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.
Also reproducible on http://voice.mozilla.org/record
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?
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
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?
(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.
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 → ---
Component: General → Crash Reporting
Product: Core → Toolkit
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.
10 months ago
See Also: → bug 1400465
[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: --- → ?
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?
See comment 18
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 ago → 10 months ago
status-firefox57: ? → fixed
Resolution: --- → FIXED
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.