Note: There are a few cases of duplicates in user autocompletion which are being worked on.

"Assertion failure: checkmTextrun ? !mTextRun : !Properties().Get(UninflatedTextRunProperty())" with font inflation, -moz-column

VERIFIED FIXED in Firefox 17



5 years ago
4 years ago


(Reporter: Jesse Ruderman, Assigned: Mats Palmgren (vacation - back in August))


(Depends on: 1 bug, Blocks: 2 bugs, 4 keywords)

assertion, crash, sec-critical, testcase
Dependency tree / graph
Bug Flags:
in-testsuite +

Firefox Tracking Flags

(firefox16 affected, firefox17+ verified, firefox18+ verified, firefox-esr10 unaffected, firefox-esr17 verified)


(Whiteboard: [adv-track-main17+])


(6 attachments)



5 years ago
Created attachment 661662 [details]
testcase (requires pref) (crashes Firefox)

  user_pref("font.size.inflation.emPerLine", 15);
Loading the testcase triggers:

Assertion failure: checkmTextrun ? !mTextRun : !Properties().Get(UninflatedTextRunProperty()), at /Users/jruderman/trees/mozilla-central/layout/generic/nsTextFrameThebes.cpp:4373

Security-sensitive because the assertion was added in a security-sensitive bug.

Comment 1

5 years ago
Created attachment 661664 [details]
Created attachment 661859 [details]
stack + frame tree

RemoveInFlows is trying to destroy the text frame marked red.

This is pretty much the same situation as in bug 756241,
but with a block parent.  On line 7300, we explicitly excluded
this case...  I don't recall why we did that - maybe we thought
that FRAMES_ARE_EMPTY would prevent the same crash in blocks?

roc, do you recall?  do you see any reason why doing that block
unconditionally won't work?  (it fixes the crash locally)
Assignee: nobody → matspal
Created attachment 661861 [details] [diff] [review]
Attachment #661861 - Flags: review?(roc)
Created attachment 661862 [details] [diff] [review]
fix (wdiff)
Created attachment 661863 [details]
before/after frame trees with the fix
Flags: in-testsuite?
Keywords: crash, sec-critical
OS: Mac OS X → All
Hardware: x86_64 → All
Blocks: 756241
Comment on attachment 661861 [details] [diff] [review]

Review of attachment 661861 [details] [diff] [review]:

I don't know why we excluded the parent block here.

Clearing text runs should be safe in any case.
Attachment #661861 - Flags: review?(roc) → review+
Last Resolved: 5 years ago
status-firefox18: --- → fixed
Resolution: --- → FIXED
Target Milestone: --- → mozilla18
status-firefox-esr10: --- → unaffected
status-firefox16: --- → affected
status-firefox17: --- → affected
tracking-firefox17: --- → +
tracking-firefox18: --- → +

Comment 10

5 years ago
This is marked sec-critical and tracking-firefox17+, are we planning to land this on beta?
Comment on attachment 661861 [details] [diff] [review]

[Approval Request Comment]
Bug caused by (feature/regressing bug #): 
User impact if declined: sec-critical crash
Testing completed (on m-c, etc.): on trunk/aurora since 2012-09-18
Risk to taking this patch (and alternatives if risky): low risk
String or UUID changes made by this patch: none
Attachment #661861 - Flags: approval-mozilla-beta?
Please also mark sec-approval? on this patch since it's sec-critical and looking for uplift we'll want to get that feedback as well to be able to time landing.
Comment on attachment 661861 [details] [diff] [review]

Again, my bad, this doesn't need sec-approval please go ahead with uplift.
Attachment #661861 - Flags: approval-mozilla-beta? → approval-mozilla-beta+
status-firefox17: affected → fixed
status-firefox-esr17: --- → fixed
Whiteboard: [adv-track-main17+]
Keywords: verifyme
Kamil, can you please make an attempt at verifying this is fixed? It should be fixed in Firefox 17, 17esr, and 18beta.
When going through the following issue using the test case HTML file attached above, I receive the following crash every single time:

###!!! ASSERTION: math on NS_UNCONSTRAINEDSIZE: 'NS_UNCONSTRAINEDSIZE != aState.mReflowState.mComputedBorderPadding.left && NS_UNCONSTRAINEDSIZE != aState.mReflowState.ComputedWidth()', file e:/builds/moz2_slave/m-rel-w32-dbg/build/layout/generic/nsBlockFrame.cpp, line 1629

The error doesn't match the one that has been posted above, but it's making it difficult to test as firefox crashes whenever the .HTML file is opened. Is this the same issue as above just a different error message? Or is there something I am doing incorrectly?

I also set the following user preference as mentioned above: ("font.size.inflation.emPerLine", 15)

Received the above assertion crash when going through the following builds:

Firefox 16:
Firefox 17:
Firefox 18:

Comment 17

5 years ago
(In reply to Kamil Jozwiak [:kjozwiak] from comment #16)

That's a non-fatal assertion, so you shouldn't experience it as a crash.  If you're on Windows, you might need to run with XPCOM_DEBUG_BREAK=warn.

(I tend to ignore any assertion that mentions NS_UNCONSTRAINEDSIZE, due to bug 575011.)
Kamil, can you please retest with XPCOM_DEBUG_BREAK=warn as Jesse suggests?

Jesse, is this an environment variable that needs to be set or does this need to be set elsewhere?

Comment 19

5 years ago
Yes, it's an environment variable.
Following prerequisites used before testing builds:
- Environment Variable: XPCOM_DEBUG_BREAK=warn
- about:config: ("font.size.inflation.emPerLine", 15)

Firefox 16 (Issue Reproduced):
Received Error: Assertion failure: checkmTextrun ? !mTextRun : !Properties().Get(UninflatedTextRunProperty()), at e:/builds/moz2_slave/m-rel-w32-dbg/build/layout/generic/nsTextFrameThebes.cpp:4248

Once the issue was reproduced several times with Firefox 16, used the following builds to ensure that the issue has been resolved:

Firefox 17 (Resolved):
- Ran through Firefox 17 and didn't receive the assertion crash that was reproduced with Firefox 16. Ensured that the above assertion failure didn't appear in the log file

Firefox 17esrpre BETA (Resolved):
- Ran through Firefox 17esrpre BETA and didn't receive the assertion crash that was reproduced with Firefox 16. Ensured that the above assertion failure didn't appear in the log file

Firefox 18 BETA (Resolved):
- Ran through Firefox 18 BETA and didn't receive the assertion crash that was reproduced with Firefox 16. Ensured that the above assertion failure didn't appear in the log file
Thank you, Kamil. I think this is sufficient to call this verified fixed. Jesse (or anyone else) feel free to revert my flag changes if there's something else we can do.
status-firefox17: fixed → verified
status-firefox18: fixed → verified
status-firefox-esr17: fixed → verified
Keywords: verifyme
Group: core-security
Crash test:
Flags: in-testsuite? → in-testsuite+


4 years ago
Depends on: 885444
You need to log in before you can comment on or make changes to this bug.