User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.5; en-US; rv:220.127.116.11) Gecko/2008102920 Firefox/3.0.4 Build Identifier: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.5; en-US; rv:18.104.22.168) Gecko/2008102920 Firefox/3.0.4 When I try to print this XHTML/SVG file in Firefox 3.0.4 on my Mac, Firefox immediately crashes. It crashes right when I choose File -> Print. I've whittled down my crasher file to a fairly small test case. If I remove the rect, it works OK. Simplifying in other ways also causes it to work. But it's not simply this filter that causes it to crash, because this filter in other places works OK. (When I say "works OK", I don't mean "prints the same as it displays on the screen". I simply mean "prints *something*, and doesn't crash". I understand that SVG printing support isn't quite there yet, and that's expected, but it should never crash.) Reproducible: Always Steps to Reproduce: 1. Open crash.xhtml in FF 3.0.4 2. Choose File->Print Actual Results: Firefox immediately crashes Expected Results: Ideally, it should print the file correctly. But I'd settle for not crashing. :-)
Created attachment 347852 [details] an XHTML/SVG file which displays fine, but crashes FF when you try to print it
I can confirm this, in both FF 3.0.3 and 3.0.4, on OS X 10.5.5. You don't actually need to print -- print preview also triggers a crash. I don't crash in FF 3.0.3 on Windows or Linux -- so this is presumably Mac-only. I don't crash in today's Minefield nightly (2008-11-12-02-mozilla-central) (on OS X 10.5.5).
Status: UNCONFIRMED → NEW
Component: General → Printing: Output
Ever confirmed: true
Product: Firefox → Core
QA Contact: general → printing
Version: unspecified → 1.9.0 Branch
If it doesn't crash in today's Minefield then this should probably be closed as WORKSFORME.
Created attachment 347869 [details] Gdb trace of crash (with debug symbols) Here's a gdb stack trace (with debug symbols) made from code pulled Monday morning -- the rough equivalent of Firefox 3.0.4.
(In reply to comment #3) > If it doesn't crash in today's Minefield then this should probably > be closed as WORKSFORME. I'm tempted to do that. And I wouldn't hesitate for an "ordinary" bug. But it's a crash, so let's leave it open for a while, to see if anyone else has any insights. If this crash uncovers some other bug (and if it's only an accident that it doesn't happen on the trunk), we'll gain by having followed through on it.
I found a solution range (?) during which this crash disappears: http://hg.mozilla.org/mozilla-central/pushloghtml?startdate=2008-07-22+08%3A00%3A00&enddate=2008-07-23+05%3A29%3A00 There's no patch in that range that directly addresses any print crashes, no Mac-specific patch, and only one SVG-related patch -- for bug 455297 ("Optimize filters so that changes to the source image don't have to repaint the entire filter"). How confident can we be be that the patch for bug 455297 "fixed" this bug's crash on the trunk?
By the way, this bug's crash happens on both OS X 10.5.5 and OS X 10.4.11 -- so it's not obviously an Apple bug.
(In reply to comment #6) > How confident can we be be that the patch for bug 455297 "fixed" this > bug's crash on the trunk? I wouldn't expect that to help.
bug 445297 may hide an unrelated printing bug as it might reduce the size of the image being printed so maybe somewhere the printing code is running out of memory and not detecting that. Even so it is too big and risky to be branch material IMHO. It is an early part of a larger series of trunk patches. A subsequent patch fixed an issue with this patch which caused changes to the filter itself to stop working IIRC.
I'm now inclined to think this is an Apple bug, after all. I rooted around in nsDeviceContextSpecX.mm, but couldn't find anything that triggers this crash. (I played tricks like commenting out calls to release an object, but nothing I did caused the crashes to stop.) And though (on the surface) this looks like a crash caused by accessing a deleted object, I don't think that's what's going on. I tried a couple of debugging techniques (using libgmalloc and setting CFZombieLevel to 5) that should have detected attempts to write to deleted objects, without causing access violations -- but they made no difference and provided no information. The top of the stack contains a call to CGSImageStreamRead(), which (though undocumented) appears to be used to read image data -- like that for an SVG image. I searched the web for CGSImageStreamRead(), and found other, similar crash stacks (in other programs). Nobody had managed to figure out the cause, but several posters concluded that this was some kind of Apple bug (which isn't surprising, given that the crashes happen deep in Apple code). There was even a post to an Apple list (http://lists.apple.com/archives/Carbon-dev/2008/Feb/msg00456.html), where an Apple developer responded by asking the poster to open a bug ... which was the last post in the thread :-( So I suppose the only remaining question is whether we mark this WORKSFORME, INVALID (because we think it's an Apple bug), or WONTFIX.
Here's another reason to doubt that this is an out-of-memory problem: Apple is usually pretty good about writing out-of-memory errors to the system console. But in all my tests I didn't see any of these.
And I don't think the data stream that CGSImageStreamRead() reads is corrupt, because the image displays fine.
Steven, can you file a bug in https://bugreport.apple.com/ and paste the ID here?
It'll be a while before I have time to do that. I'd need to redo all my research.
Firefox 3.0.x is no longer supported, time to close WFM?
status1.9.1: --- → unaffected
Keywords: crash, testcase
Summary: Printing this SVG file crashes Firefox (test case included) → [1.9.0] Printing this SVG file crashes Firefox (test case included)
(In reply to comment #15) Sounds good to me.
Status: NEW → RESOLVED
Last Resolved: 8 years ago
Resolution: --- → WORKSFORME
You need to log in before you can comment on or make changes to this bug.