Crash in EMPTY: no crashing thread identified; OK

RESOLVED FIXED in Firefox 57

Status

()

Toolkit
Crash Reporting
--
critical
RESOLVED FIXED
a year ago
10 months ago

People

(Reporter: Harald, Assigned: achronop)

Tracking

({crash})

unspecified
mozilla57
Unspecified
Mac OS X
crash
Points:
---
Dependency tree / graph

Firefox Tracking Flags

(firefox-esr52 unaffected, firefox55 unaffected, firefox56 unaffected, firefox57+ fixed)

Details

(crash signature)

(Reporter)

Description

a year ago
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.
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?
Flags: needinfo?(spohl.mozilla.bugs)
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?
Flags: needinfo?(spohl.mozilla.bugs) → needinfo?(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.
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.
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.
This was caused by bug 1384053 and fixed by bug 1385481.
Status: NEW → RESOLVED
Last Resolved: a year ago
Flags: needinfo?(mstange)
Resolution: --- → DUPLICATE
Duplicate of bug: 1385481
(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!
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?
Flags: needinfo?(ted)
(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.
Flags: needinfo?(ted)
So why can't we blame the correct thread?
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)
I'm reopening this to track the empty crash problem.
Status: RESOLVED → REOPENED
Resolution: DUPLICATE → ---
Duplicate of this bug: 1385465
Component: General → Crash Reporting
Product: Core → Toolkit
Status: REOPENED → NEW
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.

Updated

11 months ago
See Also: → bug 1398337

Updated

11 months ago
Blocks: 1398356
[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.
status-firefox57: --- → ?
tracking-firefox57: --- → ?
(Assignee)

Comment 18

10 months ago
It should be due to bug 1400465. This is fixed in bug 1400671. The patch is still on inbound.
See comment 18
Flags: needinfo?(ted)
Flags: needinfo?(spohl.mozilla.bugs)

Comment 20

10 months ago
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.
Status: NEW → RESOLVED
Last Resolved: a year ago10 months ago
status-firefox57: ? → fixed
Resolution: --- → FIXED
See Also: → bug 1400671
Target Milestone: --- → mozilla57
tracking-firefox57: ? → +
Assignee: nobody → achronop
status-firefox55: --- → unaffected
status-firefox56: --- → unaffected
status-firefox-esr52: --- → unaffected
Depends on: 1400671
See Also: bug 1400671
(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.
You need to log in before you can comment on or make changes to this bug.