148623 - Browser crashes on print of svg graphics (libart only)

Status: RESOLVED WONTFIX

(Core :: SVG, defect)

Description

[hugo van woerkom]

Display svg graphics. Hit "print", select either "file" or "printer". Boom!
I only have 2 svg enabled mozillas: a cvs tree build of 5/23 and a r1 branch
build of 5/31, they both do it.

Comment 1

[hugo van woerkom]

I need some instructions on how to get a stack trace with a CVS Build of
MOZILLA_1_0_RELEASE with these options:

ac_add_options --enable-default-mozilla-five-home=/opt/mozilla
ac_add_options --with-x
mk_add_options MOZ_INTERNAL_LIBART_LGPL=1
mk_add_options MOZ_CVS_FLAGS="-q -z 9"
ac_add_options --enable-crypto
ac_add_options --disable-xft
ac_add_options --disable-jsd
ac_add_options --disable-accessibility
ac_add_options --disable-tests
ac_add_options --disable-debug
ac_add_options --enable-optimize=-O3
ac_add_options --disable-dtd-debug
ac_add_options --disable-logging
ac_add_options --enable-reorder
ac_add_options --enable-strip
ac_add_options --enable-elf-dynstr-gc
ac_add_options --enable-cpp-rtti
ac_add_options --enable-extensions=all
ac_add_options --enable-svg
MOZ_INTERNAL_LIBART_LGPL=1

Because it happens with the CVS trunk of 5/23 that I have also.

Comment 2

[Alex Fritze]

You need to build with --enable-debug and run the debugger. Instructions for 
running gdb/ddd are at http://www.mozilla.org/unix/debugging-faq.html

In this case, however, don't bother with a stack trace. I'm pretty sure we 
crash because the required pixel-format is not implemented; see bug#111152.

Comment 3

[Roland Mainz]

Reporter:
Can you try printing using Xprint module ? That may work better...

Comment 4

[hugo van woerkom]

I find the xprint dir in mozilla but no xprint executable... or Xprint...

Comment 5

[hugo van woerkom]

I installed Xprt, but if I'm not mistaken, that is to be used when there is a
physical printer installed. I have none. The crash occurs also when printing to
file.

Comment 6

[hugo van woerkom]

Configured Xprt so it would start w/o errors.
Has to be started before xdm 
Crash still occurs.
Crash does not occur using Adobe Plugin+ showing same svg graphic but resulting
.ps file doesn't display anything in gv.

Comment 7

[Olivier Cahagne]

can you attach stack trace ? Remove flag ac_add_options --disable-debug

Comment 8

[Alex Fritze]

This bug affects the libart backend only. Printing on the GDI+ backend works fine.
Not sure about Cairo.

Crash doesn't happen on all SVGs. Some graphics don't crash but just show up
empty. This URL produces a crash:
http://www.skeeter-s.com/svg/new-lion.xhtml

Bug 233407 has a stacktrace.

Comment 9

[tor]

Cairo can generate PS (not the best output at the moment, but it's at
least something), which we should figure out how to use for printing
with that backend renderer.

Comment 10

[Roland Mainz]

[e-mail] wrote:
> Cairo can generate PS (not the best output at the moment, but it's at
> least something), which we should figure out how to use for printing
> with that backend renderer.

That will likely not work unless you redesign Cairo's PostScript generator to
generate embedable PostScript fragments.

Comment 11

[Alex Fritze]

So there are two unrelated issues here. 
Printing most svg graphics, e.g. http://www.croczilla.com/svg/polygons1.xml
causes no crash, but just prints blank. Of the top of my head, this could be due
to maybe DrawTile() not doing what it should, or because the libart renderer
doesn't scale correctly to device pixels (i.e. it assumes 1px = 1 printer pixel)
when printing. On Windows/libart this leads to printouts being way too small. 

As for crashing, I've only been able to produce this for
http://www.skeeter-s.com/svg/new-lion.xhtml.
Casual debugging shows that we fail in nsViewManager::RenderViews() because a
call to CreateBlendingBuffers() fails. CC'ing roc hoping that he has some ideas.

Comment 12

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

How does it fail? Out of memory? Or something else?

If you try to create a buffer with 1px == one printer dot, then no doubt you
will run out of memory quite easily :-)

Comment 13

[Jonathan Watt [:jwatt]]

Mass reassign of SVG bugs that aren't currently being worked on by Alex to
[e-mail]. If you think someone should be assigned to your bug you can
join the #svg channel on mozilla.org's IRC server ( irc://irc.mozilla.org/svg )
where you can try to convince one of the SVG hackers to work on it. We aren't
always there, so if you don't get a response straight away please try again later. 

Comment 14

[Jonathan Watt [:jwatt]]

Marking wontfix. We have no plans to continue work on the libart backend.