Closed Bug 232450 Opened 19 years ago Closed 18 years ago

Crash Printing URL [@nsIFrame::GetNextSibling]

Categories

(Core :: Printing: Output, defect, P1)

x86
Linux
defect

Tracking

()

RESOLVED DUPLICATE of bug 185357
mozilla1.7alpha

People

(Reporter: pete, Assigned: pete)

References

()

Details

(Keywords: crash)

Crash Data

Attachments

(3 files)

Fix for review in hand. Coming up.
Attached patch FIX for crashSplinter Review
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.
Taking bug.
Assignee: core.printing → petejc
Status: NEW → ASSIGNED
Attached file stack trace
Attached file simplified test case
Setting for 1.7 alpha
Severity: normal → critical
Priority: -- → P1
Target Milestone: --- → mozilla1.7alpha
Why is the child count out of sync?
This is probably a duplicate anyway.
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.
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
Attachment #140083 - Flags: review-
Depends on: 185357
See in particular bug 185357 comment 32, which suggests that GetChildCount is
returning a bogus value because the line itself is a corrupt pointer.
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.
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="">
That's presumably the height needed to make it not fit on the page.
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).
Keywords: crash
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]
It think this is fixed by bug 185357

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