Closed Bug 1662764 Opened 4 years ago Closed 3 years ago

Crash in [@ EMPTY: no crashing thread identified; ERROR_NO_THREAD_LIST]

Categories

(Toolkit :: Crash Reporting, defect)

Product:
Toolkit
Component:
Crash Reporting
Type:
defect

Tracking

()

Status:
RESOLVED WORKSFORME

People

(Reporter: calixte, Unassigned)

References

Details

(Keywords: crash)

Crash Data

Attachments

(1 file)

aboutsupport.txt
24.56 KB, text/plain
Details

Crash report: https://crash-stats.mozilla.org/report/index/99d93739-d953-45e1-8af5-4b09e0200902

The crash report is pretty empty (and so almost useless).
:gsvelto, could it be an issue in the crash reporter ?

Flags: needinfo?(gsvelto)

I've been seeing this today with current Nightly: three crashes in fifteen minutes.

https://crash-stats.mozilla.org/report/index/8d653e66-806d-40b0-b03b-7b72d0200902
https://crash-stats.mozilla.org/report/index/12d43c2c-bae6-4e11-a6a4-e3a5b0200902
https://crash-stats.mozilla.org/report/index/567dc9c0-09ee-4fc5-b44d-88be00200902

First one was clicking a Spotify link in Slack; a few milliseconds of audio then crash.

Another was scrolling in Reddit; a video autoplay kicked out some audio.

And another one shortly after stopping an audio-playing video in Reddit. Suspect a media root cause, potentially with a crash reporter issue alongside.

Partial bisect:

Good: https://ftp.mozilla.org/pub/firefox/nightly/2020/08/2020-08-24-09-44-58-mozilla-central/
Bad: https://ftp.mozilla.org/pub/firefox/nightly/2020/08/2020-08-27-21-29-40-mozilla-central/

so that's a three day window.

I was reproducing the crash just by unmuting a video in Reddit and scrolling.

This issue typically occurs when we're unable to write out a minidump. Unfortunately we don't have granular error information about the failure so we usually don't know why it happened. What platform where you reproducing this issue on? Can you still reproduce it? If you can I'd love to know the STR. Also it would be great if you could collect a minidump via WER. That requires the following steps:

  • Launch regedit.exe and add the following key HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\Windows Error Reporting\LocalDumps
  • Reproduce the crash
  • Go into %LOCALAPPDATA%\CrashDumps, that's usually C:\Users\<username>\AppData\Local\CrashDumps. If a minidump was generated grab it and send it to me via e-mail (do not attach it to the bug as it might contain sensitive information)
  • Remove the registry key you added to revert to the default Windows behavior WRT crashes
Flags: needinfo?(bugzilla)
Attached file aboutsupport.txt —

(In reply to Gabriele Svelto [:gsvelto] (PTO until September 5th) from comment #4)

What platform where you reproducing this issue on?

This is on macOS: 10.14.6.

STR was simply: launch recent Nightly, restore my profile, then do anything that plays audio (e.g., play in Spotify, scroll in Reddit with videos unmuted).

I've attached an about:support dump from a working Nightly.

Flags: needinfo?(gsvelto)
Flags: needinfo?(bugzilla)
Flags: needinfo?(gsvelto)

Thanks a lot, I thought this was on Windows. I have to fix my mac to try and repro which will take a few days so leaving the NI? so I don't forget.

Still reproducible in current Nightly in 44.1 or 48kHz output freq, with two different audio devices, by just unmuting a video on Reddit.

E.g.,

https://crash-stats.mozilla.org/report/index/57b29e6e-b2e6-460a-ac18-ac1a10200910

Yes, my Nightly auto-updated on restart, so now I'm back to a crashing build.

I was unable to reproduce this on both the Nightly from Aug 28 and today. MacOS 10.14.5.

Would you be able to run it through mozregression so we can at least narrow down the regression range a bit further?

I see CDM and mp4 parse patches in this range, both apply to spotify, and the mp4 parser probably applies to reddit.

I narrowed this down: with Tab Center Redux 0.7.1 (and Facebook Container), in my main profile, crash. Without Tab Center Redux, no crash.

I cannot reproduce in a fresh profile with Tab Center Redux.

That points a finger at the tab audio indicator somehow?

Narrowed down further: you need a lot of tabs open to cause the issue. The "Count Tabs" extension suggests that I have 437 tabs open in this window, about 500-600 open in Firefox as a whole.

A new window with one tab playing video/audio doesn't crash — and the tab icon is badged with a speaker correctly in the Tab Center sidebar.

So my wild-ass guess is that there's a race condition with the synchronous WebExtension tab status change callback when audio status changes, and Tab Center isn't fast enough once you get into the hundreds of tabs.

No crash with Tree Style Tabs in the same situation.

Good find! I'm worried about the range in comment 3 ? Should we disregard it, or does it tie into the problem somehow?

Is this a content process crash, or a parent process crash (sounds like a parent process crash) ? You can attach lldb to a process to catch the crash (child or parent), and then if you do a backtrace, it won't be symbolicated, but if you paste it here with the addresses, with your exact build id we can recover stacks.

lldb --pid PID from a terminal, where PID is the PID of either the child (content) process, or the parent, bt for a backtrace when it crashes. You will probably have to authenticate when attaching because attaching a debugger to a running process can't be done as a normal user.

All this said, we can probably repro ourselves if we install Tab Center Redux 0.7.1

Flags: needinfo?(bugzilla)

(In reply to Paul Adenot (:padenot) from comment #14)

Good find! I'm worried about the range in comment 3 ? Should we disregard it, or does it tie into the problem somehow?

This is definitely a recent regression between mid-August and late August; I've been using Tab Center Redux (which hasn't changed recently) with lots of tabs and web audio sources for years.

My bisect range is probably correct, though of course the root cause might not be new at all, particularly if it's a performance-related race condition change.

Is this a content process crash, or a parent process crash (sounds like a parent process crash) ? You can attach lldb to a process to catch the crash (child or parent), and then if you do a backtrace, it won't be symbolicated, but if you paste it here with the addresses, with your exact build id we can recover stacks.

I believe our processes use PT_DENY_ATTACH from lldb, so my attempts to attach to a downloaded Nightly build were failing, even with sudo.

(lldb) process attach --pid 29358
error: attach failed: Error 1
Flags: needinfo?(bugzilla)

Welp, I just got this same crash signature scrolling a page with Tree Style Tabs and no audio playing:

https://crash-stats.mozilla.org/report/index/aba65908-8911-4648-a24a-0827e0200912

That implies to me that this crash reporter issue is still a thing independent of that root cause, or the root cause doesn't require audio or Tab Center Redux.

Welp, I just got this same crash signature scrolling a page with Tree Style Tabs and no audio playing:

can you catch the crash in windbg and get a stack?

(looking forward to the new crash reporter)

(In reply to Wayne Mery (:wsmwk) from comment #17)

can you catch the crash in windbg and get a stack?

Doubly no: this is on macOS, not on Windows, and Nightly seems to be built with PT_DENY_ATTACH to specifically prevent debugging — at least, I am not able to attach with sudo lldb.

Depends on: 1666733

I could not reproduce the issue but I've filed bug 1666733 to add diagnostics that would allow us to figure out what went wrong in this case.

Flags: needinfo?(gsvelto)
Severity: -- → S2

Closing because no crashes reported for 12 weeks.

Status: NEW → RESOLVED
Closed: 3 years ago
Resolution: --- → WORKSFORME
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: