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

Status: RESOLVED FIXED

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

Description

[Jason Barnabe (np)]

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["@mozilla.org/appshell/window-mediator;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
./run-mozilla.sh: line 131: 26549 Segmentation fault      "$prog" ${1+"$@"}


http://lxr.mozilla.org/seamonkey/source/dom/src/base/nsDOMClassInfo.cpp#4960
4960  NS_PRECONDITION(aParticipant, "unexpected null pointer");

Comment 1

[timeless]

please set XPCOM_DEBUG_BREAK=suspend or something (see unix debugging faq) and gete a full stack trace for the assert.

Comment 2

[Boris Zbarsky [:bzbarsky]]

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.

Comment 3

[Jason Barnabe (np)]

Attachment: stack

Comment 4

[Jason Barnabe (np)]

I also noticed that the code doesn't crash immediately - it crashes on the next window I close.

Comment 5

[Boris Zbarsky [:bzbarsky]]

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.

Comment 6

[Jason Barnabe (np)]

Attachment: stack of the assertion

Sorry about that.

Comment 7

[Boris Zbarsky [:bzbarsky]]

Hmm...  When you get that assertion, in frame 5, what does

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

return in gdb?

Comment 8

[Jason Barnabe (np)]

0x2aaab14ef4b0 <_ZTV19nsDOMStyleSheetList+16>:  0xffffffffb0fc3514

Comment 9

[Boris Zbarsky [:bzbarsky]]

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!

Comment 10

[Boris Zbarsky [:bzbarsky]]

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");

Comment 11

[David Baron :dbaron: (⌚️UTC-4, no longer working on Mozilla)]

Attachment: patch

untested, but it should work

Comment 12

[David Baron :dbaron: (⌚️UTC-4, no longer working on Mozilla)]

Checked in to trunk.

Comment 13

[David Baron :dbaron: (⌚️UTC-4, no longer working on Mozilla)]

Fixed on MOZILLA_1_8_BRANCH by checkin of bug 336791.