193686 - Print preview crashes the browser [@ nsGfxScrollFrame::Destroy ]

Status: VERIFIED FIXED

(Core :: Print Preview, defect, P2)

Description

[George Credland]

User-Agent:       Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.3b) Gecko/20030210
Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.3b) Gecko/20030210

See: http://rhino.shef.ac.uk:3001/gc-home/crash_test.html
(This has validated with validator.w3.org as valid HTML 4.01 Strict)

When I try to Print Preview on this page, the browser crashes.






Reproducible: Always

Steps to Reproduce:
1. Open URL http://rhino.shef.ac.uk:3001/gc-home/crash_test.html
2. Print Preview from the menu.
3.

Actual Results:  
Browser crashes.

Expected Results:  
Shown Print Preview.

No additional information displayed.

I can "Print Preview" on other pages without incident.

Print Preview works fine in Netscape 7.01 for the problem page.

Comment 1

[Mitch]

Works fine on Linux with mozilla cvs 20030217, both Print Prieview and
actual Printing. Must be Windoze specific.

Comment 2

[piers]

Reporter, for me it crashes on clicking close in print preview -- is that the same
for you or does it crash on entering print preview? Do you have a talkback 
incident number?

2003021623 Solaris/SPARC

Possibly related to any of: bug 190257, bug 163800, bug 156982, bug 152536

Comment 3

[George Credland]

To confirm. Browser crashes immediately on selecting "Print Preview" from the
menu on Windows 2000 and XP Professional. I don't get the print preview window.

Comment 4

[Michael Lefevre]

confirming for the moment - may be a dupe, need the stack. TB17262060G

Comment 5

[George Credland]

Attachment: DrWatson crash log

Crash created on closing Print Preview window.

Comment 6

[George Credland]

Just uploaded the DrWatson log for a crash on closing Print Preview window.
(Matches report from Piers Cornwell)

It was produced using Windows XP Professional (Service Pack 1).

Interestingly, it let me see the Print Preview window, whereas previously the
crash occurred on opening the window. However, much of the page contents were
not rendered e.g. Labels, Fieldset frame and legend, buttons, images for buttons
at bottom of page.

Comment 7

[piers]

Yeah, the crash on exit is at:

#0 0x7f3458e8 in nsVoidArray virtual table ()
from /Moz/mozilla/./libxpcom.so
#1 0x7dd59be0 in NSGetModule ()
from /Moz/mozilla/components/libgklayout.so

which i think is known already.

Comment 8

[piers]

Btw, i'm on Win2000 now (20030216) and i get the same as you: it sometimes crashes
on entering print preview and sometimes not. Lets keep this bug just for that 
issue since the crash on exit is a different problem and the lack of display of 
form elements is bug 192938.

Comment 9

[Gábor Lipták]

confirming with

Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.3b) Gecko/20030214

Comment 10

[joakim_46]

Confirming it with build 2003021008 under Windows XP SP1.

Talkback ID: TB17270691K

Comment 11

[Nicholas Allen]

WFM 0215 WinXP trunk

Comment 12

[George Credland]

Attachment: DrWatson crash log on entering Print Preview (Windows2000 SP3)

DrWatson crash log on entering Print Preview (Windows2000 SP3)

Comment 13

[Olivier Cahagne]

Attachment: Stack trace Linux 20030223

Comment 14

[Olivier Cahagne]

related: bug 176970, bug 178781, bug 134481.

Comment 15

[Pratik]

*** Bug 195198 has been marked as a duplicate of this bug. ***

Comment 16

[Simon Montagu :smontagu]

I can't always reproduce the crash, but if I adjust the Print Preview size
settings it usually happens sooner or later.

Sometimes, even without crashing, I see

###!!! ASSERTION: unexpected frame type: 'PR_FALSE', file c:/MozillaWork/shaping
1/mozilla/layout/html/style/src/nsCSSFrameConstructor.cpp, line 11645

with frameType "FieldSetFrame", followed by one or two

###!!! ASSERTION: reflow dirty lines failed: 'NS_SUCCEEDED(rv)', file c:/Mozilla
Work/shaping1/mozilla/layout/html/base/src/nsBlockFrame.cpp, line 942

When I do crash, it is in nsGfxScrollFrameInner::GetScrollableView, with view
not null but containing lots of 0xfeeefeee

Comment 17

[Robert O'Callahan (:roc) (email my personal email if necessary)]

Need a minimized test case. Can someone cut the page down to the minimum HTML
needed to provoke the crash?

Comment 18

[Michael Lefevre]

Attachment: not-minimal testcase

well I had a go at a testcase, but I'm afraid after 30 minutes of messing
around, I can't figure it out. Page is a mass of nested tables - chopping even
a cell out of the mess makes it work... maybe someone can improve on this.

Comment 19

[Andrew Schultz]

Attachment: testcase

seems to need an <input> in the second page of a <fieldset>.

Comment 20

[Andrew Schultz]

Attachment: fun with valgrind

Comment 21

[Andrew Schultz]

I should add that Mozilla crashes when closing print preview of the testcase. 
Getting a testcase for crashing when opening print preview was futile and the
crash-on-close is also in nsGfxScrollFrame::Destroy.

Comment 22

[Matthias Versen [:Matti]]

*** Bug 197808 has been marked as a duplicate of this bug. ***

Comment 23

[Torben]

Duplicate bug 197808 claims crash on opening print preview happens if forms are
longer than one page.

Comment 24

[David Denis]

I'm not sure if this is related (I was about to file a bug but found this one
which seems to be close) but Print Preview crashes for me on this article about
Venkman:
http://devedge.netscape.com/viewsource/2002/venkman/01/
This page has special CSS specifically for print media.  I'm using 1.3 final on
WinXP.

Comment 25

[sairuh (rarely reading bugmail)]

i can easily crash this when i bring up Print Preview for the bugzilla query page,

http://bugzilla.mozilla.org/query.cgi

this occurred on both win2k and linux rh8.0 (2003.05.28-1.4 builds).

talkback reports:

http://climate.netscape.com/reports/SingleIncidentInfo.cfm?dynamicBBID=20558747
http://climate.netscape.com/reports/SingleIncidentInfo.cfm?dynamicBBID=20558734

if what i'm seeing is a different issue, let me know and i'll file another bug.

Comment 26

[Andrew Schultz]

this is probably related to bug 156982 (based on valgrind log)

Comment 27

[Samir Gehani]

adt: nsbeta1+/adt2

Comment 28

[Kevin McCluskey (gone)]

-> jkeiser

Comment 29

[Robert O'Callahan (:roc) (email my personal email if necessary)]

mine

Comment 30

[Robert O'Callahan (:roc) (email my personal email if necessary)]

Attachment: fix

The problem is that frames in the overflowList of an nsContainerFrame or
nsBlockFrame were not being destroyed until the PresShell was torn down. By
that time, their views had already been destroyed (because when we destroy a
view, we also destroy its children), so we tried to destroy the views again ...
BOOM.

The right thing to do is to delete overflow child frames when we delete the
parent frame.

nsContainerFrame also needs to report the overflowList as a possible source of
child frames.

Comment 31

[Robert O'Callahan (:roc) (email my personal email if necessary)]

Attachment: correct patch

That patch was missing a file. This is the right patch.

Comment 32

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

Comment on attachment 124632 [details] [diff] [review]
correct patch

I guess the original intent here was that the overflow lists be temporaries
during reflow that never survive past the end of the reflow, so they wouldn't
need to be reported this way.  I'd think that ought to be happening, though. 
Any idea why it isn't?

>+NS_IMETHODIMP
>+nsContainerFrame::GetAdditionalChildListName(PRInt32   aIndex,
>+                                             nsIAtom** aListName) const
>+{
>+  NS_PRECONDITION(nsnull != aListName, "null OUT parameter pointer");
>+  if (aIndex < 0) {
>+    return NS_ERROR_INVALID_ARG;
>+  }

How about something that asserts, since you're not filling in the out param?
  NS_ENSURE_TRUE(aIndex >= 0, NS_ERROR_INVALID_ARG);
is a possibility.

r+sr=dbaron

Comment 33

[Robert O'Callahan (:roc) (email my personal email if necessary)]

I think the situation here is that the fieldset can't be split across pages, so
the overflow lines belonging to its block survive the end of reflow, because
there's no next in flow block to take them.

Also, it is important to return the full set of child lists even during reflow,
for example, when a frame is reparented and we need to reparent the views of all
children including any overflow children. I fixed a bug like that a while ago by
making nsBlockFrame report its overflowList.

> How about something that asserts

Sure, I'll do that.

Comment 34

[Robert O'Callahan (:roc) (email my personal email if necessary)]

Comment on attachment 124632 [details] [diff] [review]
correct patch

this is a fairly straightfoward fix for a crasher. I wouldn't say it blocks 1.4
but it would be nice to get it in. If there's time I'd like to let the fix bake
on the trunk for a couple of days before landing this into 1.4.

Comment 35

[Robert O'Callahan (:roc) (email my personal email if necessary)]

Checked into trunk.

Comment 36

[Robert O'Callahan (:roc) (email my personal email if necessary)]

This seems to have caused about a 1% Tp hit on Linux only. Gaaah

Comment 37

[Randell Jesup [:jesup] (needinfo me)]

Comment on attachment 124632 [details] [diff] [review]
correct patch

Please add fixed1.4 when checked into the branch.

Comment 38

[Richard Ponton]

I came across this myself.  I can upload my test case (not 100% minimal, but
fairly so) if desired.  I'm using 1.4RC1 on Windows XP SP 1  (Build ID:
2003052908).  

Crash on exit of print preview (or when trying to switch to Landscape mode,
etc.)  The print preview itself doesn't come up.

Glad to know it looks like y'all have it nailed down.

Comment 39

[Robert O'Callahan (:roc) (email my personal email if necessary)]

checked into branch.

Comment 40

[sairuh (rarely reading bugmail)]

vrfy'd fixed using comm 2003.06.06.08-trunk and 2003.06.06.13-1.4 builds on
linux rh7.2. tested on the bugzilla query page and the other test pages
mentioned here.