The following command lines produce a seg fault on the macpro: bin/gs -o test.pdf -sDEVICE=pdfwrite -r300 -dJOBSERVER %rom%Resource/Init/gs_cet.ps - < ./33_all.PS and bin/gs -o test.ps -sDEVICE=ps2write -r300 -dJOBSERVER %rom%Resource/Init/gs_cet.ps - < ./33_all.PS This is a regression, the first version that causes the seg fault is : commit 4d0f6ec0fc64eba04cc85693d16bc7158599578b Author: Ray Johnston <ray.johnston@artifex.com> Date: Mon Oct 17 12:26:17 2011 -0700 Fix bug 691978: Ignore PS vmreclaim requests for GC. Only GC when vmthreshold exceeded. Some poorly designed PostScript creators make liberal use of '2 vmreclaim' which would trigger a full GC (mark/scan/reloc) pass each time. The document with the bug did this > 10,000 times. Since the vmthreshold already triggers GC when the allocated amount exceeds the threshold, we don't need to really do anything when a job requests GC. Change "internal" (infrequent) interpreter uses to use '2 .vmreclaim'. Speeds up the file from the bug by 79X ! Also fix areas that didn't update i_ctx_p after running the interpreter (which may do a GC) and a minor typo in gs.c noticed while scanning for all instances of this.
I believe this is the same issue: r -ZAa? -sOutputFile=tests_private__ps__ps3cet__35_all.PS.ps.pkmraw.300.0.ps -sDEVICE=ps2write -r300 -sDEFAULTPAPERSIZE=letter -dNOPAUSE -dBATCH -dClusterJob -dJOBSERVER %rom%Resource/Init/gs_cet.ps - < ~/tests_private/ps/ps3cet/35_all.PS With memory checking it is shown that a freed object is being referenced: GPL Ghostscript GIT PRERELEASE 9.05: ./psi/ilocate.c(541): Reference to free object 0x101a5a270(12), in chunk 0x1017107e0! Searching back for that address in the -ZA we have: [a12:+$ ]array(3) = 0x101a5a220 [a5:+> ]scanner(20) = 0x101cf7e71 [a5:-> ]scanner(20) 0x101cf7e71 [a12:+b.]moveshow -bytes-*(12=3*4) = 0x101a5a270 [a12:+< ]gdev_pdf_text_begin pdf_text_enum_t(560) = 0x101a5a290 [a12:-of]moveshow bytes(12) 0x101a5a270 [a12:+< ]alloc_save_change alloc_change(40) = 0x101a5a4d0 [a12:+<.]array refs*(48=3*16) = 0x101a5a508 [a12:+< ]alloc_save_change alloc_change(40) = 0x101a5a548 Not quite sure how the object was allocated in "other" or "." and freed from the freelist maybe my secret decoder ring is busted again. Is this really just the macpro, maybe -Z? will show the problem on any machine?
Running on Linux (x86_64) with -Z? does show a problem: GPL Ghostscript GIT PRERELEASE 9.06: ./psi/ilocate.c(541): Reference to free object 0x2da7618(12), in chunk 0x2d03bd0!
The offending pointer is in a gs_text_enum_t that still has a pointer to the 'widths' that where allocated (and freed) in zcharx.c. which is happening when -20 (e_ ) is returned from op_show_finish_setup. Even though the widths are freed, the pointer in the gs_text_enum_t text.x_widths is left set. Should be a simple fix by clearing the pointers in the text_enum when we free the array.
Change fixes Windows (where I was able to duplicate it) -- doing clusterpush
I believe it's the same problem as the bug 692684. 33_all.PS or other files from *_all.PS batch no longer crash on any hosts. *** This bug has been marked as a duplicate of bug 692684 ***