Closed Bug 467910 Opened 14 years ago Closed 14 years ago

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

Categories

(Core :: Layout, defect)

x86
Windows XP
defect
Not set
critical

Tracking

()

RESOLVED WORKSFORME

People

(Reporter: martijn.martijn, Unassigned)

References

Details

(Keywords: crash, testcase)

Crash Data

Attachments

(2 files)

500 bytes, application/vnd.mozilla.xul+xml
Details
5.62 KB, text/plain; charset=UTF-8
Details
Attached file 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
Flags: blocking1.9.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.
Summary: Crash [@ KiFastSystemCallRet] on reload with clip-path and bindings → Crash _purecall from nsReferencedElement::ChangeNotification::ChangeNotification [@ KiFastSystemCallRet] on reload with clip-path and bindings
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.
We do RemoveSubtreeFromDocument in nsXBLBinding::ChangeDocument... so I don't know how exactly we end up holding pointers to things that are dead.
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.
(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".
Could the fact that this is a recursive binding be a problem?
Flags: blocking1.9.1? → wanted1.9.1+
this doesnt crash with a current debug build under winxp
Yes, works for me too in current trunk build.
Status: NEW → RESOLVED
Closed: 14 years ago
Resolution: --- → WORKSFORME
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.
I'll file a new bug to try and sort out diffent problems that might be hidding under the same signature.
new bug is 513975
Crash Signature: [@ KiFastSystemCallRet]
You need to log in before you can comment on or make changes to this bug.