467910 - Crash _purecall from nsReferencedElement::ChangeNotification::ChangeNotification [@ KiFastSystemCallRet] on reload with clip-path and bindings

Status: RESOLVED WORKSFORME

(Core :: Layout, defect)

Description

[Martijn Wargers (dead)]

Attachment: testcase

See testcase, which crashes current trunk build on reload.
Maybe this is an xbl problem?

http://crash-stats.mozilla.com/report/index/253be1fe-ceb1-410a-8f8e-1f0302081204?p=1
0  	ntdll.dll  	KiFastSystemCallRet  	
1 	ntdll.dll 	NtWaitForSingleObject 	
2 	kernel32.dll 	WaitForSingleObjectEx 	
3 	kernel32.dll 	WaitForSingleObject 	
4 	xul.dll 	google_breakpad::ExceptionHandler::WriteMinidumpOnHandlerThread 	toolkit/crashreporter/google-breakpad/src/client/windows/handler/exception_handler.cc:424
5 	xul.dll 	google_breakpad::ExceptionHandler::HandlePureVirtualCall 	toolkit/crashreporter/google-breakpad/src/client/windows/handler/exception_handler.cc:393
6 	mozcrt19.dll 	_purecall 	obj-firefox/memory/jemalloc/src/purevirt.c:47
7 	xul.dll 	nsCOMPtr<nsIPK11Token>::nsCOMPtr<nsIPK11Token> 	obj-firefox/dist/include/xpcom/nsCOMPtr.h:554
8 	xul.dll 	nsReferencedElement::ChangeNotification::ChangeNotification 	obj-firefox/dist/include/content/nsReferencedElement.h:146
9 	xul.dll 	nsReferencedElement::Observe 	content/base/src/nsReferencedElement.cpp:244
10 	xul.dll 	FireChangeEnumerator 	content/base/src/nsDocument.cpp:401
11 	xul.dll 	nsTHashtable<nsDOMStorageEntry>::s_EnumStub 	obj-firefox/dist/include/xpcom/nsTHashtable.h:420
12 	xul.dll 	PL_DHashTableEnumerate 	obj-firefox/xpcom/build/pldhash.c:735
13 	xul.dll 	nsTHashtable<nsIdentifierMapEntry::ChangeCallbackEntry>::EnumerateEntries 	obj-firefox/dist/include/xpcom/nsTHashtable.h:241
14 	xul.dll 	xul.dll@0x27d400

Comment 1

[timeless]

so the crash report is kinda funny, basically frame 6 is the death you should care about, frames 0..4 are the crash reporter crashing trying to report it.

Comment 2

[Boris Zbarsky [:bzbarsky]]

Oh, this is kinda fun.  We have a pure virtual method call.  In particular, the aTo passed to nsReferencedElement::ChangeNotification::ChangeNotification seems to be kinda busted.  gdb seems to think its an nsINode* (as the most-derived type!).

In FireChangeEnumerator we have:

(gdb) p aEntry->mKey      
$6 = {
  mCallback = 0x1b91460 <nsReferencedElement::Observe(nsIContent*, nsIContent*, void*)>, 
  mData = 0xde4086c
}
(gdb) whats aEntry->mKey.mData
0x2249038 <_ZTVN22nsSVGRenderingObserver15SourceReferenceE+8>:  0x1fd260c <_ZN22nsSVGRenderingObserver15SourceReference14ContentChangedEP10nsIContentS2_>
(gdb) whats args.mTo
0x21edc08 <_ZTV7nsINode+8>:     0x904f56aa <__cxa_pure_virtual>
(gdb) whats args.mFrom
0x21f8c68 <_ZTV16nsHTMLDivElement+8>:   0x1c30fcc <_ZN16nsHTMLDivElement14QueryInterfaceERK4nsIDPPv>

So the args.mTo is bogus.

Further up the stack:

(gdb) frame 16
#16 0x01b1ae34 in nsIdentifierMapEntry::RemoveIdContent (this=0xe4c6c68, aContent=0xe45ade0) at /Users/bzbarsky/mozilla/debug/mozilla/content/base/src/nsDocument.cpp:485
485                             static_cast<nsIContent*>(mIdContentList.SafeElementAt(0)));
(gdb) p mIdContentList.Count()
$16 = 61

the entries all look like nsINode* instances.

At least part of the problem seems to be that anonymous XBL content is passed to nsXULDocument::AddSubtreeToDocument and so ends up in the ID table, with this stack:

#0  nsIdentifierMapEntry::AddIdContent (this=0x7641328, aContent=0xc453610) at /Users/bzbarsky/mozilla/debug/mozilla/content/base/src/nsDocument.cpp:418
#1  0x01b1b571 in nsDocument::UpdateIdTableEntry (this=0x1688c00, aContent=0xc453610) at /Users/bzbarsky/mozilla/debug/mozilla/content/base/src/nsDocument.cpp:2300
#2  0x01d8e77a in nsXULDocument::AddElementToDocumentPre (this=0x1688c00, aElement=0xc453610) at /Users/bzbarsky/mozilla/debug/mozilla/content/xul/document/src/nsXULDocument.cpp:1661
#3  0x01d8ff1c in nsXULDocument::AddSubtreeToDocument (this=0x1688c00, aElement=0xc453610) at /Users/bzbarsky/mozilla/debug/mozilla/content/xul/document/src/nsXULDocument.cpp:1742
#4  0x01d4f2b0 in nsXBLBinding::InstallAnonymousContent (this=0x7601cf0, aAnonParent=0xd6fb880, aElement=0x7648640) at /Users/bzbarsky/mozilla/debug/mozilla/content/xbl/src/nsXBLBinding.cpp:370
#5  0x01d50fb1 in nsXBLBinding::GenerateAnonymousContent (this=0x7601cf0) at /Users/bzbarsky/mozilla/debug/mozilla/content/xbl/src/nsXBLBinding.cpp:662

That seems bogus to me.

Comment 3

[Boris Zbarsky [:bzbarsky]]

We do RemoveSubtreeFromDocument in nsXBLBinding::ChangeDocument... so I don't know how exactly we end up holding pointers to things that are dead.

Comment 4

[Boris Zbarsky [:bzbarsky]]

I did check, and we don't seem to be inserting the same content multiple times into the id list.  Probably worth adding such an assert anyway, though.

Comment 5

[(not currently active) Ted Mielczarek]

(In reply to comment #1)
> so the crash report is kinda funny, basically frame 6 is the death you should
> care about, frames 0..4 are the crash reporter crashing trying to report it.

Yes, see bug 397199. There's an assertion object in the minidump with more info but we're not currently getting that info out:
http://mxr.mozilla.org/mozilla-central/source/toolkit/crashreporter/google-breakpad/src/client/windows/handler/exception_handler.cc#389

Ok, it doesn't really have more info, but it does say "this was a pure virtual call".

Comment 6

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

Attachment: valgrind's description of the problem

Comment 7

[[e-mail]]

Could the fact that this is a recursive binding be a problem?

Comment 8

[Bernd]

this doesnt crash with a current debug build under winxp

Comment 9

[Martijn Wargers (dead)]

Yes, works for me too in current trunk build.

Comment 10

[chris hofmann]

it's still ranked #22 for firefox 3.5.2.

and in yesterday's crash data it appears on pretty good volume across a wide variety of releases.

distribution of all versions where the KiFastSystemCallRet crash was found on 20090831-crashdata.csv
 516 Firefox 3.5.2
 194 Firefox 3.0.13
   9 Firefox 3.5.1
   9 Firefox 3.5
   9 Firefox 3.1b3
   6 Firefox 3.0.11
   5 Firefox 3.0.10
   4 Firefox 3.0b3
   4 Firefox 3.0.1
   3 Firefox 3.0.8
   3 Firefox 3.0.12
   2 Firefox 3.7a1pre
   1 Firefox 3.5b99
   1 Firefox 3.0b2
   1 Firefox 3.0.6
   1 Firefox 3.0.5
   1 Firefox 3.0.4
   1 Firefox 3.0.3
   1 Firefox 3.0


Did the problem just go away on trunk?  If it did we should try and figure out what made it go away, and get that same code on branches.

Comment 11

[chris hofmann]

I'll file a new bug to try and sort out diffent problems that might be hidding under the same signature.

Comment 12

[chris hofmann]

new bug is 513975