Created attachment 11062 [details] PDF that causes unhandled exceptions. I reported this problem to ImageMagick through this link: http://www.imagemagick.org/discourse-server/viewtopic.php?f=27&t=25920 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 / state_slot->x_reps; 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 confused.
As per my email to tech "banding/page mode bugs", closing this file as I cannot reproduce a problem.