Crash called from [@ nsIFrame::GetStyleData] called from nsCSSRendering::PaintBackgroundWithSC

VERIFIED FIXED

Status

()

Core
Layout: Tables
--
critical
VERIFIED FIXED
12 years ago
7 years ago

People

(Reporter: Jesse Ruderman, Unassigned)

Tracking

(Blocks: 1 bug, 4 keywords)

Trunk
PowerPC
Mac OS X
crash, fixed1.8.1, testcase, verified1.8.0.8
Points:
---
Dependency tree / graph
Bug Flags:
in-testsuite +

Firefox Tracking Flags

(Not tracked)

Details

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

Attachments

(2 attachments)

(Reporter)

Description

12 years ago
This testcase crashes a debug build that has the patches for bug 339130, bug 339246, and bug 339315.

The stack traces are somewhat similar to those in bug 339246 and bug 339315.

Before the crash, I see:

2 * ###!!! ASSERTION: invalid number of columns: 'colX < GetColCount()', file /Users/admin/trunk/mozilla/layout/tables/nsTableFrame.cpp, line 1677

1 * ###!!! ASSERTION: prevent array boundary violation: 'colIndex < mNumCols', file /Users/admin/trunk/mozilla/layout/tables/nsTablePainter.cpp, line 416
(Reporter)

Comment 1

12 years ago
Created attachment 225258 [details]
testcase
(Reporter)

Comment 2

12 years ago
Created attachment 225259 [details]
gdb output (mac debug)
(Reporter)

Comment 3

12 years ago
> The stack traces are somewhat similar to those in bug 339246 and bug 339315.

And bug 339165.
Whiteboard: [sg:critical?]

Comment 4

12 years ago
the revised patch in bug 339246 fixes the crash but not the assertion, the assertion is a critical one as it indicates a severe mismatch between the frame structure and the cellmap.  This usually crashes with the first style reference either to noninitialzed memory or for a allready deleted cell position.

Comment 5

12 years ago
attchment 225587 from bug 339246 fixes this entirely, no assertion no crash.
(Reporter)

Updated

12 years ago
Depends on: 339246
(Reporter)

Comment 6

12 years ago
I think bug 341814 has the same stack signature.

Comment 7

12 years ago
marking fixed
Status: NEW → RESOLVED
Last Resolved: 12 years ago
Resolution: --- → FIXED
Yes, current trunk debug build doesn't crash (as normal trunk builds don't crash) on the testcase and I don't see any assertions.
So this is most likely fixed by bug 339246, as bernd said in comment 5.
Status: RESOLVED → VERIFIED
Just tested this on firefox 1.5.0.8 no crash with the testcase.
Keywords: fixed1.8.1, verified1.8.0.8
Group: security
Flags: in-testsuite?
(Reporter)

Comment 10

11 years ago
Crashtest checked in.
Flags: in-testsuite? → in-testsuite+
(Assignee)

Updated

7 years ago
Crash Signature: [@ nsIFrame::GetStyleData]
You need to log in before you can comment on or make changes to this bug.