Closed Bug 360078 Opened 18 years ago Closed 17 years ago

Crash [@ nsHTMLAnchorElement::UnbindFromTree] with XBL, XUL, and unused cloneNode

Categories

(Core :: XBL, defect)

defect
Not set
critical

Tracking

()

RESOLVED FIXED

People

(Reporter: jruderman, Unassigned)

References

Details

(Keywords: crash, testcase)

Crash Data

Attachments

(2 files, 1 obsolete file)

Loading the testcase makes Firefox crash after 5-15 seconds.
Attached file testcase (obsolete) (deleted) —
Attached file stack trace (mac debug / gdb) (deleted) —
This crash happens with a lot of destructors on the stack, e.g. nsDocument::~nsDocument. Sometimes it happens during GC, sometimes not, but the top line of the stack is always the same. Program received signal EXC_BAD_ACCESS, Could not access memory. Reason: KERN_PROTECTION_FAILURE at address: 0x00000000 0x081c6060 in nsHTMLAnchorElement::UnbindFromTree (this=0x248f7ee0, aDeep=0, aNullParent=1) at /Users/admin/trunk/mozilla/content/html/content/src/nsHTMLAnchorElement.cpp:201 201 GetCurrentDoc()->ForgetLink(this); (gdb) p IsInDoc() $2 = 1 (gdb) p GetCurrentDoc() $1 = (nsIDocument *) 0x0
I spent 2 days (!) making the reduced testcase after bc pointed the crash out to me, so I hope it gets fixed :)
but now your testcase works cross platform winxp 2006110704
OS: Mac OS X 10.4 → All
Hardware: Macintosh → All
Hmm... So the basic problem here is bug 53901. I would guess that the sequence of events is the following: 1) We clone the XUL node. Due to bug 53901 it flags itself as being in document. 2) We attach the XBL binding. The anonymous nodes now think they're in the document. 3) The document is destroyed. It notifies the nodeinfo manager, so now all nodes with that document have a null GetOwnerDoc()/GetCurrentDoc(). 4) Destruction of the document destroys the binding manager, which tears down the binding, releases the anonymous content, and enters the code in question. We could change step 3 to release the binding manager before notifying the nodeinfo manager, but that would sorta violate he invariant that we have a binding manager for the lifetime of the document. I think it also wouldn't help in the case when step 2 is replaced by an explicit DOM appendChild call (followed by holding to the little subtree until after the document has gone away; could happen either on purpose or due to the ordering of GC finalization). So really, we need to either fix bug 53901, fix what happens when nodes are appended to such a lying XUL node, or add null-checks everywhere where we assume that IsInDoc() means GetCurrentDoc() is non-null. I vote we fix bug 53901, except that I doubt we can do that on branches.... and I'm not sure we can do it for 1.9. :(
Depends on: 53901
> or add null-checks everywhere where we > assume that IsInDoc() means GetCurrentDoc() is non-null Or change IsInDoc to check that GetOwnerDoc() != nsnull?
> Or change IsInDoc to check that GetOwnerDoc() != nsnull? Or that for now, yeah.... That might work... Sorta.
Bug 53901 is fixed now, so should I expect this to be fixed? The testcase in this bug doesn't work any more because I'm not allowed to load XBL cross-site (e.g. from software.hixie.ch). If I change the testcase to use a data: URL (which is possible now that bug 366770 is fixed), I don't get a crash, but I do get a lot of ###!!! ASSERTION: Shallow unbind won't clear document and binding parent on kids!: 'aDeep || (!GetCurrentDoc() && !GetBindingParent())', file /Users/jruderman/trunk/mozilla/content/base/src/nsGenericElement.cpp, line 2036
Attached file testcase using data: URL (deleted) —
Attachment #245079 - Attachment is obsolete: true
Should I morph this bug to be about the assertion in comment 8 or should I make that a new bug?
Flags: blocking1.9?
Please file a new bug on the assertion.
Status: NEW → RESOLVED
Closed: 17 years ago
Flags: blocking1.9? → blocking1.9-
Resolution: --- → FIXED
Ok, filed bug 397849.
Crashtest checked in.
Flags: in-testsuite+
Depends on: 486608
Crash Signature: [@ nsHTMLAnchorElement::UnbindFromTree]
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: