Closed
Bug 317545
Opened 19 years ago
Closed 19 years ago
Crash [@ dddddddd()] called from nsFrameList::DestroyFrames() line 139 involving MathML
Categories
(Core :: Layout, defect)
Core
Layout
Tracking
()
RESOLVED
DUPLICATE
of bug 317544
People
(Reporter: bc, Assigned: rbs)
References
Details
(Keywords: crash, Whiteboard: [sg:dupe 317544])
Crash Data
Attachments
(1 file)
33.60 KB,
text/plain
|
Details |
On the 1.5 branch I crash in a different spot (in a debug build), VerifyContextParent() below a bunch of VerifyStyleTree() calls below nsFrameManager::DebugVerifyStyleTree(). It appears aFrame refers to a deleted object as in the stack below, though.
Status: UNCONFIRMED → NEW
Ever confirmed: true
Whiteboard: [sg:fix] uses freed memory
Updated•19 years ago
|
Flags: blocking1.8.0.1?
Updated•19 years ago
|
Summary: Crash [@ dddddddd()] called from nsFrameList::DestroyFrames() line 139 → Crash [@ dddddddd()] called from nsFrameList::DestroyFrames() line 139 involving MathML
Updated•19 years ago
|
Whiteboard: [sg:fix] uses freed memory → [sg:critical?] uses freed memory
Comment 3•19 years ago
|
||
I get a crash while the status bar counter says 1509, with the same stack as in comment 0. Mac trunk debug.
OS: Windows XP → All
Hardware: PC → All
Whiteboard: [sg:critical?] uses freed memory → [sg:critical] uses freed memory
Updated•19 years ago
|
Flags: blocking1.8.0.2?
Flags: blocking1.8.0.1?
Flags: blocking1.8.0.1-
Comment 4•19 years ago
|
||
I no longer see a crash at 1509, but I do see a consistent crash later, when the status bar counter says 2559 (both Mac trunk debug and Mac trunk nightly). Top of the very long stack trace: nsBlockReflowState::AddFloat nsLineLayout::AddFloat nsLineLayout::ReflowFrame nsInlineFrame::ReflowInlineFrame nsInlineFrame::ReflowFrames nsInlineFrame::Reflow nsLineLayout::ReflowFrame nsMathMLContainerFrame::ReflowForeignChild nsMathMLContainerFrame::ReflowChild nsMathMLTokenFrame::Reflow nsContainerFrame::ReflowChild
Comment 5•19 years ago
|
||
Comment 6•19 years ago
|
||
Sicking says: * We understand what's happening in comment 4, and it involves floating children (or some other descendants) of MathML elements. So we don't need a reduced testcase. This is always a null-deref crash that occurs while building the frame tree. * See also bug 322625, which involves positioned children of MathML elements.
Sorry, i think i'll have to backtack here. The crash in comment 4 isn't as reliable as I initially thought, so there might still be ways to create a frametree that will crash on teardown. Investigating how.
Comment 8•19 years ago
|
||
Yesterday's nightly build crashes with the status bar counter at 2559. A very recent hourly from atlantia doesn't crash at all. Dup of bug 317544. (The patch there disabled floating inside MathML.) *** This bug has been marked as a duplicate of 317544 ***
Status: NEW → RESOLVED
Closed: 19 years ago
Flags: blocking1.8.0.2?
Resolution: --- → DUPLICATE
Updated•18 years ago
|
Whiteboard: [sg:critical] uses freed memory → [sg:dupe 317544] uses freed memory
Updated•18 years ago
|
Whiteboard: [sg:dupe 317544] uses freed memory → [sg:dupe 317544] stirdom testcase
Updated•17 years ago
|
Whiteboard: [sg:dupe 317544] stirdom testcase → [sg:dupe 317544]
Updated•17 years ago
|
Group: security
Updated•13 years ago
|
Crash Signature: [@ dddddddd()]
You need to log in
before you can comment on or make changes to this bug.
Comment 1
•