Bug 690435 - Segmentation fault sending Windows Printer Test Page to CUPS
Summary: Segmentation fault sending Windows Printer Test Page to CUPS
Status: RESOLVED FIXED
Alias: None
Product: Ghostscript
Classification: Unclassified
Component: CUPS driver (show other bugs)
Version: master
Hardware: All Linux
: P3 normal
Assignee: Till Kamppeter
QA Contact: Bug traffic
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2009-04-20 14:32 UTC by Stephen Gildea
Modified: 2014-02-17 04:42 UTC (History)
5 users (show)

See Also:
Customer:
Word Size: ---


Attachments
windows-test-page.ps (169.60 KB, application/postscript)
2009-04-20 14:35 UTC, Stephen Gildea
Details
stderr (215.89 KB, text/plain)
2009-04-20 14:36 UTC, Stephen Gildea
Details
backtrace (2.52 KB, text/plain)
2009-04-20 14:37 UTC, Stephen Gildea
Details
close-device-on-color-depth-change.patch (512 bytes, patch)
2010-08-05 07:37 UTC, Till Kamppeter
Details | Diff
launch_leaflet.pdf (2.95 MB, application/pdf)
2010-08-05 07:40 UTC, Till Kamppeter
Details
log (1.76 MB, text/plain)
2010-08-05 07:42 UTC, Till Kamppeter
Details
cups-raster-reallocate-on-color-depth-change.patch (866 bytes, patch)
2010-08-05 23:45 UTC, Till Kamppeter
Details | Diff

Note You need to log in before you can comment on or make changes to this bug.
Description Stephen Gildea 2009-04-20 14:32:53 UTC
I cannot print PS files generated on MS/Windows to CUPS devices.  I cannot even
print the Windows Printer Test Page--the gs interpreter segfaults with
-sDEVICE=cups.

My command line:

gs -dQUIET -dPARANOIDSAFER -dNOPAUSE -dBATCH -dNOMEDIAATTRS -sDEVICE=cups
-sstdout=/dev/null -sOUTPUTFILE=/dev/null windows-test-page.ps

Attached: input PS file, stderr debug messages, backtrace from gdb.
Comment 1 Stephen Gildea 2009-04-20 14:35:20 UTC
Created attachment 4954 [details]
windows-test-page.ps

Postscript input
Comment 2 Stephen Gildea 2009-04-20 14:36:36 UTC
Created attachment 4955 [details]
stderr

standard error output
Comment 3 Stephen Gildea 2009-04-20 14:37:13 UTC
Created attachment 4956 [details]
backtrace

backtrace from gdb
Comment 4 Ray Johnston 2009-04-23 13:15:31 UTC
Assigned to Marcos to test.
Comment 5 Hin-Tak Leung 2010-06-27 00:08:18 UTC
r10340 segfaults at a different place than the submitted backtrace - probably clist related.

------------------
#0  0x0000003e9d082d2a in memset () from /lib64/libc.so.6
#1  0x000000000098b2c5 in mem_true24_fill_rectangle (dev=0x1ca04e0, x=0, y=0, w=24480, h=19, color=0) at ./base/gdevm24.c:184
#2  0x000000000093072b in gx_dc_pure_fill_rectangle (pdevc=0x7fffffff69a0, x=0, y=0, w=24480, h=29, dev=0x1ca04e0, lop=252, source=0x0)
    at ./base/gxdcolor.c:414
#3  0x000000000097a67c in gx_default_fillpage (dev=0x1ca04e0, pis=0x7fffffff6ca0, pdevc=0x7fffffff69a0) at ./base/gdevddrw.c:1077
#4  0x00000000006e6729 in clist_playback_band (playback_action=playback_action_render, cdev=0x7ffff1d63068, s=0x7fffffffa290, target=0x1ca04e0, x0=0, 
    y0=0, mem=0x193ad58) at ./base/gxclrast.c:1997
#5  0x00000000006ecb93 in clist_playback_file_bands (action=playback_action_render, crdev=0x7ffff1d63068, page_info=0x7fffffffb1d8, target=0x1ca04e0, 
    band_first=0, band_last=0, x0=0, y0=0) at ./base/gxclread.c:835
#6  0x00000000006ec7a8 in clist_render_rectangle (cldev=0x7ffff1d63068, prect=0x7fffffffb7f0, bdev=0x1ca04e0, render_plane=0x7fffffffb9c0, clear=1)
    at ./base/gxclread.c:764
#7  0x00000000006ec4ae in clist_rasterize_lines (dev=0x7ffff1d63068, y=0, line_count=1, bdev=0x1ca04e0, render_plane=0x7fffffffb9c0, 
    pmy=0x7fffffffb9bc) at ./base/gxclread.c:676
#8  0x00000000006ebf8b in clist_get_bits_rectangle (dev=0x7ffff1d63068, prect=0x7fffffffbd80, params=0x7fffffffbc60, unread=0x0)
    at ./base/gxclread.c:567
#9  0x0000000000701eed in clist_get_bits_rect_mt (dev=0x7ffff1d63068, prect=0x7fffffffbd80, params=0x7fffffffbc60, unread=0x0)
    at ./base/gxclthrd.c:481
#10 0x000000000097c21e in gx_default_get_bits (dev=0x7ffff1d63068, y=0, data=0x1efd490 "", actual_data=0x7fffffffbe48) at ./base/gdevdgbr.c:51
#11 0x00000000006da88f in gdev_prn_get_bits (pdev=0x7ffff1d63068, y=0, str=0x1efd490 "", actual_data=0x7fffffffbe48) at ./base/gdevprn.c:1225
#12 0x00000000008cae4c in cups_print_chunked (pdev=0x7ffff1d63068, src=0x1efd490 "", dst=0x1f0f3b0 "", srcbytes=73440) at cups/gdevcups.c:3997
#13 0x00000000008c6041 in cups_print_pages (pdev=0x7ffff1d63068, fp=0x1ef8de0, num_copies=1) at cups/gdevcups.c:2790
#14 0x00000000006d9816 in gdev_prn_output_page (pdev=0x7ffff1d63068, num_copies=1, flush=1) at ./base/gdevprn.c:770
....

--------------
Comment 6 Hin-Tak Leung 2010-06-27 00:10:48 UTC
(In reply to comment #5)
> r10340 segfaults at a different place than the submitted backtrace - probably
> clist related.

I meant r11340 there.
Comment 7 Hin-Tak Leung 2010-06-27 00:23:01 UTC
The file seems to set a very large resolution internally:

gs-debug-r11340 -sDEVICE=png256 -o /tmp/a.png  bugs.ghostscript.com/attachment.cgi\?id\=4954\&action\=view

$ file /tmp/a.png
/tmp/a.png: PNG image data, 24480 x 15840, 8-bit colormap, non-interlaced


gs-debug-r11340 -r72 -sDEVICE=png256 -o /tmp/a.png  bugs.ghostscript.com/attachment.cgi\?id\=4954\&action\=view

$ file /tmp/a.png
/tmp/a.png: PNG image data, 612 x 792, 8-bit colormap, non-interlaced

i.e. The file seems to set itself to render to 2880 dpi x 1440 dpi.
Comment 8 Ray Johnston 2010-07-20 17:07:26 UTC
This _still_ segfaults (on peeves) with rev 11529. Marking as a blocker for
the release.
Comment 9 Ray Johnston 2010-07-20 17:19:45 UTC
At the time of the segfault, we are clearing the band buffer. Examination
shows the BandHeight is 29, with a 'raster' of 73440 (24480*3) so the
band buffer _should_ be 2,129,760 bytes, but it is only 838,860 bytes.

This seems to be a problem in setting up the clist buffer device.

Assigning to myself.
Comment 10 Ray Johnston 2010-07-20 18:02:26 UTC
The cups device is doing something screwy. It is setting up the clist device
buffers based on 8-bit pixels (Gray, depth 8), but then not resizing the
buffers when it switches to 24-bit (RGB) colors.

Still looking into it to see how it does this.
Comment 11 Henry Stiles 2010-08-03 17:51:12 UTC
Till, this looks very similar to the problem you addressed in revision 11547, so maybe you should have a look at it first.  If you can't fix it quickly assign it back to me, we should fix this before a release (blocker).
Comment 12 Henry Stiles 2010-08-04 15:13:50 UTC
Following up on what Ray said in Comment #10 if I force the memory reallocation, by setting width_old = -1 before gdev_prn_maybe_realloc_memory() the crash goes away, so I guess you can see if the color info has caused the buffer sizes to change and then realloc.  Till, I'd rather you make changes to this device I don't have a setup to test it well.  Let me know if you can do this.
Comment 13 Ray Johnston 2010-08-04 17:36:52 UTC
calling gdev_prn_maybe_realloc_memory isn't a sufficient method for when the
color_info.depth changes since this function is only sensitive to the width,
height and transparency flag.

The gdevbit.c file does the following to handle depth changes:

    if (pdev->color_info.depth != save_info.depth ||
	pdev->color_info.num_components != save_info.num_components
	) {
	gs_closedevice(pdev);
    }

by closing the device, then the old (incorrect) memory will be torn down and
new prn memory will be allocated correctly for the new depth.
Comment 14 Till Kamppeter 2010-08-05 05:18:17 UTC
I will do the change in the next days.
Comment 15 Till Kamppeter 2010-08-05 07:34:53 UTC
I tried a simple approach now (attached). It solves the segfault but it causes also a regression (as usual). If I run

cat ~/ghostscript/gpl/testfiles/launch_leaflet.pdf | LD_PRELOAD=sobin/libgs.so.9.00 GS_LIB=Resource/Init:lib sobin/gsc -dQUIET -dPARANOIDSAFER -dNOPAUSE -dBATCH -sDEVICE=cups -sstdout=%stderr -sOutputFile=%stdout -r720x720 -dcupsBitsPerColor=8 -dcupsColorSpace=1 -_ > out.raster 2> log

I get

| ./base/gxclread.c:434: clist_unserialize_icctable(): insufficient memory for i
cc table buffer reader

in the "log"file. It seems that when closing the device on a color depth change it gets reopened with a too tight meomory buffer, not providing the space for the new ICC support.
Comment 16 Till Kamppeter 2010-08-05 07:37:40 UTC
Created attachment 6612 [details]
close-device-on-color-depth-change.patch

Simple patch to fix the segfault problem.
Comment 17 Till Kamppeter 2010-08-05 07:40:20 UTC
Created attachment 6613 [details]
launch_leaflet.pdf

PDF input file of the command line in the comment above.
Comment 18 Till Kamppeter 2010-08-05 07:42:32 UTC
Created attachment 6614 [details]
log

log file (=stderr) of the command line from the comment above.
Comment 19 Till Kamppeter 2010-08-05 15:13:56 UTC
Ray, can you have a look into cups/gdevcups.c to see whether there is something wrong with the device's architecture? It seems that if the device is closed in the middle of the job that on reopening the needed memory does not get allocated.
Comment 20 Till Kamppeter 2010-08-05 23:33:35 UTC
Applied Henry's workaround from comment #10 as rev. 11604. This makes the CUPS device reliably working, but I leave the bug open until we have a real fix. Ray suggests to add support for color depth changes to the maybe_realoc function.
Comment 21 Till Kamppeter 2010-08-05 23:38:25 UTC
Sorry, Henry's suggestion is in comment #12 and not in #10.
Comment 22 Till Kamppeter 2010-08-05 23:45:06 UTC
Created attachment 6623 [details]
cups-raster-reallocate-on-color-depth-change.patch

Ghostscript 8.71 has the same problem. Therefore it is highly recommended to apply the change here, too, especially in distribution packages. The patch is attached.
Comment 23 Ray Johnston 2010-08-06 17:00:14 UTC
Since this is resolved by a hack in gdevcups (rev 11604), downgrading from 
'blocker' state.
Comment 24 Till Kamppeter 2011-01-07 23:44:01 UTC
My last proposal for a workaround for bug 691733 (see comment #29 there) fixes also this bug.

Note that I do not know why this works. I found it out simply by testing. So this is not necessarily the correct solution but also only a workaround.

Please test more files with this workaround.

I have committed it as SVN rev. 12007 for the time being.
Comment 25 Till Kamppeter 2011-07-25 17:24:46 UTC
Like bug bug 691733, this one seems to be fixed, too. The bugs seem to be duplicates.