nsCookieService::Init calls GetPrivateBrowsingEnabled, which creates a JSStackGuard, which calls |do_GetService("@mozilla.org/js/xpc/ContextStack;1", &rv);|, which calls into XPConnect. I'm not exactly sure what JSStackGuard is trying to do, but maybe it should just be a no-op if it is being called off the main thread? There shouldn't be any JS running there. Crashes from the last week on beta: https://crash-stats.mozilla.com/report/index/961834de-1613-4187-9407-5ac242121205 https://crash-stats.mozilla.com/report/index/f43c1209-553c-4192-a9c5-63fc92121204 https://crash-stats.mozilla.com/report/index/41d6ac8d-8c60-40f5-ac98-5c9ec2121203 https://crash-stats.mozilla.com/report/index/34a1c728-02e4-4339-97d4-7a2492121202 https://crash-stats.mozilla.com/report/index/bec35329-c128-4a02-b092-7089f2121202
See bug 472396 and bug 475141 for the backstory of why we're doing this. If you want I can probably avoid using the JSStackGuard in the PB side somehow. But perhaps this makes more sense to be done in JSStackGuard itself... Over to xpconnect to get the right people involved. (Also, note that the PB code in question is going to go away completely very soon -- bug 818800)
Component: Private Browsing → XPConnect
Product: Firefox → Core
If this is just going away soon anyways, it seems like it isn't worth fixing, as the volume of crashes is quite low. Thanks for the explanation!
Status: NEW → RESOLVED
Last Resolved: 6 years ago
Resolution: --- → WONTFIX
Crash Signature: [@ nsXPConnect::GetXPConnect()]
(In reply to comment #2) > If this is just going away soon anyways, it seems like it isn't worth fixing, > as the volume of crashes is quite low. Thanks for the explanation! Is this the only place in the code where we use those though?
Other places seem to do similar things with nsIJSContextStack, but I guess it is okay as long as it isn't off the main thread...
Component: XPConnect → Private Browsing
Product: Core → Firefox
You need to log in before you can comment on or make changes to this bug.