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

Status: RESOLVED WORKSFORME

(Core :: MathML, defect)

Description

[Jesse Ruderman]

Attachment: 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.

Comment 1

[Jesse Ruderman]

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?

Comment 2

[Jesse Ruderman]

Is that an unrelated regression, or is it the same bug manifesting itself in a new (and less crashy) way?

Comment 3

[Robert O'Callahan (:roc) (email my personal email if necessary)]

beats me... but I think it's safe to remove blocking status.

Comment 4

[Jesse Ruderman]

Why do you think that?

Comment 5

[Robert O'Callahan (:roc) (email my personal email if necessary)]

because it doesn't crash or assert, and we don't much care about MathML DOM regressions?

Comment 6

[Jesse Ruderman]

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?

Comment 7

[Robert O'Callahan (:roc) (email my personal email if necessary)]

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.

Comment 8

[Jesse Ruderman]

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.

Comment 9

[Jesse Ruderman]

Crashtest checked in.