Created attachment 7380 [details] File causing a seg fault in clist processing The attached file is a much cut-down version of the file created by pdfwrite from the C320.bin pcl6cet file. I've removed all the extraneous pages and much of the content of the remaining page (the file renders blank in Acrobat). When run with this command line: gswin32 -sDEVICE=ppmraw -sOutputFile=\temp\out.ppm -r600 -dNOPAUSE -dBATCH \temp\crash.pdf GS encounters a GPF on Windows, Seg fault on Linux. I think the only switch that matters is the -r600, and probably only because it triggers banding and the use of the Clist. The GPF occurs in gxclrast.c, line 1999: switch (op >> 4) { case cmd_op_fill_rect >> 4: if (state.rect.width == 0 && state.rect.height == 0 && state.rect.x == 0 && state.rect.y == 0) { code = (*dev_proc(tdev, fillpage))(tdev, &imager_state, &dev_color); break; } because the clip_list_accumulator device has no 'fillpage' method. This is probably a red herring, I imagine the real problem is the fact that the list contains a 0 width/height rectangle. I wasn't able to reduce the PDF any further and still trigger the problem.
Assigning to Ray as a clist problem.
The cause is (as Ken guessed) another case of a 'fillpage' being invoked on a clip_accumulator device (which has the fillpage proc vector == NULL). This is being entered into the clist by: q 0 6600 0 0 re W n Then this empty clip path is used for the stroke performed by: 0.509375 w q 1.96319 0 0 1.96319 0 0 cm -305.625 3667.5 m -305.625 -12938.1 l 16300 -12938.1 l 16300 3667.5 l h S The solution to this is to (a) not do stroke or fill when the clip path is an empty area, which is more efficient and (b) get rid of the hacky fillpage method invocation in favor of a explicit cmd_op_ clist command. w.r.t. (b) there seem to be quite a few "obsolete" commands: /* obsolete */ /* cmd_opv_set_color = 0xd0, */ /* obsolete */ /* cmd_opv_set_color_short = 0xd1, /* cmd_opv_htfill = 0xf1, */ /* obsolete */ /* cmd_opv_colorfill = 0xf2, */ /* obsolete */ cmd_opv_eofill = 0xf3, /* cmd_opv_hteofill = 0xf4, */ /* obsolete */ /* cmd_opv_coloreofill = 0xf5, */ /* obsolete */ cmd_opv_stroke = 0xf6, /* cmd_opv_htstroke = 0xf7, */ /* obsolete */ /* cmd_opv_colorstroke = 0xf8, */ /* obsolete */ cmd_opv_polyfill = 0xf9, /* cmd_opv_htpolyfill = 0xfa, */ /* obsolete */ /* cmd_opv_colorpolyfill = 0xfb */ /* obsolete */ ... and the list goes on
Workaround added in 62b5781. This patches the symptoms, doesn't prevent the fillpage being in the clist in the first place.
The clist fillpage patch from Robin prevents the crash. We'd like to improve this to avoid the nonsense of using a 0x0 rect to represent HL color fillpage, but that's an internal improvement, not a bug.