Crash in AsyncShutdownTimeout | profile-before-change | Crash Reporter: blocking on minidumpgeneration.




Crash Reporting
3 months ago
14 days ago


(Reporter: philipp, Unassigned)


({crash, regression})

56 Branch
crash, regression

Firefox Tracking Flags

(firefox-esr52 unaffected, firefox55 unaffected, firefox56 fix-optional, firefox57 fix-optional)


(crash signature)



3 months ago
This bug was filed from the Socorro interface and is 
report bp-b7ab3852-ca97-41da-a4e7-5d0ca0170804.
{"phase":"profile-before-change","conditions":[{"name":"Crash Reporter: blocking on minidumpgeneration.","state":"(none)","filename":"z:/build/build/src/ipc/glue/CrashReporterHost.cpp","lineNumber":192,"stack":"Minidump generation"}]}

this async shutdown timeout crash was introduced with bug 1360308. 
it is in the top 5 browser crashes of 57.0a1 in its first few days.
Looks like minidump generation can be so slow as to cause shutdown timeout. This is probably what happened:

* A child process hangs.
* The parent process detects that and generates a minidump for that.
* The user closes the browser, but we block shutdown during the generation of minidumps.
* Shutdown timeout crash.

I am not sure whether we can cleanly unblock the above scenario. If we don't block shutdown on minidump generation, we can still block in shutting down the thread for async dump generation:

Or we just don't shut down the thread when we have pending operation on it during process shutdown and let the thread leak, but it doesn't sound good that we let the thread continue writing the minidump while we exit the main thread.
See Also: → bug 1376795

Comment 2

2 months ago
shutdown timeout auto generated crash.
status-firefox56: affected → fix-optional
status-firefox57: affected → fix-optional

Comment 3

14 days ago
Pre async crashes were in bug 1182927.
Increased volume likely down to a shorter timeout.
You need to log in before you can comment on or make changes to this bug.