Crash [@ GetContentRect] with -moz-column, fieldset

RESOLVED FIXED

Status

()

Core
Layout
P3
normal
RESOLVED FIXED
9 years ago
3 years ago

People

(Reporter: dholbert, Assigned: roc)

Tracking

(4 keywords)

Trunk
x86
Linux
assertion, crash, regression, testcase
Points:
---
Dependency tree / graph
Bug Flags:
blocking1.9.1 -
wanted1.9.1 +
wanted1.9.0.x ?
wanted1.8.1.x -

Firefox Tracking Flags

(Not tracked)

Details

(Whiteboard: [sg:critical], crash signature, URL)

Attachments

(3 attachments)

Created attachment 356745 [details]
testcase 1 (crashes Firefox when loaded)

This testcase crashes today's nightly mozilla-central build:
Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9.2a1pre) Gecko/20090113 Minefield/3.2a1pre

Note: This bug's testcase is exactly attachment 356643 [details] from bug 472919; however, it has a different regression range from that bug's original testcase, so I'm splitting it into its own bug, per bug 472919 comment 6.

See also attachment 356639 [details], a slightly-less-reduced testcase with the same regression range as this one.

Regression range for this testcase:
Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9b4pre) Gecko/2008021304
Minefield/3.0b4pre
Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9b4pre) Gecko/2008021404
Minefield/3.0b4pre
Bonsai link: http://tinyurl.com/9ew7se  -- maybe bug 416018? (cairo upgrade)
Whiteboard: [sg:critical]
Created attachment 356747 [details]
backtrace for crash

Here's a backtrace for the crash on testcase 1.
(Note: this is the same as the backtrace I previously posted on bug 472919, attachment 356735 [details])

Also, here's a crash report for the crash:
http://crash-stats.mozilla.com/report/index/7357f444-e4e7-4eff-8d64-9dbad2090113?p=1
(In reply to comment #0)
> Bonsai link: http://tinyurl.com/9ew7se  -- maybe bug 416018? (cairo upgrade)

Nope -- I tested a few CVS checkouts from the regression range, and it looks like this was caused by bug 400813.

I get a crash with a CVS checkout taken just after bug 400813's update landed (2008-02-14 02:10), but if I back out the patch per the commands at http://tinyurl.com/9hxxxe, I get no crash.
Blocks: 400813
The following assertion accompanies the crash, both in a debug build from today and in a debug build from just after bug 400813 landed.  The assertion does not appear before bug 400813 landed, though.
###!!! ASSERTION: frame was not removed from primary frame map before destruction or was readded to map after being removed: 'Not Reached', file nsFrameManager.cpp, line 711
Keywords: assertion, crash
Created attachment 356842 [details] [diff] [review]
workaround

(Note: I'm not intending this as an actual fix -- at this point it's just a demo of what's going on.)

This patch works around the crash.  It reverts one line from bug 400813's patch -- the line that caused this issue.

The workaround is just this:
-      if (psd->mHasNonemptyContent || preMode || foundLI) {
+      if ((psd->mX != psd->mLeftEdge) || preMode || foundLI) {

(where the +'d line is the restored code from before bug 400813 landed)

On this bug's testcase, we hit this line with psd->mX == 0 and psd->mLeftEdge == 0, but with psd->mHasNonemptyContent == 1.

So in current mozilla-central, the condition passes (and we assert and crash later on), but with the workaround, the condition fails (and we don't assert or crash).  So, the assertion+crash are triggered in part by running the code immediately below that if-check.
Flags: wanted1.9.0.x?
Flags: wanted1.8.1.x-

Comment 5

9 years ago
Nominating for blocking1.9.1 -- calling 0xdddddddd is especially bad.

Is the workaround appropriate for checkin as a stopgap, or did you only attach it for testing purposes?
Flags: blocking1.9.1?
I attached the workaround for testing / demonstrating-what's-going-on purposes.  I'm not sure if landing it would break other stuff (or regress parts of bug 400813).
Depends on: 463350
(In reply to comment #3)
> ###!!! ASSERTION: frame was not removed from primary frame map before
> destruction or was readded to map after being removed: 'Not Reached', file
> nsFrameManager.cpp, line 711

That suggests this may be the same problem as bug 463350, although I didn't check the stack.
Flags: blocking1.9.1? → blocking1.9.1+
Priority: -- → P3
Flags: wanted1.9.1+
Flags: blocking1.9.1-
Flags: blocking1.9.1+
(In reply to comment #7)
> That suggests this may be the same problem as bug 463350, although I didn't
> check the stack.

That bug regressed a few months earlier than this one, FWIW.  So while the crashes may be related, there's at least something slightly different going on here.
Fixed by checkin for bug 463350
Assignee: nobody → roc
Status: NEW → RESOLVED
Last Resolved: 9 years ago
Resolution: --- → FIXED
Crash Signature: [@ GetContentRect]
Group: core-security
You need to log in before you can comment on or make changes to this bug.