Closed Bug 1362203 Opened 7 years ago Closed 6 years ago

Crash in AsyncShutdownTimeout | profile-before-change | Crash reporter: blocking on minidump analysis

Categories

(Toolkit :: Crash Reporting, defect)

53 Branch
defect
Not set
normal

Tracking

()

RESOLVED FIXED
Tracking Status
firefox-esr52 --- unaffected
firefox-esr60 --- wontfix
firefox53 --- wontfix
firefox54 --- fix-optional
firefox55 --- fix-optional

People

(Reporter: philipp, Unassigned)

References

Details

(Keywords: crash, regression)

Crash Data

This bug was filed from the Socorro interface and is 
report bp-506367cd-9e54-4105-a46a-71cba0170504.
=============================================================

this new async shutdown timeout signature is newly showing up since firefox 53 from the work in bug 1293656. so better analysing crash reports might even trigger some more :-)

AsyncShutdownTimeout 	
{"phase":"profile-before-change","conditions":[{"name":"Crash reporter: blocking on minidump analysis","state":"(none)","filename":"c:/builds/moz2_slave/m-rel-w32-00000000000000000000/build/src/ipc/glue/CrashReporterHost.cpp","lineNumber":95,"stack":"Minidump analysis"}]}
It seems like minidump analysis is taking too long while a regular shutdown is also taking place. I intend to rewrite the code in bug 1293656 in JavaScript as part of bug 1359326 so I might also add a provision to drop the minidump analysis if Firefox is shutting down.
300 crashes or so here, per week, on release. Looks like a fix may be coming soon in bug 1359326.
(In reply to Liz Henry (:lizzard) (needinfo? me) from comment #2)
> 300 crashes or so here, per week, on release. Looks like a fix may be coming
> soon in bug 1359326.

Ouch. Well I do hope that bug 1359326 solves this by getting rid of the additional shutdown blocker, but if it doesn't (i.e. if we start timing out on the other blocker) then I might have to rethink how we handle this. I'm keeping my fingers crossed in the meantime, I should be able to land bug 1359326 next week after a last round of tests.
Now that bug 1359326 has landed keep your eyes peeled for crashes like this one but with the reason being "CrashService waiting for content crash ping to be sent". That's the other blocker in this code path and that one is still there and could take a long time.

If we get a spike of those then I think I'll have to drop any kind of minidump analysis for content crashes during shutdown and postpone it to the next startup.
Crash reports for this signature are only coming from users with old versions that don't have the fix in bug 1359326, closing.
Status: NEW → RESOLVED
Closed: 6 years ago
Resolution: --- → FIXED
You need to log in before you can comment on or make changes to this bug.