| Summary: | Getting Divide by Zero, Access Denied | ||
|---|---|---|---|
| Product: | Ghostscript | Reporter: | Dave <dohara> |
| Component: | Graphics Library | Assignee: | Ray Johnston <ray.johnston> |
| Status: | RESOLVED WORKSFORME | ||
| Severity: | normal | CC: | dohara |
| Priority: | P4 | ||
| Version: | 9.14 | ||
| Hardware: | PC | ||
| OS: | Windows 7 | ||
| Customer: | Word Size: | --- | |
| Attachments: | PDF that causes unhandled exceptions. | ||
|
Description
Dave
2014-07-17 03:59:56 UTC
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. |