crash [@ nsDOMClassInfo::PreCreate], [@ XUL@0x62fba6 ]

RESOLVED WORKSFORME

Status

()

--
critical
RESOLVED WORKSFORME
8 years ago
5 years ago

People

(Reporter: humph, Assigned: peterv)

Tracking

({crash})

Trunk
All
Mac OS X
crash
Points:
---

Firefox Tracking Flags

(blocking2.0 .x+)

Details

(Whiteboard: [softblocker], crash signature)

Attachments

(1 attachment)

(Reporter)

Description

8 years ago
This bug was filed from the Socorro interface and is 
report bp-cb0bf4f8-4e83-4d37-9641-8bab72110129 .
============================================================= 

The last few days, working on our audio/webgl demo, I've been crashing on shutdown quite a bit.  It doesn't happen every time, and it doesn't always produce a useful stack (they might not all be the same thing).
(Reporter)

Updated

8 years ago
Assignee: nobody → general
Component: General → JavaScript Engine
Product: Firefox → Core
QA Contact: general → general

Updated

8 years ago
Component: JavaScript Engine → XPConnect

Comment 1

8 years ago
Setting b? to get this triaged.
blocking2.0: --- → ?

Comment 2

8 years ago
This looks like a shutdown problem. The context might have been destroyed already. Hard to tell from here. David, can you point me to the test case?

Updated

8 years ago
QA Contact: general → xpconnect
(Reporter)

Comment 3

8 years ago
I'm having a lot of trouble reproducing this, but here is another one that just happened (not as helpful as before):

https://crash-stats.mozilla.com/report/index/bp-32583cf2-9003-482f-ab18-9a8c12110130

This demo is due tomorrow, so I'll have a version you can test with soon, but can't stop working on it now to get you one.
(Reporter)

Updated

8 years ago
Summary: crash [@ nsDOMClassInfo::PreCreate] → crash [@ nsDOMClassInfo::PreCreate], [@ XUL@0x62fba6 ]

Comment 5

8 years ago
We can't block on this until we get a test case and STR.
(Reporter)

Comment 6

8 years ago
I've had it happen 5 times over the weekend to me, and I still have no idea how to tell you STR, except that I'll mail you a link to this demo and you can try it there (we finished an hour ago)--you run it, sometimes on close, it crashes.  We are doing something with memory that doesn't agree with the browser.  This demo is likely a useful stress test of things anyway, so good for you to see it, Andreas.

Comment 7

8 years ago
Yeah, that sounds good. Just send me the link and we will cycle through it a couple times.

Comment 8

8 years ago
We should try to find out whats up here before we ship, if possible. We might not have to fix it before we ship.
blocking2.0: ? → final+
Whiteboard: [softblocker]

Updated

8 years ago
Assignee: general → gal

Updated

8 years ago
Keywords: qawanted

Comment 9

8 years ago
QA help would be appreciated reproducing this. If you need the test case, please contact me or David.
That first stack seems pretty clear.  

   424 inline
   425 nsQueryInterface
   426 do_QueryWrapper(JSContext *cx, JSObject *obj)
   427 {
   428   nsISupports *native =
   429     nsDOMClassInfo::XPConnect()->GetNativeOfWrapper(cx, obj);
   430   return nsQueryInterface(native);
   431 }

nsDOMClassInfo::XPConnect() is null at this point in shutdown, presumably, given the crash address.

Comment 11

8 years ago
I can make a patch based on that theory.
An interesting question, though, is _why_ we're trying to js-wrap stuff that late in shutdown.  Are we leaking here?  humph's comments in #audio suggested we might be.

Comment 13

8 years ago
Yeah an observer leak of some kind seems likely.
Fwiw, I'd kill for JS stacks in soccorro.  Probably not people, but a pigeon, say....  Does Ted take burnt offerings?  ;)
Once we have OOP crashdumping, we can get there.

Comment 16

8 years ago
Created attachment 509285 [details] [diff] [review]
patch
Attachment #509285 - Flags: review?(bzbarsky)

Comment 17

8 years ago
I think this is the right choke point. bz? This doesn't fix the leak of course.

Comment 18

8 years ago
jst says that peter should take a look, too.

mrbkap says we don't always end up in nsDOMClassInfo::PreCreate, so we might want to add this to all PreCreate hooks.
Comment on attachment 509285 [details] [diff] [review]
patch

Yeah, add to the other hooks and looks good.
Attachment #509285 - Flags: review?(bzbarsky) → review+
(Assignee)

Comment 20

8 years ago
Not all hooks would need this, windows and documents (so also nodes that still have a wrapper) keep nsLayoutStatics alive past XPCOM shutdown notifications. That was done to prevent these types of crashes. The scary part is that nsDOMScriptObjectFactory::Observe seems to circumvent it though.
blocking2.0: final+ → ?

Updated

8 years ago
blocking2.0: ? → final+

Comment 21

8 years ago
peterv, what should we do here?

Updated

8 years ago
Assignee: gal → peterv

Comment 22

8 years ago
jst suggested peterv should take this since he knows what to do here
** PRODUCT DRIVERS PLEASE NOTE **

This bug is one of 7 automatically changed from blocking2.0:final+ to blocking2.0:.x during the endgame of Firefox 4 for the following reasons:

 - it was marked as a soft blocking issue without a requirement for beta coverage
blocking2.0: final+ → .x+
Crash Signature: [@ nsDOMClassInfo::PreCreate] [@ XUL@0x62fba6 ]
You need to log in before you can comment on or make changes to this bug.