While consolidating the nightly regression tests with the svn based test files I came across a problem with the file imagemask-with-pattern.ps. It that generates a "Floating exception" on peeves (and probably other systems as well) using gshead (r8694) with pbmraw output and banding. The command line I'm using: /home/regression/gshead/bin/gs -sOutputFile=test.ppm -sDEVICE=pbmraw -dMaxBitmap=10000 /home/regression/comparefiles/imagemask-with-pattern.ps
The exception occurs in gdevm1.c at line 493: run -sOutputFile=test.ppm -sDEVICE=pbmraw -dMaxBitmap=10000 ./imagemask-with-pattern.ps ... Program received signal EXC_ARITHMETIC, Arithmetic exception. 0x0046c6ae in mem_mono_strip_tile_rectangle (dev=0x176e6c8, tiles=0xbfffadc4, tx=100, y=412, tw=3, th=1, color0=1, color1=0, px=0, py=0) at gdevm1.c:493 493 source_data = tiles->data + ((y + py) % tiles->rep_height) * source_raster; (gdb) print *tiles $4 = { data = 0x0, raster = 0, size = { x = 0, y = 0 }, id = 0, rep_width = 0, rep_height = 0, rep_shift = 0, shift = 0 }
Since this only occurs when using banding, assigning to Igor.
This is a regression, it worked in gs8.54 but not in gs8.56 and later. The revision which broke this is r7861.
Bumping priority for crash.
Created attachment 4228 [details] imagemask-with-pattern.ps
The failure happens because the clist language do not pass tile id. In same time, the implementation of strip_tile_rectangle for clist writer (clist_strip_tile_rectangle) assumes that a tile id presents whenever the tile is not empty. In the test case a clist based pattern includes a tile, so while its playback to the page clist device clist_strip_tile_rectangle recieves a non-empty tile with zero tile id and then malfunctions. So possible resolutions are either to extend the clist language with tile id (see clist_change_tile), or fall back to gx_default_strip_tile_rectangle from clist_strip_tile_rectangle when dev->proc.open_device==clist_open. I'm not clear which way is better. I wonder that neither my local test base, nor incasper:/home/regression/comparefiles include imagemask-with-pattern.ps . I see it comes from the closed bug 689210, but why it is not tested nightly ?
The nightly regression test runs on peeves, and there is a /home/regression/comparefiles/imagemask-with-pattern.ps It's also in the ghostcript svn tree; under tests/ps
I think clist_change_tile must check for cldev->nbands == 1. Well it's a new invariant, which allows to know whethet the target is a clist writer for a clist-based pattern accumulator. If true, write tiles->id to cmd_opv_set_tile_size. Functions cmd_size_tile_params, cmd_store_tile_params, read_set_tile_size will need an extra boolean parameter for passing the condition mentioned above.
Regarding Comment #8 : cdev->nbands==1 doewsn't work properly because it appears so when running -sDEVICE=pbmraw -dMaxBitmap=10000 CompareFiles\000- 00.ps . A right criterion is : #define IS_CLIST_FOR_PATTERN(cdev) (cdev->procs.open_device == pattern_clist_open_device) It could break non-pattern builds. Not sure whether it is important.
The case where nbands is 1 does occur when -dMaxBitmap is small enough to force banding, but -dBufferSpace is large enough that a given page only needs 1 band. We have at least one customer that always wants banding, so they specify -dMaxBitmap=10000 always.
Created attachment 4230 [details] patch.txt A suggested patch waits for code review from Henry and Ray.
Patch to HEAD : http://ghostscript.com/pipermail/gs-cvs/2008-July/008440.html Note it was committed with a wrong lig message that was fixed later.
This is still broken, at least on Mac OS X and Linux. On both my MacBook Pro and on peeves the following command line still gives a seg fault with gshead (r8865): bin/gs -sDEVICE=pbmraw -o test.pbm -r600 -dMaxBitmap=10000 ./imagemask-with-pattern.ps Here is the output: marcos@peeves:[27]% bin/gs -sDEVICE=pbmraw -o test.pbm -r600 -dMaxBitmap=10000 ./imagemask-with-pattern.ps GPL Ghostscript SVN PRE-RELEASE 8.63 (2008-03-01) Copyright (C) 2008 Artifex Software, Inc. All rights reserved. This software comes with NO WARRANTY: see the file PUBLIC for details. Floating exception marcos@peeves:[28]%
Well Comment #13 supplies a different command line than ones above. I could reproduce the crash on Windows. Will analyze it.
One more patch to HEAD : http://ghostscript.com/pipermail/gs-cvs/2008-July/008445.html