Hi, current svn HEAD pdfwriter segfaults when attempting to convert the attached ps file to pdf via ps2pdf. This is on 32 bit Fedora 10, CentOS 4.7, RHEL 4 update 7, etc. I do not see segfaults on 64 bit systems. The same figure processes fine with gs 8.63. # ps2pdf diagram2.eps Segmentation fault (core dumped) (gdb) bt #0 0x080fa6e5 in gs_gc_reclaim () #1 0x08171867 in context_reclaim () #2 0x080cb28c in ireclaim () #3 0x080c69b2 in interp_reclaim () #4 0x080c8154 in interp () #5 0x080c8dfe in gs_interpret () #6 0x080bded9 in gs_main_run_string_with_length () #7 0x080bdf1a in gs_main_run_string () #8 0x080beb47 in run_string () #9 0x080bf299 in runarg () #10 0x080bf495 in argproc () #11 0x080c0cf7 in gs_main_init_with_args () #12 0x0804e92a in main () Cheers T.
Created attachment 4789 [details] diagram2.eps ps file which causes segfault with ps2pdf
I can also reproduce on 32 bit (intel) MacOS X, but not 64 bit Linux. .setpdfwrite seems to be critical. This command succeeds: $ debugobj/gs -sDEVICE=pwdwrite -o diagram2.pdf diagram2.eps while this one fail: $ debugobj/gs -sDEVICE=pdfwrite -o diagram2.pdf -c .setpdfwrite -f diagram2.eps Also, my debug build reports chunk parsing errors from igc.c lines 1181, 1224 and 1326.
<sigh> Its another non-deterministic bug it seems. For me under Windows the bug exhibits without -c .setpdfwrite, or at least I get a crash. However, under the debugger it won't crash either way. I think this may be a memory issue, which is why it doesn't apparently exhibit on 64-bit machines and, for me, disappears when run under a debugger. The memory arena is sufficiently different that whatever causes the problem stamps on something unimportant. Its also (probably) a clue that the stack trace shows the crash in gs_gc_reclaim, and Ralph's debug build shows memory chunk problems.
Not sure if this is informative (this is with r9471, with gs8.54 these messages do not appear): marcos@imac:[145]% gshead.debug -Z@\? -sDEVICE=pdfwrite -sOutputFile=test.pdf -dNOPAUSE - dBATCH -c .setpdfwrite -f ./diagram2.eps GPL Ghostscript SVN PRE-RELEASE 8.64 (2008-08-02) Copyright (C) 2008 Artifex Software, Inc. All rights reserved. This software comes with NO WARRANTY: see the file PUBLIC for details. **** Warning: Some of the BoundingBox for the EPS file will be clipped. Use -dEPSCrop or -dEPSFitPage to avoid clipping. GPL Ghostscript SVN PRE-RELEASE 8.64: ./psi/ilocate.c(461): At 0x113009c, array 0x226c9e8[87] element 1 is not a ref GPL Ghostscript SVN PRE-RELEASE 8.64: ./psi/ilocate.c(461): At 0x113009c, array 0x226c9e8[87] element 2 is not a ref GPL Ghostscript SVN PRE-RELEASE 8.64: ./psi/ilocate.c(461): At 0x113009c, array 0x226c9e8[87] element 9 is not a ref GPL Ghostscript SVN PRE-RELEASE 8.64: ./psi/ilocate.c(461): At 0x113009c, array 0x226c9e8[87] element 10 is not a ref GPL Ghostscript SVN PRE-RELEASE 8.64: ./psi/ilocate.c(461): At 0x113009c, array 0x226c9e8[87] element 11 is not a ref GPL Ghostscript SVN PRE-RELEASE 8.64: ./psi/ilocate.c(461): At 0x113009c, array 0x226c9e8[87] element 12 is not a ref GPL Ghostscript SVN PRE-RELEASE 8.64: ./psi/ilocate.c(461): At 0x113009c, array 0x226c9e8[87] element 13 is not a ref . . .
Here's relevant fragment of the allocation trace. The array allocated as "cie_cache_common" seems to have bad references. I plan to validate the references when they are assigned to the array shortly after the allocation and check why invalid references are assigned. [a12:+<.]cie_cache_common refs*(704=88*8) = 0xc1ac10 [a12:+<f]alloc_save_change alloc_change(20) = 0xc0ab20 [a12:-of]alloc_save_remove alloc_change(20) 0xc0ab20 [a12:-o ]cie_tpqr_finish refs(704) 0xc1ac10 [a12:+b.]make_type4_function(Domain) -bytes-*(8=2*4) = 0xc1ac10 [a12:+b.]make_type4_function(Range) -bytes-*(24=6*4) = 0xc1ac28 [a12:->#]ops(0) 0x0 [a12:-o ]Range bytes(24) 0xc1ac28 [a12:-o ]Domain bytes(8) 0xc1ac10 [a12:+b.]make_sampled_function(Domain) -bytes-*(8=2*4) = 0xc1ac10 [a12:+b.]make_sampled_function(Range) -bytes-*(24=6*4) = 0xc1ac28 [a12:+b.]Size -bytes-*(4=1*4) = 0xc1ac50 [a12:+b.]cube_build_func0(bytes) -bytes-*(3072=3072*1) = 0xc1ac68 [a12:+<f]gs_function_Sd_init gs_function_Sd_t(104) = 0xbefd70 [a12:+b.]gs_function_Sd_init -bytes-*(64=16*4) = 0xc1b878 [a12:+b.]gs_function_Sd_init -bytes-*(64=16*4) = 0xc1b8c8 [a+]gs_malloc(large object chunk)(96) = 0x8d03d8: OK [a+]gs_malloc(large object chunk)(36856) = 0x148d3b8: OK [a12:+b.]gs_function_Sd_init -bytes-*(36816=4602*8) = 0x148d3e0 [a12:+<f]zbuildsampledfuntion(params) gs_sampled_data_enum(72) = 0xbefe88 GPL Ghostscript SVN PRE-RELEASE 8.65: .\psi\ilocate.c(461): At 0x9f5ef8, array 0xc1ac10[87] element 2 is not a ref GPL Ghostscript SVN PRE-RELEASE 8.65: .\psi\ilocate.c(461): At 0x9f5ef8, array 0xc1ac10[87] element 7 is not a ref GPL Ghostscript SVN PRE-RELEASE 8.65: .\psi\ilocate.c(461): At 0x9f5ef8, array 0xc1ac10[87] element 10 is not a ref
Probably not helpful, but r8962 was the first one to show this problem: r8962 | ken | 2008-08-11 07:16:18 -0700 (Mon, 11 Aug 2008) | 10 lines Move the interpretation of PostScript (and PDF) color spaces from PostScript into C.
Created attachment 4795 [details] patch Clear the reference to cie_cache_common ref array when the array is deleted to prevent enumeration of freed (and reused) memory by GC. I cannot fully test the patch. If fixes the error messages from -Z? but I was unable to reproduce the crash. Please retest with the patch.
Alex, this fixes the crash for me. I can reproduce it before, but not after. First, thanks for finding the problem, I wasn't looking forward to that one :-) Do you have any clue why this was causing trouble ? Its not a piece of code I've changed, do you think this has always been a potential problem, and we've just been lucky not to hit it ? I see the issue is assigned to you, will you commit the change ?
I think the problem might actually be more fundamental, in the funky way ifree_ref_array works. There's a rather puzzling comment at the start: /* Deallocate an array of refs. Only do this if LIFO, or if */ /* the array occupies an entire chunk by itself. */ and one of the paths through this function says: /* Punt, but fill the array with nulls so that there won't be */ /* dangling references to confuse the garbage collector. */ It seems that the arrays are not always really freed, but this will take some more study. I'm not sure why the make_null(op-1) resolves this since I would think the pop(2) would remove this element from the stack, making it invisible to the GC. Alex, can you investigate which path the ifree_ref_array is taking in this case, in case that leads to further insight?
I confirm that the patch from comment #7 fixes the core dump for me on Linux, Fedora 10, i686, with current svn HEAD (revision 9737) will the patch be committed? Thanks T.
The problem has disappeared with the rev. r11306 | mvrhel | 2010-05-24 12:31:58 -0400 (Mon, 24 May 2010) | 20 lines Merge of icc_work branch into trunk.
I confirm that the problem has disappeared in current HEAD Thanks T.