Closed Bug 394150 Opened 13 years ago Closed 13 years ago

This MathML testcase causes a crash [@ nsTextFragment::CharAt] under TextRun code

Categories

(Core :: MathML, defect)

x86
macOS
defect
Not set
critical

Tracking

()

RESOLVED WORKSFORME

People

(Reporter: jruderman, Assigned: rbs)

References

(Blocks 1 open bug)

Details

(Keywords: assertion, crash, testcase)

Crash Data

Attachments

(1 file)

653 bytes, application/xhtml+xml
Details
Attached file testcase
###!!! ASSERTION: overflow list w/o frames: 'mFrames.NotEmpty()', file /Users/jruderman/trunk/mozilla/layout/generic/nsInlineFrame.cpp, line 346

This assertion may or may not be related to the crash.

###!!! ASSERTION: Attempting to allocate excessively large array: 'Error', file nsTArray.cpp, line 68

BuildTextRunsScanner::FlushFrames calls an array's AppendElements method with count = (2^31 - 1).  "Excessively large" is an understatement.

###!!! ASSERTION: bad index: 'PRUint32(aIndex) < mState.mLength', file /Users/jruderman/trunk/mozilla/layout/base/../../content/base/src/nsTextFragment.h, line 184
  
HasTerminalNewline calls nsTextFragment::CharAt(-1) because aFrame->GetContentLength() returns -1.

Firefox crashes in nsTextFragment::CharAt trying to dereference 0xffffffff.  (I'm guessing this happens immediately after the last assertion.)

I don't know how bad dereferencing 0xffffffff is, so I'm filing this bug as security-sensitive.
Flags: blocking1.9?
Flags: blocking1.9? → blocking1.9+
This testcase now triggers:

JavaScript error: , line 0: uncaught exception: [Exception... "Node cannot be inserted at the specified point in the hierarchy"  code: "3" nsresult: "0x80530003 (NS_ERROR_DOM_HIERARCHY_REQUEST_ERR)"  location: "file:///Users/jruderman/lithium/cy.xhtml Line: 12"]

I don't understand why, though.  Does |textNode| not get removed from the document properly at line 11?
Is that an unrelated regression, or is it the same bug manifesting itself in a new (and less crashy) way?
beats me... but I think it's safe to remove blocking status.
Flags: blocking1.9+
Why do you think that?
because it doesn't crash or assert, and we don't much care about MathML DOM regressions?
Do you have reason to believe that all the ways to trigger this crash are now masked by the NS_ERROR_DOM_HIERARCHY_REQUEST_ERR regression?  And that the NS_ERROR_DOM_HIERARCHY_REQUEST_ERR regression won't be fixed?
No and no. But those uncertainties do not justify this being a blocker, IMHO. We should add the test to the new crashtest framework when that's ready, so that it gets tracked.
Flags: in-testsuite?
Oops, the NS_ERROR_DOM_HIERARCHY_REQUEST_ERR is just due to a bug in the testcase: it accidentally calls boom() twice, which results in it trying to append a node to itself.

WFM on trunk, Firefox 2.0.0.0, and Firefox 2.0.0.11.  Since this was WFM a while ago, I'm making it public now, and I'll check in a crashtest in a minute.
Group: security
Status: NEW → RESOLVED
Closed: 13 years ago
Resolution: --- → WORKSFORME
Crashtest checked in.
Flags: in-testsuite? → in-testsuite+
Crash Signature: [@ nsTextFragment::CharAt]
You need to log in before you can comment on or make changes to this bug.