Reproducible crash when printing page [@nsFloaterCacheList::~nsFloaterCacheList()]

RESOLVED FIXED

Status

()

Core
Printing: Output
--
critical
RESOLVED FIXED
16 years ago
16 years ago

People

(Reporter: jraymond, Assigned: Pete Zha)

Tracking

({crash, fixedOEM})

Trunk
crash, fixedOEM
Points:
---

Firefox Tracking Flags

(Not tracked)

Details

(crash signature, URL)

Attachments

(5 attachments)

(Reporter)

Description

16 years ago
Mozilla (1.0-RC3, Solaris, Sparc) crashes every single time I try to print the
page referenced by the URL. This happens both when printing to a file or to a
printer.
-> printing 
Assignee: Matti → rods
Component: Browser-General → Printing
QA Contact: imajes-qa → sujay

Comment 2

16 years ago
confirming...happens on Win 98 also.
Status: UNCONFIRMED → NEW
Ever confirmed: true
OS: Solaris → All
Hardware: Sun → All

Comment 3

16 years ago
It llooks like the "cs" (or CombinedArea) is garbage.

Chris, any ideas?

nsRect::YMost() line 146 + 10 bytes
nsLineBox::CombinedAreaIntersects(const nsRect & {...}) line 345 + 9 bytes
nsBlockFrame::PaintChildren(nsIPresContext * 0x03f43d88, nsIRenderingContext &
{...}, const nsRect & {...}, nsFramePaintLayer eFramePaintLayer_Underlay,
unsigned int 0) line 5634 + 19 bytes
nsBlockFrame::Paint(nsBlockFrame * const 0x03f55368, nsIPresContext *
0x03f43d88, nsIRenderingContext & {...}, const nsRect & {...}, nsFramePaintLayer
eFramePaintLayer_Underlay, unsigned int 0) line 5529
nsContainerFrame::PaintChild(nsIPresContext * 0x03f43d88, nsIRenderingContext &
{...}, const nsRect & {...}, nsIFrame * 0x03f55368, nsFramePaintLayer
eFramePaintLayer_Underlay, unsigned int 0) line 255
nsBlockFrame::PaintChildren(nsIPresContext * 0x03f43d88, nsIRenderingContext &
{...}, const nsRect & {...}, nsFramePaintLayer eFramePaintLayer_Underlay,
unsigned int 0) line 5657
nsBlockFrame::Paint(nsBlockFrame * const 0x03f4926c, nsIPresContext *
0x03f43d88, nsIRenderingContext & {...}, const nsRect & {...}, nsFramePaintLayer
eFramePaintLayer_Underlay, unsigned int 0) line 5529
nsContainerFrame::PaintChild(nsIPresContext * 0x03f43d88, nsIRenderingContext &
{...}, const nsRect & {...}, nsIFrame * 0x03f4926c, nsFramePaintLayer
eFramePaintLayer_Underlay, unsigned int 0) line 255
nsBlockFrame::PaintChildren(nsIPresContext * 0x03f43d88, nsIRenderingContext &
{...}, const nsRect & {...}, nsFramePaintLayer eFramePaintLayer_Underlay,
unsigned int 0) line 5657
nsBlockFrame::Paint(nsBlockFrame * const 0x03f48fe0, nsIPresContext *
0x03f43d88, nsIRenderingContext & {...}, const nsRect & {...}, nsFramePaintLayer
eFramePaintLayer_Underlay, unsigned int 0) line 5529
nsContainerFrame::PaintChild(nsIPresContext * 0x03f43d88, nsIRenderingContext &
{...}, const nsRect & {...}, nsIFrame * 0x03f48fe0, nsFramePaintLayer
eFramePaintLayer_Underlay, unsigned int 0) line 255
nsContainerFrame::PaintChildren(nsIPresContext * 0x03f43d88, nsIRenderingContext
& {...}, const nsRect & {...}, nsFramePaintLayer eFramePaintLayer_Underlay,
unsigned int 0) line 196
nsContainerFrame::Paint(nsContainerFrame * const 0x03f48d88, nsIPresContext *
0x03f43d88, nsIRenderingContext & {...}, const nsRect & {...}, nsFramePaintLayer
eFramePaintLayer_Underlay, unsigned int 0) line 177
nsPageContentFrame::Paint(nsPageContentFrame * const 0x03f48d88, nsIPresContext
* 0x03f43d88, nsIRenderingContext & {...}, const nsRect & {...},
nsFramePaintLayer eFramePaintLayer_Underlay, unsigned int 0) line 181 + 27 bytes
PresShell::Paint(PresShell * const 0x03f45f1c, nsIView * 0x03f4b918,
nsIRenderingContext & {...}, const nsRect & {...}) line 5816 + 36 bytes
nsView::Paint(nsView * const 0x03f4b918, nsIRenderingContext & {...}, const
nsRect & {...}, unsigned int 0, int & 1243912) line 280
nsViewManager::RenderDisplayListElement(DisplayListElement2 * 0x03f43608,
nsIRenderingContext & {...}) line 1192
nsViewManager::RenderViews(nsView * 0x03f49ef0, nsIRenderingContext & {...},
const nsRect & {...}, int & 0) line 1141
nsViewManager::Display(nsViewManager * const 0x03f45cf0, nsIView * 0x03f49ef0,
int 0, int 0, const nsRect & {...}) line 3068
nsSimplePageSequenceFrame::PrintNextPage(nsSimplePageSequenceFrame * const
0x03f48a68, nsIPresContext * 0x03f43d88) line 966
DocumentViewerImpl::PrintPage(nsIPresContext * 0x03f43d88, nsIPrintSettings *
0x03f132f0, PrintObject * 0x03f1f428, int & 1) line 3163 + 22 bytes
Assignee: rods → karnaze

Updated

16 years ago
Severity: normal → critical
Keywords: crash

Comment 4

16 years ago
Created attachment 94737 [details]
testcase

the problem is that a non existent image which cant be rendered fails somehow
while printing

Updated

16 years ago
Blocks: 157675

Comment 5

16 years ago
nsFloaterCacheList::~nsFloaterCacheList() line 1029 + 3 bytes
nsLineBox::ExtraInlineData::~ExtraInlineData() + 18 bytes
nsLineBox::ExtraInlineData::`scalar deleting destructor'(unsigned int
0x00000001) + 15 bytes
nsLineBox::Cleanup() line 129 + 31 bytes
nsLineBox::~nsLineBox() line 85
nsLineBox::`scalar deleting destructor'(unsigned int 0x00000001) + 15 bytes
nsLineBox::Destroy(nsIPresShell * 0x042682d0) line 115 + 28 bytes
nsLineBox::DeleteLineList(nsIPresContext * 0x037d9d20, nsLineList & {...}) line 322
nsBlockFrame::Destroy(nsBlockFrame * const 0x00bbe408, nsIPresContext *
0x037d9d20) line 421 + 16 bytes
nsLineBox::DeleteLineList(nsIPresContext * 0x037d9d20, nsLineList & {...}) line 312
nsBlockFrame::Destroy(nsBlockFrame * const 0x00ec88f8, nsIPresContext *
0x037d9d20) line 421 + 16 bytes
nsLineBox::DeleteLineList(nsIPresContext * 0x037d9d20, nsLineList & {...}) line 312
nsBlockFrame::Destroy(nsBlockFrame * const 0x00ec85c0, nsIPresContext *
0x037d9d20) line 421 + 16 bytes
nsAreaFrame::Destroy(nsAreaFrame * const 0x00ec85c0, nsIPresContext *
0x037d9d20) line 168
nsFrameList::DestroyFrames(nsIPresContext * 0x037d9d20) line 131
nsContainerFrame::Destroy(nsContainerFrame * const 0x00ec8364, nsIPresContext *
0x037d9d20) line 144
nsFrameList::DestroyFrames(nsIPresContext * 0x037d9d20) line 131
nsContainerFrame::Destroy(nsContainerFrame * const 0x00ec8154, nsIPresContext *
0x037d9d20) line 144
nsFrameList::DestroyFrames(nsIPresContext * 0x037d9d20) line 131
nsContainerFrame::Destroy(nsContainerFrame * const 0x00ec8000, nsIPresContext *
0x037d9d20) line 144
nsFrameList::DestroyFrames(nsIPresContext * 0x037d9d20) line 131
nsContainerFrame::Destroy(nsContainerFrame * const 0x00ec7fc4, nsIPresContext *
0x037d9d20) line 144
ViewportFrame::Destroy(ViewportFrame * const 0x00ec7fc4, nsIPresContext *
0x037d9d20) line 154
FrameManager::Destroy(FrameManager * const 0x00cf7cb0) line 510
PresShell::Destroy(PresShell * const 0x042682d0) line 1825
PrintObject::~PrintObject() line 1064
PrintObject::`scalar deleting destructor'(unsigned int 0x00000001) + 15 bytes
PrintData::~PrintData() line 974 + 31 bytes
PrintData::`scalar deleting destructor'(unsigned int 0x00000001) + 15 bytes
DocumentViewerImpl::DonePrintingPages(PrintObject * 0x04285ca0) line 3049 + 31 bytes
nsPagePrintTimer::Notify(nsPagePrintTimer * const 0x04291fd0, nsITimer *
0x042971b0) line 821 + 18 bytes
nsTimerImpl::Fire() line 341
handleTimerEvent(TimerEventType * 0x042912d0) line 399
PL_HandleEvent(PLEvent * 0x042912d0) line 596 + 10 bytes
PL_ProcessPendingEvents(PLEventQueue * 0x00c65960) line 526 + 9 bytes
_md_EventReceiverProc(HWND__ * 0x00000f80, unsigned int 0x0000dda2, unsigned int
0x00000000, long 0x00c65960) line 1077 + 9 bytes
KERNEL32! bff7363b()
KERNEL32! bff94407()
00908cce()
Summary: Reproducible crash when printing page → Reproducible crash when printing page [@nsFloaterCacheList::~nsFloaterCacheList()]

Comment 6

16 years ago
before it crashes it hits the following assertion:

###!!! ASSERTION: prev sibling not in line list: 'Not Reached', file c:/moz_sour
/mozilla/mozilla/layout/html/base/src/nsBlockFrame.cpp, line 4905

Comment 7

16 years ago
it looks as waterson said that we are leaking nsFloaterCache objects - bug 68805
(Assignee)

Comment 8

16 years ago
I investigated this bug and find the reason.
Sometime, image frame need more then one frame to present. So it create a 
continu frame when reflow if it cross page in preview. But, if the image not 
found, system will fire a event to replace the image frame to some other type 
of frame(like InLineFrame). The reason of this bug is because when system 
replace the image frame to InLineFrame, it met an error. The replacing is 
failed, but the imageFrame has already deleted and not remove itself's refrence 
from frame tree. So, when reflow happen on this frame(deleted), browser will 
crash of course since it points to garbage... Crash at FloaterCacheList maybe 
because of the same reason since we have a pointer to garbage and we don't 
aware of it...
Need some time to find out how to resolve it.
(Assignee)

Comment 9

16 years ago
Created attachment 96675 [details] [diff] [review]
proposed patch (Can fix the crash)

We should not create continue frame before the image load complete I think.
(Assignee)

Updated

16 years ago
Attachment #96675 - Attachment description: pupose patch (Can fix the crash) → proposed patch (Can fix the crash)
(Assignee)

Comment 10

16 years ago
Created attachment 96786 [details] [diff] [review]
patch (use STATUS_SIZE_AVAILABLE)

Comment 11

16 years ago
Comment on attachment 96786 [details] [diff] [review]
patch (use STATUS_SIZE_AVAILABLE)

r=karnaze if block and table regression tests run successfully. I would have
used parens differently -

if (isPaginated && (loadStatus & imgIRequest::STATUS_SIZE_AVAILABLE) &&
Attachment #96786 - Flags: review+
Comment on attachment 96786 [details] [diff] [review]
patch (use STATUS_SIZE_AVAILABLE)

sr=bzbarsky if you reparenthesize as karnaze suggests.
Attachment #96786 - Flags: superreview+

Comment 13

16 years ago
I just wanted to mention that this patch regresses at least one case.

If you load a file with an image tag that specifies both width and height, and
for some reason that image has a broken url or fails to load (as test case
attachment 94737 [details] does), we will not allow the broken image to split across
multiple pages.

I'll attach a modified version of the test case to show what I'm talking about.

My concern is that slow loading images will display this same bug. I tried
testing this with an actual image, but I think the fact that the image is
already in the cache at the time I bring PrintPreview up, means that the image
dimensions are always available.

Comment 14

16 years ago
Created attachment 96921 [details]
testcase 2 (same as attachment 94737 [details], but specifies both width and height)

Here's the modified test case that shows the problem I mentioned above when the
patch is used.
hmm... we want to handle that case, no?
(Assignee)

Comment 16

16 years ago
Created attachment 96957 [details] [diff] [review]
patch (fix the problem that kin mentioned)
(Assignee)

Updated

16 years ago
Attachment #96957 - Attachment description: patch (fix the problem that kin metioned) → patch (fix the problem that kin mentioned)
(Assignee)

Comment 17

16 years ago
Jim, this patch need to check in to OEM branch after checking in trunk.
Whiteboard: branchOEM
Comment on attachment 96957 [details] [diff] [review]
patch (fix the problem that kin mentioned)

remove the parens around isPaginated and sr=bzbarsky
Attachment #96957 - Flags: superreview+
(Assignee)

Comment 19

16 years ago
=>
Assignee: karnaze → pete.zha

Comment 20

16 years ago
Comment on attachment 96957 [details] [diff] [review]
patch (fix the problem that kin mentioned)

r=karnaze
Attachment #96957 - Flags: review+
(Assignee)

Comment 21

16 years ago
checked in trunk
(Have go through the block&table regression test and didn't find any problem
caused by this patch)
Status: NEW → RESOLVED
Last Resolved: 16 years ago
Resolution: --- → FIXED
(Assignee)

Comment 22

16 years ago
Jim, can you approval this bug to check in OEM branch?

Updated

16 years ago
Whiteboard: branchOEM → branchOEM+
(Assignee)

Comment 23

16 years ago
checked in NETSCAPE_7_0_OEM_BRANCH (a=jdunn@netscape.com)
Whiteboard: branchOEM+ → branchOEM+ fixedOEM

Updated

16 years ago
Keywords: fixedOEM
Whiteboard: branchOEM+ fixedOEM
Crash Signature: [@nsFloaterCacheList::~nsFloaterCacheList()]
You need to log in before you can comment on or make changes to this bug.