Created attachment 11062 [details]
PDF that causes unhandled exceptions.
I reported this problem to ImageMagick through this link:
That has everything. I'm also attaching the PDF that causes the problem.
Trying to convert a PDF to PNG.
Something else I should've added. A ImageMagick person has looked at this issue and says he's debugged it to be inside GhostScript.
So, can we have a command line to make it fail in just Ghostscript then please?
From the ImageMagick person ... The following command will reproduce the error:
"c:\Program Files (x86)\gs\gs9.14\bin\gswin32c.exe" -dQUIET -dSAFER -dBATCH -dNOPAUSE -dNOPROMPT -dMaxBitmap=500000000 -dAlignToPixels=0 -dGridFitTT=2 "-sDEVICE=pngalpha" -dTextAlphaBits=4 -dGraphicsAlphaBits=4 "-r300x300" "-sOutputFile=c:\test.jpg" "-fERI_MRP_02_MAP.pdf"
This is not a problem with images. For me the GPF happens in clist_playback_band() because state_slot->x_reps is 0 and on line 1135 we execute the code:
state_tile.rep_width = state_tile.size.x /
resulting in a divide by zero error.
Assigning to Ray as it is (or seems to be) a clist bug.
Current code (SHA , Windows 32-bit debug build, this command line:
gswin32 -sDEVICE=pngalpha -r300 -sOutputFile=test.png ERI_MRP_02_MAP.pdf
exhibits the fault for me, and is a much simpler command line.
Running under the VS debugger the exception happens in a different place though, line 1131:
stp:state_tile.size.x = state_slot->width;
because state_slot is a pointer to a nonsense memory location. I suspect its the same problem exhibiting slightly differently because memory locations have moved.
This seems to be caused by the playback_action being wrong since it is losing
sync in the playback after set_color when 'playback_action_render_no_pdf14'
is given to clist_playback_band. This is due to the expected 'depth' being
24 (when the pdf14 device is used), but is 32 for the pngalpha device.
I suspect I have to disable the pdf14 optimization when the device is "non-
standard" (when the color model does not match the pdf14 device) since the
colors will always be written to the clist using the pdf14 encode_color, but
if we've skipped the pdf14 compositor, the clist and device will become
As per my email to tech "banding/page mode bugs", closing this file as I cannot reproduce a problem.