Closed Bug 319642 Opened 19 years ago Closed 19 years ago

ASSERTION: unexpected null pointer: 'aParticipant', file nsDOMClassInfo.cpp, line 4960


(Core :: DOM: Core & HTML, defect, P1)






(Reporter: jason.barnabe, Assigned: dbaron)



(Keywords: crash, fixed1.8.1, Whiteboard: [patch])


(2 files, 1 obsolete file)

Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9a1) Gecko/20051208 Firefox/1.6a1

//a whole bunch of stuff to get a reference to a content document
var ww = Components.classes[";1"].getService(Components.interfaces.nsIWindowMediator);
var win = ww.getEnumerator("navigator:browser").getNext();
var browser = win.document.getElementsByTagName("tabbrowser")[0].browsers[0];
var docStyle = browser.contentDocument.QueryInterface(Components.interfaces.nsIDOMDocumentStyle);
//this crashes
docStyle.styleSheets[docStyle.styleSheets.length] = "this is a new sheet!";

WARNING: NS_ENSURE_TRUE(NS_SUCCEEDED(rv)) failed, file nsEditor.cpp, line 1273
###!!! ASSERTION: unexpected null pointer: 'aParticipant', file nsDOMClassInfo.cpp, line 4960
Break: at file nsDOMClassInfo.cpp, line 4960
--WEBSHELL 0xde6680 == 5
./ line 131: 26549 Segmentation fault      "$prog" ${1+"$@"}
4960  NS_PRECONDITION(aParticipant, "unexpected null pointer");
please set XPCOM_DEBUG_BREAK=suspend or something (see unix debugging faq) and gete a full stack trace for the assert.
Assignee: general → dbaron
Component: DOM → Style System (CSS)
Keywords: stackwanted
Either that, or attach a testcase (one that uses UniversalXPConnect privileges as needed?) that would let someone else reproduce the crash...

Alternately, if you can just crash in a debugger and get the stack from that, that would also help some.  If you can crash in a debugger and catch someone on irc to help debug, that would be even better.
Keywords: qawanted
Attached file stack (obsolete) —
I also noticed that the code doesn't crash immediately - it crashes on the next window I close.
Keywords: stackwanted
Er..  That's the stack to the crash.  That doesn't really help -- we're crashing because someone stuck a null in our hashtable (which is when we asserted), but by this point we have no idea who that was.

The stack to the assertion is what matters here.
Attached file stack of the assertion
Sorry about that.
Attachment #205501 - Attachment is obsolete: true
Hmm...  When you get that assertion, in frame 5, what does

  x/wa *(void**) aWrapper->Native()

return in gdb?
0x2aaab14ef4b0 <_ZTV19nsDOMStyleSheetList+16>:  0xffffffffb0fc3514
Keywords: stackwanted
Ah, ok.  So this is a regression from bug 241518 -- the problem is that nsJSContext::PreserveWrapper doesn't only get called for wrappers on nodes.  The patch in that bug makes it call nsDOMClassInfo::PreserveNodeWrapper, which doesn't check whether the native actually QIs to nsIDOMGCParticipant (and in this case it doesn't).

Jason, thanks for the debugging help!
Blocks: 241518
Flags: blocking1.9a1+
Keywords: qawanted
Note that to reproduce you have to work with an XPCNativeWrapper.  Minimal testcase for that assert is:

javascript:void(new XPCNativeWrapper(document.styleSheets)['foo'] = "test");
Attached patch patchSplinter Review
untested, but it should work
Attachment #206365 - Flags: superreview?(jst)
Attachment #206365 - Flags: review?(jst)
Component: Style System (CSS) → DOM
OS: Linux → All
Priority: -- → P1
Hardware: PC → All
Whiteboard: [patch]
Target Milestone: --- → mozilla1.9alpha
Attachment #206365 - Flags: superreview?(jst)
Attachment #206365 - Flags: superreview+
Attachment #206365 - Flags: review?(jst)
Attachment #206365 - Flags: review+
Blocks: 320946
Checked in to trunk.
Closed: 19 years ago
Resolution: --- → FIXED
Fixed on MOZILLA_1_8_BRANCH by checkin of bug 336791.
Keywords: fixed1.8.1
Component: DOM → DOM: Core & HTML
You need to log in before you can comment on or make changes to this bug.