[1.9.0] Printing this SVG file crashes Firefox (test case included)




10 years ago
3 years ago


(Reporter: kengruven, Unassigned)


({crash, testcase})

1.9.0 Branch
crash, testcase
Bug Flags:
wanted1.9.0.x +

Firefox Tracking Flags

(status1.9.1 unaffected)


(Whiteboard: [sg:moderate] Apple bug?)


(2 attachments)



10 years ago
User-Agent:       Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.5; en-US; rv: Gecko/2008102920 Firefox/3.0.4
Build Identifier: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.5; en-US; rv: 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.  :-)

Comment 1

10 years ago
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

I don't crash in FF 3.0.3 on Windows or Linux -- so this is presumably

I don't crash in today's Minefield nightly
(2008-11-12-02-mozilla-central) (on OS X 10.5.5).
Component: General → Printing: Output
Ever confirmed: true
Product: Firefox → Core
QA Contact: general → printing
Version: unspecified → 1.9.0 Branch
Hardware: Macintosh → All
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"

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:


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
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.


10 years ago
Whiteboard: [sg:moderate] Apple bug?


10 years ago
Group: core-security

Comment 13

9 years ago
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
Flags: wanted1.9.0.x+
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.
Last Resolved: 9 years ago
Resolution: --- → WORKSFORME


3 years ago
Group: core-security → core-security-release
Group: core-security-release
You need to log in before you can comment on or make changes to this bug.