Closed
Bug 680687
Opened 13 years ago
Closed 13 years ago
Crash [@ nsSVGSwitchElement::FindActiveChild] after GC
Categories
(Core :: SVG, defect)
Tracking
()
VERIFIED
FIXED
Tracking | Status | |
---|---|---|
firefox7 | - | unaffected |
firefox8 | - | unaffected |
firefox9 | + | fixed |
firefox10 | + | fixed |
status1.9.2 | --- | unaffected |
People
(Reporter: jruderman, Assigned: smaug)
References
Details
(Keywords: crash, testcase, verified-beta, Whiteboard: [sg:critical?][qa!] possible regression from 335998?)
Crash Data
Attachments
(3 files)
1. Install https://www.squarefree.com/extensions/domFuzzLite2.xpi
2. Load the testcase.
Result:
Debug: Crash [@ nsSVGSwitchElement::FindActiveChild] calling 0x0 ?
Opt: Crash [@ nsNodeUtils::ContentRemoved] calling bogus ?
The GC pattern makes me wonder if this is related to bug 335998 being fixed.
Reporter | ||
Comment 1•13 years ago
|
||
Assignee | ||
Comment 2•13 years ago
|
||
Um, nsSVGSwitchElement overrides InsertChildAt/RemoveChildAt
Assignee: nobody → Olli.Pettay
Assignee | ||
Comment 3•13 years ago
|
||
The changes shouldn't be in hot paths, and this is the right thing to do.
Yet, it is unfortunate to add new Addref/releases.
Attachment #554672 -
Flags: review?(jst)
Assignee | ||
Comment 4•13 years ago
|
||
...so I patched all the cases I found where similar problem could occur,
not only nsGenericElement.
Assignee | ||
Comment 5•13 years ago
|
||
And note, in parser eTreeOpAppendChildrenToNewParent
it is really the node which needs to be strong.
Updated•13 years ago
|
Whiteboard: [sg:critical?] possible regression from 335998?
Updated•13 years ago
|
Attachment #554672 -
Flags: review?(jst) → review+
Assignee | ||
Comment 6•13 years ago
|
||
Status: NEW → RESOLVED
Closed: 13 years ago
Resolution: --- → FIXED
Comment 7•13 years ago
|
||
Olli, this is something we could take in 8, right?
status-firefox10:
--- → fixed
status-firefox7:
--- → wontfix
status-firefox8:
--- → affected
status-firefox9:
--- → fixed
tracking-firefox10:
--- → +
tracking-firefox7:
--- → +
tracking-firefox8:
--- → +
tracking-firefox9:
--- → +
Comment 8•13 years ago
|
||
I could not reproduce the crash using the testcase on Firefox 8 (beta), is it possible this was introduced by something in Firefox 9 rather than bug 335998 as Jesse guessed? Didn't see any script errors running the testcase so I think I ran it correctly, but I'd be happier if Jesse concurred. It's also possible something else that landed on both Fx9 and 8 masked/fixed this, or something that landed earlier on Fx9 that un-masked the underlying problem.
Assignee | ||
Comment 9•13 years ago
|
||
The patch for bug 335998 is not in FF8.
Assignee | ||
Comment 10•13 years ago
|
||
I don't see any reason to take this to FF8.
Comment 11•13 years ago
|
||
Excellent, thanks Olli!
Whiteboard: [sg:critical?] possible regression from 335998? → [sg:critical?][qa+] possible regression from 335998?
Comment 12•13 years ago
|
||
Verified fixed using Mozilla/5.0 (Macintosh; Intel Mac OS X 10.6; rv:11.0a1) Gecko/20111122 Firefox/11.0a1. I verified by following the steps in Comment 0.
Status: RESOLVED → VERIFIED
Comment 13•13 years ago
|
||
(In reply to Marcia Knous [:marcia] from comment #12)
> Verified fixed using Mozilla/5.0 (Macintosh; Intel Mac OS X 10.6; rv:11.0a1)
> Gecko/20111122 Firefox/11.0a1. I verified by following the steps in Comment
> 0.
Thanks Marcia. If you have time, could you please also verify on Firefox 9 and 10?
Updated•13 years ago
|
status1.9.2:
--- → unaffected
Comment 14•13 years ago
|
||
Verified fixed using Mozilla/5.0 (Macintosh; Intel Mac OS X 10.6; rv:9.0) Gecko/20100101 Firefox/9.0. The extension is not compatible with Aurora, so I am not sure if forcing compat would be a fair test.
Keywords: verified-beta
Whiteboard: [sg:critical?][qa+] possible regression from 335998? → [sg:critical?][qa!] possible regression from 335998?
Updated•13 years ago
|
Group: core-security
You need to log in
before you can comment on or make changes to this bug.
Description
•