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

RESOLVED WORKSFORME

Status

()

--
critical
RESOLVED WORKSFORME
11 years ago
11 years ago

People

(Reporter: jruderman, Assigned: rbs)

Tracking

(Blocks: 1 bug, {assertion, crash, testcase})

Trunk
x86
Mac OS X
assertion, crash, testcase
Points:
---
Bug Flags:
in-testsuite +

Firefox Tracking Flags

(Not tracked)

Details

(crash signature)

Attachments

(1 attachment)

653 bytes, application/xhtml+xml
Details
(Reporter)

Description

11 years ago
Created attachment 278760 [details]
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+
(Reporter)

Comment 1

11 years ago
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?
(Reporter)

Comment 2

11 years ago
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+
(Reporter)

Comment 4

11 years ago
Why do you think that?
because it doesn't crash or assert, and we don't much care about MathML DOM regressions?
(Reporter)

Comment 6

11 years ago
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?
(Reporter)

Comment 8

11 years ago
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
Last Resolved: 11 years ago
Resolution: --- → WORKSFORME
(Reporter)

Comment 9

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