[BC] ASSERTION: invalid BC damage area: 'PR_FALSE'

RESOLVED FIXED

Status

()

Core
Layout: Tables
RESOLVED FIXED
12 years ago
6 years ago

People

(Reporter: Martijn Wargers (dead), Unassigned)

Tracking

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

Trunk
assertion, testcase
Points:
---
Dependency tree / graph

Firefox Tracking Flags

(Not tracked)

Details

Attachments

(5 attachments)

(Reporter)

Description

12 years ago
See upcoming testcase.
I get this assertion in my debug build when hovering over the text:
###!!! ASSERTION: invalid BC damage area: 'PR_FALSE', file c:/mozilla/mozilla/la
yout/tables/nsTableFrame.cpp, line 4577
(Reporter)

Comment 1

12 years ago
Created attachment 202242 [details]
testcase

Updated

11 years ago
Blocks: 306663

Updated

11 years ago
Blocks: 323604

Updated

11 years ago
OS: Windows XP → All
Hardware: PC → All

Comment 2

11 years ago
Created attachment 234594 [details]
debug trace

Sometimes we get a zero-width damage area to SetBCDamageArea().
After doing "newRect.width  = PR_MAX(1, newRect.width)" it is possible
that it's an invalid damage area (that reaches beyond the last column).

Comment 3

11 years ago
Created attachment 234595 [details] [diff] [review]
wip

This patch fixes the assertion by adjusting 'x'...
An alternative would be to leave 'x' as is unless it's the last col.

Comment 4

10 years ago
Crashed on this too whilst testing a fx 2.0.0.3 debug build on a Win98 box.  Machine was too hosed to do very much, but what data I got I shall add as an attachment, in case anyone needs it.

Looking at #3 it looks like this one is fixed, though?

Comment 5

10 years ago
Created attachment 262239 [details]
Stack trace of this crash on fx2003/win98se

Comment 6

10 years ago
When testing the top sites with a debug trunk linux build earlier this week, I got this assertion 24985 times on 23524 pages. At the time, it made this assert the 2nd most common but since bug 394384 was fixed, that makes this the top assertion. An example reproducible with today's build is <http://telemundo.yahoo.com/_ylh=X3oDMTFhZWw1b3JpBF9TAzg5NTQyNjEEcGlkAzIwMjcyNAR0ZXN0AzAEdG1wbANlMV9pbmRleA--/r/tmc>
Attachment #234595 - Flags: review?(bernd_mozilla)

Comment 7

10 years ago
>Sometimes we get a zero-width damage area to SetBCDamageArea().

Is that the root cause?

Comment 8

10 years ago
to be more clear, I am afraid of wall papering.

>An alternative would be to leave 'x' as is unless it's the last col.

that sounds better to me, but I would like to get the zero width   SetBCDamageArea() fixed.
Created attachment 309584 [details]
C++ and JS stack of GMail

So I get this in GMail too. Wonder if we should care more about this assertion?

Updated

9 years ago
Blocks: 460637
Comment on attachment 234595 [details] [diff] [review]
wip

There's a better fix in bug 460637.
Attachment #234595 - Flags: review?(bernd_mozilla)

Updated

9 years ago
No longer blocks: 460637
Depends on: 460637

Updated

8 years ago
Summary: ASSERTION: invalid BC damage area: 'PR_FALSE' → [BC] ASSERTION: invalid BC damage area: 'PR_FALSE'

Comment 11

6 years ago
this is fixed by bug 460637, as the testcase involves hovering it makes no sense to check it in as it is.
Status: NEW → RESOLVED
Last Resolved: 6 years ago
Resolution: --- → FIXED
You need to log in before you can comment on or make changes to this bug.