Customer reported: The attach file causes gs to crash (gs 8.53, Linux) with a big BufferSpace (200Mb): gs -DBufferSpace=200000000 -sDEVICE=tiff32nc -sOututFile=a.tif -r720 - dNOPAUSE -f 36x60.pdf -c quit gs immediatly crashes in mem_true32_fill_rectangle (called from gs_fillpage) The strange thing is that it doesn not crash at higher resolutions, e.g 800 or 1440 dpi (more exactly, it crashes when the output file reaches 2 Gb, but this is normal). In these resolutions clist_fill_rectangle is called insted of mem32_fill_rectangle. It seems that at 720 dpi (and close values, e.g. 719), tiff32nc is processed like a non-banding device. Also when you specify a lower BufferSpace (e.g. 100Mb, or none at all), it works without problems. Note that I don't really want to use 200Mb - I just found this bug while experimenting with different values. But I would like to be sure that it's not something that can happen with other files, or other resolutions, with a more reasonnable BufferSpace value (100Mb). Problem also verified on WinXP.
Created attachment 2382 [details] test file
Additional comment from the customer: I've reproduced the problem with a 100Mb BufferSpace: gs -DBufferSpace=100000000 -sDEVICE=tiff32nc -sOututFile=a.tif -r712 - dNOPAUSE -f 36x60.pdf -c quit Apparently that depends of the resolution. At 720 dpi it's OK.
Note: The test file is 36 x 60 inches. This gives 1119744000 pixels. FOr a 32 bit output device, this would take over 4 GBytes. Thus we should be using the clist. However the segv is occuring while processing a fill page without using the clist. The first thing to check is a math overflow in the logic which decides about using the band logic.
Ray's already done some work on this.
This problem has been fixed by Ray on 2007-06-17 by rev. 8056.