Created attachment 4954 [details]
windows-test-page.ps

Postscript input

Created attachment 4955 [details]
stderr

standard error output

Created attachment 4956 [details]
backtrace

backtrace from gdb

Assigned to Marcos to test.

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

--------------

(In reply to comment #5)
> r10340 segfaults at a different place than the submitted backtrace - probably
> clist related.

I meant r11340 there.

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.

This _still_ segfaults (on peeves) with rev 11529. Marking as a blocker for
the release.

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.

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.

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

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.

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.

I will do the change in the next days.

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.

Created attachment 6612 [details]
close-device-on-color-depth-change.patch

Simple patch to fix the segfault problem.

Created attachment 6613 [details]
launch_leaflet.pdf

PDF input file of the command line in the comment above.

Created attachment 6614 [details]
log

log file (=stderr) of the command line from the comment above.

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.

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.

Sorry, Henry's suggestion is in comment #12 and not in #10.

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.

Since this is resolved by a hack in gdevcups (rev 11604), downgrading from 
'blocker' state.

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.

Like bug bug 691733, this one seems to be fixed, too. The bugs seem to be duplicates.