89236 - printing is producing crash

Status: VERIFIED FIXED

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

Description

[Adam Hauner]

Mozilla/5.0 (Windows; U; WinNT4.0; en-US; rv:0.9.2+) Gecko/20010703

After selecting printer, setting print properties and clicking on "Print" 
Mozilla crashes.

(FYI: In NN4.77 is problem same.)

Comment 1

[Asa Dotzler [:asa]]

If you are crashing in Mozilla and you want the bug to be fixed the best thing
you can do is to attach a stacktrace. If you're not building yourself you are
not out of luck.  Mozilla (thanks to a very cool donation from Netscape)
releases nightly and milestone builds with Full Circle's Talkback. Talkback
should catch most crashes and offer to send in a crash report. I can retrieve
that crash report and attach it to your bug report if you provide either the
Incident ID (you can get it by running the talkback program from
/components/talkback/) or you can let me know the email address you used to
submit the report and the time of sending. Thanks for your help in testing
Mozilla and reporting bugs.

Comment 2

[Adam Hauner]

Attachment: Netscape Feedback crash details

Comment 3

[Keyser Sose]

We need the actual id for us to be able to help.

Comment 4

[Adam Hauner]

> We need the actual id for us to be able to help.

Incident ID? I'm sorry, but in talkback are just crashes of actual nightbuild, 
older was deleted with reinstalation.

I posted 'Netscape Feedback crash details' (160 kB textfile) as attachment to 
this bug.

Incident was reported with my e-mail ([e-mail]) and with URL 
http://www.mujweb.cz/www/brdy/mista/m_babka/m_babka.htm

Comment 5

[Adam Hauner]

I reproduced same error and Incident ID was TB32760818Y (11. 7. 2001 8:18).
E-mail and URL are same.

Comment 6

[sujay]

I just tried printing using 7/10 branch build and it prints fine
w/o crash.

Comment 7

[sujay]

ignore my previous comment.

I crash on both branch and trunk using 7/11 builds when I try
and print that page.

Comment 8

[Asa Dotzler [:asa]]

Incident ID 32760818
Stack Signature 0x00000010 76400ce8
Bug ID
Trigger Time 2001-07-10 23:13:35
User Comments trying to print on the printer
Build ID 2001070710
Product ID MozillaTrunk
Platform ID Win32
Stack Trace
0x00000010
nsContainerFrame::Destroy 
[d:\builds\seamonkey\mozilla\layout\html\base\src\nsContainerFrame.cpp, line 
116]
nsTableOuterFrame::Destroy 
[d:\builds\seamonkey\mozilla\layout\html\table\src\nsTableOuterFrame.cpp, line 
68]
nsFrameList::DestroyFrames 
[d:\builds\seamonkey\mozilla\layout\base\src\nsFrameList.cpp, line 116]
nsBlockFrame::Destroy 
[d:\builds\seamonkey\mozilla\layout\html\base\src\nsBlockFrame.cpp, line 313]
nsLineBox::DeleteLineList 
[d:\builds\seamonkey\mozilla\layout\html\base\src\nsLineBox.cpp, line 252]
nsBlockFrame::Destroy 
[d:\builds\seamonkey\mozilla\layout\html\base\src\nsBlockFrame.cpp, line 315]
nsFrameList::DestroyFrames 
[d:\builds\seamonkey\mozilla\layout\base\src\nsFrameList.cpp, line 116]
nsContainerFrame::Destroy 
[d:\builds\seamonkey\mozilla\layout\html\base\src\nsContainerFrame.cpp, line 
119]
nsFrameList::DestroyFrames 
[d:\builds\seamonkey\mozilla\layout\base\src\nsFrameList.cpp, line 116]
nsContainerFrame::Destroy 
[d:\builds\seamonkey\mozilla\layout\html\base\src\nsContainerFrame.cpp, line 
119]
nsFrameList::DestroyFrames 
[d:\builds\seamonkey\mozilla\layout\base\src\nsFrameList.cpp, line 116]
nsContainerFrame::Destroy 
[d:\builds\seamonkey\mozilla\layout\html\base\src\nsContainerFrame.cpp, line 
119]
ViewportFrame::Destroy 
[d:\builds\seamonkey\mozilla\layout\html\base\src\nsViewportFrame.cpp, line 142]
FrameManager::Destroy 
[d:\builds\seamonkey\mozilla\layout\html\base\src\nsFrameManager.cpp, line 457]
PresShell::~PresShell 
[d:\builds\seamonkey\mozilla\layout\html\base\src\nsPresShell.cpp, line 1555]
PresShell::`scalar deleting destructor'
PresShell::Release 
[d:\builds\seamonkey\mozilla\layout\html\base\src\nsPresShell.cpp, line 1442]
PrintObject::~PrintObject 
[d:\builds\seamonkey\mozilla\content\base\src\nsDocumentViewer.cpp, line 777]
PrintObject::`scalar deleting destructor'
PrintData::~PrintData 
[d:\builds\seamonkey\mozilla\content\base\src\nsDocumentViewer.cpp, line 722]
PrintData::`scalar deleting destructor'
DocumentViewerImpl::DonePrintingPages 
[d:\builds\seamonkey\mozilla\content\base\src\nsDocumentViewer.cpp, line 2104]
nsPagePrintTimer::Notify 
[d:\builds\seamonkey\mozilla\content\base\src\nsDocumentViewer.cpp, line 618]
nsTimer::Fire [d:\builds\seamonkey\mozilla\widget\timer\src\windows\nsTimer.cpp, 
line 200]
nsTimerManager::FireNextReadyTimer 
[d:\builds\seamonkey\mozilla\widget\timer\src\windows\nsTimerManager.cpp, line 
117]
nsAppShell::Run [d:\builds\seamonkey\mozilla\widget\src\windows\nsAppShell.cpp, 
line 118]
nsAppShellService::Run 
[d:\builds\seamonkey\mozilla\xpfe\appshell\src\nsAppShellService.cpp, line 419]
main1 [d:\builds\seamonkey\mozilla\xpfe\bootstrap\nsAppRunner.cpp, line 1181]
main [d:\builds\seamonkey\mozilla\xpfe\bootstrap\nsAppRunner.cpp, line 1481]
WinMain [d:\builds\seamonkey\mozilla\xpfe\bootstrap\nsAppRunner.cpp, line 1499]
WinMainCRTStartup()
KERNEL32.dll + 0x1b9ea (0x77f1b9ea)

Comment 9

[Keyser Sose]

Marking NEW.

Comment 10

[dcone (gone)]

I see a problem in the table code.  Chris can you look at this.

Comment 11

[karnaze (gone)]

I see the crash on the m0.9.2 branch but not the trunk. A relatively positioned 
table has a view and that view has already been destroyed when 
nsContainerFrame::Destroy on the nsTableFrame tries to destroy it. CCing 
attinasi, dbaron, waterson who may have some insight.

dcone, reassigning back to you for more analysis.

Comment 12

[dcone (gone)]

can you start looking at this.. maybee reduce the test case and find out who is 
destroying this view before it should be.

Comment 13

[David Baron :dbaron: (⌚️UTC-4, no longer working on Mozilla)]

A likely reason would be that the view manager was destroyed -- which would
happen when it's released by the printing code.

Comment 14

[Alexandru Savulov]

reassigning to dcone. 
Don: this is the one that is fixed on the trunk, but not on 0.9.2 branch

Comment 15

[dcone (gone)]

to dcone for analysis.

Comment 16

[David Baron :dbaron: (⌚️UTC-4, no longer working on Mozilla)]

Attachment: patch to copy trunk changes for bug 80203, etc., onto branch

Comment 17

[rods (gone)]

This is still crashing on the trunk....

The view it is getting is garbage.

here is the stack trace:
nsFrameList::DestroyFrames(nsIPresContext * 0x02ebb780) line 116
nsContainerFrame::Destroy(nsContainerFrame * const 0x029666c0, nsIPresContext * 
0x02ebb780) line 120
ViewportFrame::Destroy(ViewportFrame * const 0x029666c0, nsIPresContext * 
0x02ebb780) line 142
FrameManager::Destroy(FrameManager * const 0x02eba680) line 459
PresShell::Destroy(PresShell * const 0x02ebc870) line 1700
PrintData::~PrintData() line 702
PrintData::`scalar deleting destructor'(unsigned int 1) + 15 bytes
DocumentViewerImpl::DonePrintingPages(PrintObject * 0x02ebd720) line 2135 + 31 
bytes
nsPagePrintTimer::Notify(nsPagePrintTimer * const 0x028525b0, nsITimer * 
0x02f40820) line 596 + 18 bytes
nsTimer::Fire() line 200
FireTimeout(HWND__ * 0x00000000, unsigned int 275, unsigned int 1875, unsigned 
long 18187250) line 78
USER32! 77e7185c()
main(int 1, char * * 0x00bb4590) line 157 + 11 bytes
mainCRTStartup() line 338 + 17 bytes

Comment 18

[David Baron :dbaron: (⌚️UTC-4, no longer working on Mozilla)]

I think there's a separate bug (marked topcrash) for some of the crashes on the
trunk.  Are the trunk crashes a recent regression?

rod:  If you catch it in the debugger again, could you have a look at what the
state of the view manager owned by the PrintData is?

Comment 19

[David Baron :dbaron: (⌚️UTC-4, no longer working on Mozilla)]

The difference between the crash rod reported and the one this bug originally
covered was that the one originally covered by this bug was the one caused by
destroying the pres shell owned by the PrintObject.  The crash rod reported was
during the destruction of the pres shell owned by the PrintData.

Why does the PrintData have its own pres shell, although it's never used beyond
doing an InitialReflow?

Comment 20

[dcone (gone)]

Each PrintData represents a Frame in a frameset for example.. that will get 
printed.  Each Frame(or PrintData) needs to do that InitialReflow.. and when 
that is called.. printing is pretty much over for that object..and will get 
destroyed soon.

Should there be a boolean in the PresShell that an object who has a strong 
reference to the PresShell can ask it if the Destroy() has been called already, 
which could stop the Destroy from being called twice.  

Comment 21

[rods (gone)]

Actually there is a PrintObject for each document being printed (FrameSet-Frame, 
etc.) and there is a single PrintData object which holds all the printing 
"state" information so the DocViewer doesn't have to incur the memory overhead 
when not printing.

Comment 22

[rods (gone)]

No, what is facinating about the recent crash I posted is: Why do the the 
container frame have a view? I thought there was only supose to be one view when 
printing, the "main" view.

The problem is that the table have this style set:

style="position: relative; float: left"

which apparently gives them a view when printing.

I'll look into this some more.

Comment 23

[dcone (gone)]

I installed the patch.. and I crash on startup.. so I guess that patch will not 
work.

Comment 24

[Kevin McCluskey (gone)]

Reassigning to Rod.

Comment 25

[Kevin McCluskey (gone)]

Adding nsbranch+ keyword

Comment 26

[karnaze (gone)]

Kin, is this related to bug 92215.

Comment 27

[kinmoz]

This doesn't look like it's related to bug 92215, since my fix for that bug 
never gets hit/activated.

I don't crash when actually printing the URL above ... I'm using a fake printer 
that outputs LaserJet 5 PostScript to a file. However, I can get it to crash 
with Asa's stack trace if I cancel out of the dialog that asks me where to save 
the printer output file.

I can help look into this after I verify that my fix for 92215 doesn't regress 
anything.

Comment 28

[kinmoz]

Taking from rods.

Comment 29

[kinmoz]

Attachment: Minimal Test Case

Comment 30

[kinmoz]

Attachment: Patch Rev 1 (Make DrainOverlowLines() reparent out-of-flow frames too)

Comment 31

[kinmoz]

I just attatched a fix that prevents this crasher.

The problem seems to be that nsBlockFrame::DrainOverflowLines() reparents the 
overflow frames (and their views) from the previous block, but don't do it for 
the out-of-flow frames of placeholders.

In the case of printing, this leaves the view, associated with a floating table, 
in the view hierarchy for the 1st page, when it should actually be in the view 
hierarchy of the 2nd page.

So when we delete the print objects, the views for the 1st page go away, causing 
the view to be free'd before the floater frame is deleted.

So are there any assumptions in layout that the mParent pointer of out-of-flow 
frames always point to the Primary frame? Or is it ok for them to point to the 
continuing frame that is the parent of the placeholder ... which is what Patch 
Rev 1 does?

I also noted that we do this reparenting thing in several places in 
nsBlockFrame. If my fix is the right thing to do, should I update those places 
too?

By the way things print and look fine with this fix. :-)

Comment 32

[David Baron :dbaron: (⌚️UTC-4, no longer working on Mozilla)]

Reparenting through a placeholder seems a bit odd -- the placeholder could point
to a number of things (a float, an absolutely positioned element, or a fixed
positioned element), and I would think those should be handled on their own, at
the appropriate times for each.

When do we decide that it's not worth doing this extra reflow when printing, and
go back and find another fix for bug 84017?

Comment 33

[karnaze (gone)]

vidur is looking into removing the extra printing resize reflow to get the form 
data. The patch in bug 82401 contains code to defeat the bad effects of the 
extra resize reflow. It also appears to fix this bug.

Comment 34

[kinmoz]

Attachment: Patch Rev 2 (Make sure placeholder is not absolute or fixed.)

Comment 35

[kinmoz]

I just attatched Rev 2 of the patch which basically limits the reparenting of 
placeholder out-of-flow frames/views to floaters.

My 09/24/01 Win32 debug build, with karnaze's fix for bug 82401, and without 
either of my fixes, still crashes.

Like dbaron, I didn't like fixing things this way, the problem is that 
DrainOverflowLines() is called before ReflowDirtyLines(), so I don't have access 
to the linebox's floater list, because it hasn't been built yet ... and when we 
get to ReflowDirtyLines(), we can't really tell that the line was dirtied as the 
result of it coming from the now empty overflow list.

Any other suggestions for fixing this bug?

Comment 36

[Kevin McCluskey (gone)]

Vidur's fix for bug 84017 also fixes this bug by removing the Resize Reflow
completely.

Comment 37

[Kevin McCluskey (gone)]

*** This bug has been marked as a duplicate of 84017 ***

Comment 38

[sujay]

verified. will re-verify after 84017 is fixed.

Comment 39

[kinmoz]

Reopening this bug since I can still reproduce the crash after applying Patch v3
in bug 84017.

Comment 40

[Chris Waterson]

Comment on attachment 50571 [details] [diff] [review]
Patch Rev 2 (Make sure placeholder is not absolute or fixed.)

sr=waterson!

Comment 41

[David Baron :dbaron: (⌚️UTC-4, no longer working on Mozilla)]

Comment on attachment 50571 [details] [diff] [review]
Patch Rev 2 (Make sure placeholder is not absolute or fixed.)

r=dbaron

Comment 42

[Jaime Rodriguez, Jr.]

check it in - PDT+

Comment 43

[kinmoz]

Fix checked into MOZILLA_0_9_4_BRANCH:

   mozilla/layout/html/base/src/nsBlockFrame.cpp  revision 3.452.2.5

Comment 44

[kinmoz]

Fix checked into TRUNK:

   mozilla/layout/html/base/src/nsBlockFrame.cpp  revision 3.459

Should appear in the 09/28/01 8am QA builds.

Comment 45

[sujay]

verified in 9/28 branch. will verify in trunk later.

Comment 46

[sujay]

verified in 10/26 trunk.