Crash Printing URL [@nsIFrame::GetNextSibling]

RESOLVED DUPLICATE of bug 185357

Status

()

P1
critical
RESOLVED DUPLICATE of bug 185357
15 years ago
15 years ago

People

(Reporter: pete, Assigned: pete)

Tracking

({crash})

Trunk
mozilla1.7alpha
x86
Linux
crash
Points:
---

Firefox Tracking Flags

(Not tracked)

Details

(crash signature, URL)

Attachments

(3 attachments)

(Assignee)

Description

15 years ago
Fix for review in hand. Coming up.
(Assignee)

Comment 1

15 years ago
Created attachment 140083 [details] [diff] [review]
FIX for crash

Diff is from 1.6 branch, but should work on the trunk easy enough.

I need some names for peer review so I can check this fix in.
(Assignee)

Comment 2

15 years ago
Taking bug.
Assignee: core.printing → petejc
(Assignee)

Updated

15 years ago
Status: NEW → ASSIGNED
(Assignee)

Comment 3

15 years ago
Created attachment 140084 [details]
stack trace
(Assignee)

Comment 4

15 years ago
Created attachment 140085 [details]
simplified test case
(Assignee)

Comment 5

15 years ago
Setting for 1.7 alpha
Severity: normal → critical
Priority: -- → P1
Target Milestone: --- → mozilla1.7alpha
I suspect based on previous debugging in another bug that you're dealing with
corrupt data well before you get to the code you're modifying, and that this
might be lucky enough to fix the crash in some cases, but not all.
(Assignee)

Comment 9

15 years ago
Beats me. No harm in testing for a null pointer.

The simplified test case I posted should crash as well.
There is harm in testing for a null pointer:
 * it makes the compiled code bigger
 * it makes the code larger, and thus harder to understand
 * it makes the code confusing, since the code is designed so that this pointer
could never be null
 * it hides real problems -- a fix in the right place might solve all the
problems that incorrect null checks in twenty different places would solve, and
we're better off fixing the real problems
See in particular bug 185357 comment 32, which suggests that GetChildCount is
returning a bogus value because the line itself is a corrupt pointer.
(Assignee)

Comment 12

15 years ago
Yup

**** GetChildCount(3)
**** GetChildCount(1)
**** GetChildCount(1)
**** GetChildCount(1)
**** GetChildCount(3)
**** GetChildCount(2)
**** GetChildCount(1)
**** GetChildCount(1)
**** GetChildCount(1)
**** GetChildCount(2)
**** GetChildCount(1)
**** GetChildCount(1)
###!!! ASSERTION: running past end: 'mCurrent != mListLink', file nsLineBox.h,
line 545
Break: at file nsLineBox.h, line 545
**** GetChildCount(34761)
**** GetChildCount(1)
**** GetChildCount(1)
**** GetChildCount(1)
**** GetChildCount(1)
And the stack for the assertion shows what code is accessing something that's
not a line box.
(Assignee)

Comment 14

15 years ago
Using the html test case here.

The assertion happens exactly at this html source location:

  <img src="" height="280" align="right">

It seems that if the height is 275 or greater (in this case 280), the
GetChildCount() is a bogus value. If I lower the height to 274, no asertion
occurs and .GetChildCount() is calid data.


###!!! ASSERTION: running past end: 'mCurrent != mListLink', file nsLineBox.h,
line 545
Break: at file nsLineBox.h, line 545
GetChildCount(278837)
<img align="right" height="280" src="">
(Assignee)

Comment 16

15 years ago
Ok, so that fact that when the height of the image pushes the threshold from a
single page to two pages, it is cusing the child count data to be corrupt.

So, a guess would be in the code that implements the geometry layout for
postscript pages might be a place to start.

This crash will happen in Print Preview as well (if that isn't already obvious).

Updated

15 years ago
Keywords: crash

Comment 17

15 years ago
Comment on attachment 140085 [details]
simplified test case

The testcase prints OK with mozilla1.7b(Installer with TB) and Xprint 009... is
it possible that the bug is gone now ?
Summary: Crash Printing URL → Crash Printing URL [@nsIFrame::GetNextSibling]

Comment 18

15 years ago
It think this is fixed by bug 185357

*** This bug has been marked as a duplicate of 185357 ***
Status: ASSIGNED → RESOLVED
Last Resolved: 15 years ago
Resolution: --- → DUPLICATE
Crash Signature: [@nsIFrame::GetNextSibling]
You need to log in before you can comment on or make changes to this bug.