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

RESOLVED FIXED

Status

()

defect
P1
critical
RESOLVED FIXED
11 years ago
4 years ago

People

(Reporter: jruderman, Assigned: smaug)

Tracking

(Blocks 2 bugs, {crash, testcase})

Trunk
x86
macOS
Points:
---
Dependency tree / graph
Bug Flags:
blocking1.9.1 -
wanted1.9.1 +
wanted1.9.0.x -

Firefox Tracking Flags

(Not tracked)

Details

(Whiteboard: [sg:critical?], crash signature)

Attachments

(2 attachments)

Reporter

Description

11 years ago
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.
Reporter

Updated

11 years ago
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
Assignee

Comment 4

11 years ago
Posted 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?
Assignee

Comment 6

11 years ago
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?
Assignee

Comment 8

11 years ago
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?
Assignee

Comment 10

11 years ago
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.
Assignee

Updated

11 years ago
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+
Assignee

Updated

11 years ago
Status: ASSIGNED → RESOLVED
Closed: 11 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]

Updated

4 years ago
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.