Closed Bug 451323 Opened 16 years ago Closed 16 years ago

[FIX] Crash [@ nsAttributeTextNode::UnbindFromTree] with <optgroup> in <xbl:content>

Categories

(Core :: XBL, defect, P1)

x86
macOS
defect

Tracking

()

RESOLVED FIXED

People

(Reporter: jruderman, Assigned: smaug)

References

Details

(Keywords: crash, testcase, Whiteboard: [sg:critical?])

Crash Data

Attachments

(2 files)

Steps to reproduce:
1. export MallocScribble=1
2. Run a debug build of Firefox.
3. Load the testcase.
4. Quit Firefox.

Result: crash [@ nsAttributeTextNode::UnbindFromTree], usually dereferencing 0x555555c5, but sometimes dereferencing 0xc71fe657 or nearby.
Whiteboard: [sg:critical?]
Is this new?  Sounds like a possible regression from bug 238072.
Blocks: 238072
Flags: blocking1.9.1?
Yeah, it does.
Assignee: nobody → roc
Not blocking on this, but we'd really love a fix for this.
Flags: wanted1.9.1+
Flags: wanted1.9.0.x?
Flags: blocking1.9.1?
Flags: blocking1.9.1-
Priority: -- → P1
Attached patch patchSplinter Review
This should do it. Because nsAttributeTextNode is already mutationobserver, just
use NodeWillBeDestroyed.
Assignee: roc → Olli.Pettay
Attachment #341607 - Flags: superreview?(roc)
Attachment #341607 - Flags: review?(roc)
So how are we losing our grandparent _node_ without its frame (and hence us) going away?
Some property keeps element (and its attributetextnode) alive until presshell
is destroyed. So could perhaps remove that property earlier.
That would be good (in addition to this patch), since otherwise we have a leak for the lifetime of the page, no?
Actually, the patch should be enough.
The only case when the property doesn't get removed before grandparent is 
deleted is when framemanager is about to be destroyed. In that case 
PresShell::NotifyDestroyingFrame doesn't destroy properties for individual 
frames. Properties will be destroyed right after framemanager::Destroy.
Flags: wanted1.9.0.x?
Flags: wanted1.9.0.x+
Flags: blocking1.9.0.4?
Ah, ok.  Can we somehow assert that we're in that situation here?
I don't think there is any easy way to assert.
When properties are deleted in Destroy, document doesn't anymore have pointer
to the relevant presshell.
Hmm.  And we can't assert that because we don't know which shell is the relevant one, I guess.  OK.
Status: NEW → ASSIGNED
Summary: Crash [@ nsAttributeTextNode::UnbindFromTree] with <optgroup> in <xbl:content> → [FIX] Crash [@ nsAttributeTextNode::UnbindFromTree] with <optgroup> in <xbl:content>
Attachment #341607 - Flags: superreview?(roc)
Attachment #341607 - Flags: superreview+
Attachment #341607 - Flags: review?(roc)
Attachment #341607 - Flags: review+
Status: ASSIGNED → RESOLVED
Closed: 16 years ago
Resolution: --- → FIXED
This doesn't seem to affect 1.9.0.x, and it's blamed on a bug (bug 238072) that appears to have been mozilla-central only.

If I'm wrong please renominate
Flags: wanted1.9.0.x-
Flags: wanted1.9.0.x+
Flags: blocking1.9.0.4?
Crash Signature: [@ nsAttributeTextNode::UnbindFromTree]
Group: core-security → core-security-release
Group: core-security-release
You need to log in before you can comment on or make changes to this bug.