Closed Bug 1393451 Opened 4 years ago Closed 2 years ago
Crash in xul
.dll@0xce1b75 | _PR _Native Run Thread | pr _root
This bug was filed from the Socorro interface and is report bp-101c581c-368c-455a-afee-4a5cc0170824. ============================================================= Filing in General, not sure if this instead belongs in NSPR - new crash in Beta 5: http://bit.ly/2wBguHu No URLs and no correlations are present. Reports show "MOZ_CRASH(Shutdown too long, probably frozen, causing a crash.)" Some URLs: https://b2b.flysriwijayaair.com/SJ-Eticket/application/?action=booking http://www.airtel.in/applications/airteldongle.jsp?et=1415705166516 https://id.yahoo.com/ https://www.facebook.com/
Maybe related to bug 1389160. rhelmer can you check?
(In reply to Liz Henry (:lizzard) (needinfo? me) from comment #1) > Maybe related to bug 1389160. rhelmer can you check? Bug 1389160 only runs at startup so I don't think that's it... I see WindowsDllBlocklist.cpp in the stack so that is probably where I would suggest investigating.
Flags: needinfo?(rhelmer) → needinfo?(lhenry)
It's crashing in the shutdown hang terminator, which should be categorized as shutdown hang. I think socorro failed to label it. Or it's due to missing symbol because the last frame should be `mozilla::`anonymous namespace'::RunWatchdog`
This was tagged for 55 but it actually only appears in 56 (beta 5, so far).
http://bit.ly/2x11y4V seems to the equivalent signature for Beta 6. Upon looking further in crash stats there are also similar signatures for ESR and 55.0.3 (xul.dll@0x8c7564 | _PR_NativeRunThread | pr_root). Most of the comments mention Firefox being very slow and laggy.
I'm pretty positive that the signature is from the shutdown watch dog because it's on the "Shutdown Hang Terminator" thread. Adrian could you confirm this signature is shutdownhang and we fail to label it as so? Ted, any idea why we fail to symolicate the first frame?
Deferring to Will.
Flags: needinfo?(adrian) → needinfo?(willkg)
I agree with comment #3. If "RunWatchdog" shows up in the signature, the signature gets prepended with "shutdownhang". But since that frame didn't get symbolicated due to missing symbols, that didn't happen.
If you look at the Modules tab you can see that there's no Debug Identifier/Filename for xul.dll. This happens sometimes for crashes where we're low on memory and the minidump writing code fails to write out the necessary information. Without that the stackwalker can't find the matching symbols, unfortunately.
I assume this is the same issue, but each have different addresses due to being different versions/builds? https://crash-stats.mozilla.com/search/?signature=~_PR_NativeRunThread%20%7C%20pr_root&date=%3E%3D2017-08-23T15%3A54%3A00.000Z&date=%3C2017-08-30T15%3A54%3A00.000Z&_sort=-date&_facets=signature&_columns=date&_columns=signature&_columns=product&_columns=version&_columns=build_id&_columns=platform#facet-signature
(In reply to Mike Taylor [:miketaylr] from comment #10) > I assume this is the same issue, but each have different addresses due to > being different versions/builds? It looks like so. I randomly clicked some reports and all of them are on the "Shutdown Hang Terminator" thread. We need a better way to detect that. Is it possible to facet on the thread name given we have this data now?
when faceting the link from comment #10 on versions this issue goes back for a long time (firefox 4 showing up there too), so it's not a recent regression...
Component: General → DOM: Content Processes
Product: Firefox → Core
Noting the signature in bug 1413224 is also the #16 top crash for Windows on 56.0.2. From the comments on crash stats, it's noticeable to users.
Closing because no crashes reported for 12 weeks.
Status: NEW → RESOLVED
Closed: 2 years ago
Resolution: --- → WONTFIX
You need to log in before you can comment on or make changes to this bug.