1385531 - Crash in EMPTY: no crashing thread identified; OK

Status: RESOLVED FIXED

(Toolkit :: Crash Reporting, defect)

Description

[:Harald Kirschner :digitarald]

This bug was filed from the Socorro interface and is 
report bp-928f830e-08ea-48d5-aea0-fbb550170729.
=============================================================

STR:

Opened https://tuner.cloud
Accepted access to microphone.
Crash. Open tab again. Crash.

Comment 1

[Mike Conley (:mconley) (:⚙️)]

Also reproducible on http://voice.mozilla.org/record

Comment 2

[Nicholas Nethercote [inactive]]

This crash signature is heavily or entirely weighted towards Mac. crash-stats correlations say:

> (79.41% in signature vs 05.47% overall) platform = Mac OS X

but the individual reports appear to be 100% Mac.

It's the #2 Mac topcrash in Nightly 20170728100358.

spohl, any ideas?

Comment 3

[Stephen A Pohl [:spohl]]

I'm unable to reproduce this, and I don't know how to get started with the crash reports. Is it true that if we don't detect a crashing thread, we don't parse the crash log at all? Markus, have you seen this before?

Comment 4

[Markus Stange [:mstange]]

I also hit this crash on http://voice.mozilla.org/record a few days ago, but I can't reproduce it now. Maybe it has been fixed? I'll try to reproduce it in an older build.

Comment 5

[Stephen A Pohl [:spohl]]

If I'm reading this right, there seem to be crash reports with build ids of today, which makes me pessimistic about this being fixed.

Comment 6

[Markus Stange [:mstange]]

I'm able to reproduce this in the 2017-07-28 build, but not in today's build. I'm now looking for a fix range.

Comment 7

[Markus Stange [:mstange]]

This was caused by bug 1384053 and fixed by bug 1385481.

Comment 8

[Stephen A Pohl [:spohl]]

(In reply to Markus Stange [:mstange] from comment #7)
> This was caused by bug 1384053 and fixed by bug 1385481.

Thank you for the sleuthing!

Comment 9

[Markus Stange [:mstange]]

We were crashing at this assert(): http://searchfox.org/mozilla-central/rev/bbc1c59e460a27b20929b56489e2e55438de81fa/media/libcubeb/src/cubeb_audiounit.cpp#611

Ted, do you if there's a bug about the crash reporter not being able to identify the crashing thread here?

Comment 10

[(not currently active) Ted Mielczarek]

(In reply to Stephen A Pohl [:spohl] from comment #3)
> I'm unable to reproduce this, and I don't know how to get started with the
> crash reports. Is it true that if we don't detect a crashing thread, we
> don't parse the crash log at all? Markus, have you seen this before?

(In reply to Markus Stange [:mstange] from comment #9)
> Ted, do you if there's a bug about the crash reporter not being able to
> identify the crashing thread here?

We don't generate a useful signature if we don't know the crashing thread, since we can't blame the right thread. In this case, as mstange points out, we're crashing somewhere that's *not* the main thread, so if we blamed the main thread we'd have an incorrect signature.

Comment 11

[Markus Stange [:mstange]]

So why can't we blame the correct thread?

Comment 12

[(not currently active) Ted Mielczarek]

There is a thread ID in the exception record in the minidump (from the output of minidump_dump on the dump in comment 0):
MDException
  thread_id                                  = 0xb4623
  exception_record.exception_code            = 0x5
  exception_record.exception_flags           = 0x10002
  exception_record.exception_record          = 0x0
  exception_record.exception_address         = 0x7fffbcdca34a
  exception_record.number_parameters         = 0
  thread_context.data_size                   = 1232
  thread_context.rva                         = 0xcbc50

However, that thread isn't present in the minidump:
$ minidump_dump ~/dumps/bug1385531-928f830e-08ea-48d5-aea0-fbb550170729.dmp 2>/dev/null | grep thread_id | grep 0xb4623
  thread_id                                  = 0xb4623
  dump_thread_id       = 0xb4623
  requesting_thread_id = 0xb4623

(the first line is from the MDException I pasted above, the last two are from the "breakpad info" which just indicates which thread asked for the dump)

Comment 13

[Jeff Muizelaar [:jrmuizel]]

I'm reopening this to track the empty crash problem.

Comment 15

[(not currently active) Ted Mielczarek]

There's an additional Socorro bug here that I didn't realize yesterday--there are threads with valid stacks in the stackwalker output, but Socorro doesn't show any of them, presumably because there's no crashing thread.

Comment 16

[Nicholas Nethercote [inactive]]

[Tracking Requested - why for this release]:

This crash signature is accounting for 60--80% of all Mac crashes on Nightly, and the volumes are really high. In other words, we have a significant crash problem on Mac right now and zero insight into the cause because the crash reports are lacking stack traces.

Comment 17

[Julien Cristau [:jcristau]]

https://crash-stats.mozilla.com/signature/?release_channel=nightly&platform=Mac%20OS%20X&signature=EMPTY%3A%20no%20crashing%20thread%20identified%3B%20OK&date=%3E%3D2017-06-18T08%3A33%3A50.000Z&date=%3C2017-09-18T08%3A36%3A00.000Z&_columns=date&_columns=product&_columns=version&_columns=build_id&_columns=platform&_columns=reason&_columns=address&_columns=install_time&_columns=platform_pretty_version&_sort=-date&page=1#graphs

This issue got worse on mac in the last few days.  Ted, Stephen, any ideas why?

Comment 18

[Alex Chronopoulos [:achronop]]

It should be due to bug 1400465. This is fixed in bug 1400671. The patch is still on inbound.

Comment 19

[Stephen A Pohl [:spohl]]

See comment 18

Comment 20

[[:philipp]]

looking at crash stats, this issue was indeed fixed with bug 1400671 - the last nightly with an unusually high amount of these crashes on mac was 57.0a1 build 20170917220255.

Comment 21

[(not currently active) Ted Mielczarek]

(In reply to Ted Mielczarek [:ted.mielczarek] from comment #15)
> There's an additional Socorro bug here that I didn't realize
> yesterday--there are threads with valid stacks in the stackwalker output,
> but Socorro doesn't show any of them, presumably because there's no crashing
> thread.

I finally remembered to file a bug on this: bug 1406121.