Closed Bug 38768 Opened 26 years ago Closed 26 years ago

Printing and Crashing

Categories

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

Product:
Core
Component:
Printing: Output
Platform:
x86
All
Type:
defect

Tracking

()

Status:
VERIFIED FIXED

People

(Reporter: dem4, Assigned: attinasi)

References

(
URL
)

Details

(Keywords: crash, Whiteboard: [dogfood+][nsbeta2-][M16Blocker])

Attachments

(3 files)

stack trace (crash occurred only once), printing www.msn.com
8.09 KB, text/plain
Details
Patch to fix the crash: complete setting up pres context before calling SetCompatMode
567 bytes, patch
Details | Diff | Splinter Review
Another patch to remove an assertion that is invalid for printing cases
335 bytes, patch
Details | Diff | Splinter Review
Summary of bug We experienced constant instability of the Mozilla web browser while attempting to print out URL's. In order to verify our bug, we used the Bugzilla query to search for the strings "crash" and "print." We found two bug reports, which were close to what we have been noticing. Bugzilla Query Results Bug # 24459, which may be found in appendix A. Description: The user attempted to print the URL: http://www.mozilla.org/quality/browser/front-end/testcases/printing/css6.html After selecting OK from the Windows Print Dialog Box the browser crashes. OS: Windows 98 Target Milestone: M15 Priority: P3 Severity: Critical Status: Resolved Resolution: Invalid Summary: Bug is marked as Resolved Invalid due to the URL no longer existing. Bug # 3817, which may be found in appendix B. (Marked as duplicate of Bug #3468 appendix C) Description: The user attempts to print a page but clicking OK on the Windows Print Dialog Box will crash after an assert about trying to deref a null nsCOMPtr. OS: Mac OS Target Milestone: Not Specified Priority: P1 Severity: Major Status: Verified Resolution: Duplicate Summary: Bug is based on the Mac OS, however it is marked as a duplicate of a bug based on Windows 98 whose target milestone is M3. We found that many pages would crash Mozilla right after printing. The page would print and then Mozilla would experience an invalid operation fault and crash itself. Now, for those URL's that successfully printed without a subsequent crash of Mozilla, we found that Mozilla would crash when: 1. Another URL was entered in the find URL dialogue box (Ctrl+L). 2. Reload, back, or forward, was clicked right after the successful print. We have provided screen shots with source code of the URL's that we tested. Furthermore, we have provided a way to reproduce these errors so that they may be tested and fixed by the Mozilla development team. Finally we tested it under the nightly build. The test for the nightly build proved inconclusive because all our tests simply did not print, but at the same time did not crash Mozilla. Machines The bug was initially found while running Mozilla on a computer at a PC workstation at Fairchild Martindale. The bug was then reproduced on three other computers at that same location. Finally, the bug was verified on Scott's personal computer. Library PC's PC: Gateway Pentium OS: Windows98 Ram: 64MB Printer: Lehigh LAN Printer 1st floor Fairchild Martindale Library Scott's PC PC: Gateway Pentium OS: Windows98 Ram: 48MB RAM Printer: Canon BJC 240 Printer Speed: 166MHz Reproduction of Bug: · Install build M15 of Mozilla as explained earlier · Start Browser · Load desired URL · Print Page - File/Print · Just watch the it crash Observed Results After attempting to print the URL, we found a number of things going wrong with the browser, varying generally from page to page, but not following any real consistent type of pattern. After printing out many pages, we noted the following results: · Printing of the page successfully without crashing the browser · Successful printing of the page, with the next click of mouse resulting in an "illegal instruction" message resulting in the browser closing · Successful printing of the page, followed immediately by browser lock up. · Successful printing, followed immediately by "illegal operation" message resulting in the browser closing · Failure to print the page at all without terminating the browser · Printing out an entirely blank page without terminating the browser Successful printing without crashing was predominantly found on Scott's computer, approximately 40% of the time. Successful printing without crashing actually happened quite rarely on the school's computers, although they were higher performance systems. By far the most frequently observed results on the schools systems was the illegal operation message, occurring either immediately or after the next click of the mouse. Surprisingly, in these cases, the page was printed successfully prior to the browser crashing. Scott's computer occasionally experienced complete failure to print or printed blank pages without crashing. Pattern Some Web Sites produced more crashes than others, although each web page tested was successfully printed after a number of tries on different computers. The general trend though was the more complex the webpage, the quicker the crash. Crashing seemed particularly frequent in highly graphical pages, possibly due to poor memory usage. Verification All Web pages that failed to print normally were successfully printed using Netscape Communicator. Test Cases & Screen Shots Scott's Computer Successes upon print utility Http://www.mozilla.org/mozorg.html Http://www2.lehigh.edu/home.html http://msnbc.com Http://www.aol.com/ Failures upon print utility URL ERROR http://www.cnn.com/ Froze at Print Dialog Http://www.espn.go.com/ Printed Blank Page, didn't crash Http://www.msn.com/ Printed, but crashed - giving error message (see screenshot 1) http://www.eecs.lehigh.edu/ Experienced heavy slowdown, never printed http://www.lehigh.edu/~dem4 Displayed error message and locked up, printed however Second attempt successful Third Attempt crashed Mozilla (see screenshot 2) http://home.netscape.com/index1.html Never Printed, no crash Computers in Fairchild-Martindale Library Successes upon print utility Http://www.yahoo.com Http://www.eecs.lehigh.edu/~arp6 Failures upon print utility URL ERROR http://www.cnn.com Printed, but crashed immediately - giving error message http://www.eecs.lehigh.edu/~dem4 Printed, but gave error message on reload/forward/back/open new URL http://www.netscape.com Printed, but gave error message on reload/forward/back/open new URL http://www.mozilla.org Printed, but gave error message on reload/forward/back/open new URL (see 3) http://www.cnet.com Printed, but gave error message on reload/forward/back/open new URL (see 4) http://www.zdnet.com Printed, but crashed - giving error message http://www.espn.go.com Printed, but gave error message on reload/forward/back/open new URL http://www.eecs.lehigh.edu/~tid2 Printed, but crashed right on print
Adding crash keyword
Keywords: crash
I guess we need to start looking at this monster of a bug report. I would hate to mark it invalid, but there does seem to be like 7-8 issues in here, all regarding different URLS, and different results (slow printing, blank page, froze at print dialog, crashed on OK at print dlg, printed but gave error msg, locked up but printed, and so forth).
Yes, we should look at this one. I hate unconfirmed bugs, especially crashers.
I could reproduce that mozilla hangs when trying to print www.cnn.com to a file. I found that bug 31484 "Printing URL fails -- and browser hangs or crashed" already mentions this page and attached the stack trace there.
http://www.espn.go.com/ currently crashes in nsDSURIContentListener::DoContent, which is addressed by bug 40116. I added a note there.
Confirming bug (there are many valid issues mentioned here, and it seems to be important that attention is payed to them rather sooner than later). Adding dependency to bug 40116. Changing OS to All. Next URL: When printing www.msn.com for the first time, it crashed like this: Gtk-WARNING **: invalid cast from (NULL) pointer to `GtkObject' WEBSHELL- = 6 Program received signal SIGSEGV, Segmentation fault. #0 0x4121c624 in GIFDecoder virtual table () from components/libnsgif.so #1 0x21 in ?? () #2 0x40cad159 in nsImageFrame::Destroy () from components/libraptorhtml.so (See the attachment for the full stack trace). Afterwards, I successfully printed that page to a file twice (without crash).
Status: UNCONFIRMED → NEW
Depends on: 40116
Ever confirmed: true
OS: Windows 98 → All
http://www.eecs.lehigh.edu/ ........ printed fine for me twice http://www.lehigh.edu/~dem4 ........ currently crashes in nsDSURIContentListener::DoContent (bug 40116) http://home.netscape.com/index1.html printed fine for me http://www.eecs.lehigh.edu/~dem4 .. printed fine for me, back etc. works fine. http://www.mozilla.org ............. printed fine for me, back etc. works fine. http://www.cnet.com ................ displayed some messages in the shell: Gtk-WARNING **: invalid cast from (NULL) pointer to `GtkObject', then printed, but in the resulting ps file the main content seems to be missing somehow. Don't know if this is a ghostview bug or a mozilla bug. http://www.eecs.lehigh.edu/~tid2 ... prints fine. I suggest to use this bug as a collection of test pages for printing. It could be closed as soon as all the originally mentioned URLs are printed without problems. Could someone on Windows also try to print these URLs ? Dennis Miu -- I can't find the screenshots you mentioned in your original description. Could you add some comments here where to find them? It is also necessary that you retest the behaviour (at least on one machine) with a current build. Probably it's best to wait till M16 is finally out (should be in a few days, the planned date is 6/5). Please report any differences to your original results with M15, and also any differences to my results above. I think it's likely that the crashes on button use after printing have been fixed, but anyway your confirmation is needed. CC self.
Depends on: 31484
yep, crash on NT trying to print mozilla home page. nominating for nsbeta2.
URL: http://www.mozilla.org
Keywords: nsbeta2
severity : critical, milestone :m16. Printing webpages is crashing a lot on win/mac/linux.
Severity: normal → critical
Keywords: dogfood
Target Milestone: --- → M16
I have not noticed this bug untill i submitted a separate bug report #41591 yesterday. Although the bug i submitted is talking specifically of international pages, it may be a duplicate of this one. Inside my bug report is a gdb backtrace and strace of the crash.
This is has a problem with an assert in nsFrameManager and a null pointer when cx->SetCompatibilityMode() is called in nsDocumentViewer. This requires moving 4 lines of code down in the sequence, very low risk, fixes a major bug. Mark Attinasi has the fix.. so I will give this to him..
Assignee: dcone → attinasi
Whiteboard: Have Fix in tree, very low risk
I have the fix ready to land - very low risk, I'll attach the patch.
Status: NEW → ASSIGNED
Whiteboard: Have Fix in tree, very low risk → [Fix In Hand]
*** Bug 41698 has been marked as a duplicate of this bug. ***
*** Bug 41529 has been marked as a duplicate of this bug. ***
[nsbeta2+]
Whiteboard: [Fix In Hand] → [nsbeta2+][Fix In Hand]
Adding [dogfood-]
Whiteboard: [nsbeta2+][Fix In Hand] → [nsbeta2+][dogfood-][Fix In Hand]
This should be reconsidered for dogfood+ since trying to print anything( all platforms) crashes the browser. cc:leger. severity: blocker.
Severity: critical → blocker
Whiteboard: [nsbeta2+][dogfood-][Fix In Hand] → [nsbeta2+][Fix In Hand]
I'm checking in the fix as soon as the tree opens anyway, so it doesn't really matter to me if you call it dogfood or not. If you care for other reasons, then that's ok too :-)
Putting on [dogfood+] radar.
Whiteboard: [nsbeta2+][Fix In Hand] → [dogfood+][nsbeta2-][Fix In Hand]
Fixed. (nsDocumentViewer.cpp, nsFrameManager.cpp)
Status: ASSIGNED → RESOLVED
Closed: 26 years ago
Resolution: --- → FIXED
The current popularity of this bug seems to have been caused be a recently introduced problem. The duplicates (bug 41698 and bug 41529) have been reported on 6/6 and 6/4. The original bug report however was about a variety of different crashing problems with different pages. I would be very surprised if Mark's fix(es) really fixed each and every problem mentioned in the original report. For example, both dependencies of this bug have not been resolved yet. IMHO the best thing would be if someone from QA (shrir?) could try to verify that all problematic pages mentioned in the original bug description now print (and can be reloaded after printing) without a single crash on all platforms. If this is not the case, then this bug could either be reopened (without dogfood etc. of course) or new bugs could be filed about the remaining problems. When verifying, please add some information about what has been tested. Otherwise we could easily lose the information contained in the original report. I had suggested to use this bug as a tracking bug for crashes related to printing (and reloading) the following pages: http://www.mozilla.org http://www.netscape.com http://home.netscape.com/index1.html http://www.msn.com/ http://www.cnn.com/ http://www.cnet.com http://www.zdnet.com http://www.espn.go.com/ and http://www.eecs.lehigh.edu/ http://www.lehigh.edu/~dem4 http://www.eecs.lehigh.edu/~dem4 http://www.eecs.lehigh.edu/~tid2 If it is not possible to verify all these pages on all platforms, then this bug could be closed by verifying that www.mozilla.org now prints (again) on all platforms, but then a new bug should be opened for the rest of the pages. Let's not lose this bug's information.
This bug needs to be fixed in the m16 branch too. I assume that this fix would only go into m17 trunk.Thnx.
Regarding Andreas Franke's comment: my fix was to the recent regression of mine that caused ALL printing to fail due to a newly introduced assumption about the PresShell being initialized before SetCompatibilityMode is called... That is it. There are bound to be many other problems with printing that are more specific and more subtle, and if the dup'd bugs represent those issues then I agree that we have made a big mistake in blindly closing this bug. Remaining printing isses should be brought to the attention of dcone since he is the printing-god, I am just a style-guy who mistakenly broke printing with an unrelated change. So, if you do decide to reopen the bug, please reassign to dcone. Also, thanks for bringing up this isses, I would hate for valuable bug information to be lost due to my lack of knowledge of the problems. Shrir, I'm checking on updating the M16 branch - good call, thanks.
Adding on my [M16Blocker] radar.
Whiteboard: [dogfood+][nsbeta2-][Fix In Hand] → [dogfood+][nsbeta2-][M16Blocker][Fix In Hand]
Update: This(printing crash) is fixed on all trunk builds (2000060820M17) on win + linux and 2000060811M17 on mac. Not yet fixed on the branch bits (2000060815M16).
Checked into M16 branch.
Whiteboard: [dogfood+][nsbeta2-][M16Blocker][Fix In Hand] → [dogfood+][nsbeta2-][M16Blocker]
Verified fixed on M16 builds for today on all platforms(2000061200M16).
Status: RESOLVED → VERIFIED
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: