pcl6 -sDEVICE=txtwrite -dNOPAUSE -dBATCH -sOutputFile=whatever tests_private/pcl/pcl5cfts/fts.0980 line 1878, in gdevtxtw.c penum->Widths[pte->index -1] = wanted.x pte->index is zero in this case with this file, and therefore the array index goes to -1 and segfaulted. (need a txtwrite device component in bugzilla, but I want this to go to Ken who wrote those bits, so that would do...)
I can't reproduce the described problem. I do see a problem with this file where the interpreter exits with a -1 code. Looks like this is caused by PCL raster ops. txtwrite is a pretty simple-minded device and doesn't implement a whole lot of device methods. Since its not a rendering device it doesn't return chunks of the page bitmap via the 'get_bits_rectangle' method, and this causes the ROP compositing to fail (it has no bitmap to composite with). I'll fix that problem and try again to reproduce the described problem.
I was using a debug build, BTW, if that makes any differences. The location of segfault was pin-pointed with gdb.
(In reply to comment #2) > I was using a debug build, BTW, if that makes any differences. It probably does, I get different results with debug and release builds. I'm using debug builds on both Linux and Windows
I confirm Hin-Tak's findings with valgrind on all PCL files I've tried, writes outside the bound of the array. ==95603== Conditional jump or move depends on uninitialised value(s) ==95603== at 0x1004B1BCB: pl_cmap_lookup (plchar.c:723) ==95603== by 0x1004B210D: pl_tt_cmap_encode_char (plchar.c:794) ==95603== by 0x1004B2445: pl_tt_encode_char (plchar.c:858) ==95603== by 0x1003000D1: txtwrite_process_plain_text (gdevtxtw.c:1865) ==95603== by 0x10030178E: textw_text_process (gdevtxtw.c:2119) ==95603== by 0x1003C8A73: gs_text_process (gstext.c:552) ==95603== by 0x10050F1C5: hpgl_print_char (pglabel.c:882) ==95603== by 0x100510E54: hpgl_process_buffer (pglabel.c:1320) ==95603== by 0x1005113D2: hpgl_LB (pglabel.c:1383) ==95603== by 0x1004FE428: hpgl_process (pgparse.c:104) ==95603== by 0x1004D445C: pcl_process (pcparse.c:457) ==95603== by 0x100001BD8: pcl_impl_process (pctop.c:519) ==95603== Uninitialised value was created by a stack allocation ==95603== at 0x1002FFF80: txtwrite_process_plain_text (gdevtxtw.c:1840) ==95603== ==95603== Invalid write of size 4 ==95603== at 0x100300289: txtwrite_process_plain_text (gdevtxtw.c:1878) ==95603== by 0x10030178E: textw_text_process (gdevtxtw.c:2119) ==95603== by 0x1003C8A73: gs_text_process (gstext.c:552) ==95603== by 0x10050F1C5: hpgl_print_char (pglabel.c:882) ==95603== by 0x100510E54: hpgl_process_buffer (pglabel.c:1320) ==95603== by 0x1005113D2: hpgl_LB (pglabel.c:1383) ==95603== by 0x1004FE428: hpgl_process (pgparse.c:104) ==95603== by 0x1004D445C: pcl_process (pcparse.c:457) ==95603== by 0x100001BD8: pcl_impl_process (pctop.c:519) ==95603== by 0x100493DED: pl_process (pltop.c:160) ==95603== by 0x100513A9D: pl_main_aux (plmain.c:431) ==95603== by 0x100513F39: pl_main (plmain.c:513) ==95603== Address 0x501bb5634 is not stack'd, malloc'd or (recently) free'd ==95603==
I can't reproduce the crash. However I can see that the index is 0 which it categorically must *not* be at this point. This is caused by the fact that the txtwrite code does not handle TEXT_FROM_CHARS or TEXT_FOM_SINGLE_CHAR, it looks like I got diverted form it before finding test cases for these. I've added that code in this commit: http://ghostscript.com/pipermail/gs-cvs/2012-May/014585.html and the result is certainly better than it was before. Hin-Tak can you try this please ? You will also probably need commit : http://ghostscript.com/pipermail/gs-cvs/2012-May/014582.html Though I've a feeling this is not specific to txtwrite, see Hin-Taks bug #693054 which looks like it might be the same problem with the pxlcolor device.
Henry confirms this fixes the problem for him so I will close the bug, if it is not resolved please reopen.
(In reply to comment #6) > Henry confirms this fixes the problem for him so I will close the bug, if it is > not resolved please reopen. yes, just confirming that the segfault is gone.