running ps2pdf from current svn HEAD on the attached ps file results in a segfault on various linux x86_64 (redhat, centos, fedora) but not on i386 gdb backtrace Core was generated by `gs -dSAFER -dCompatibilityLevel=1.3 -q -dNOPAUSE -dBATCH -sDEVICE=pdfwrite -sOu'. Program terminated with signal 11, Segmentation fault. #0 0x00000000004c7dbd in names_trace_finish () (gdb) bt #0 0x00000000004c7dbd in names_trace_finish () #1 0x00000000004c601d in gs_gc_reclaim () #2 0x000000000053e994 in context_reclaim () #3 0x00000000004967e6 in ireclaim () #4 0x00000000004923a1 in interp_reclaim () #5 0x0000000000493eb6 in gs_interpret () #6 0x00000000004892fe in gs_main_run_string_end () #7 0x000000000048a2c0 in run_string () #8 0x000000000048aa24 in runarg () #9 0x000000000048abd8 in argproc () #10 0x000000000048c2cb in gs_main_init_with_args () #11 0x000000000041c721 in main () I tried to build a debug build (-g -O0), but it doesn't segfault. only the regular build (-O2) segfaults. Also, when run with valgrind, I don't get a segfault. Instead a valid pdf file is generated. However valgrind reports ==29897== Invalid read of size 4 ==29897== at 0x4B58BD: names_trace_finish (iname.c:424) ==29897== by 0x4B3BBD: gs_gc_reclaim (igc.c:370) ==29897== by 0x52A071: context_reclaim (zcontext.c:283) ==29897== by 0x485443: ireclaim (ireclaim.c:153) ==29897== by 0x48111E: interp_reclaim (interp.c:427) ==29897== by 0x482B8F: gs_interpret (interp.c:1690) ==29897== by 0x4785BD: gs_main_run_string_end (imain.c:526) ==29897== by 0x47950F: run_string (imainarg.c:815) ==29897== by 0x479C05: runarg (imainarg.c:805) ==29897== by 0x479DB1: argproc (imainarg.c:738) ==29897== by 0x47B33A: gs_main_init_with_args (imainarg.c:215) ==29897== by 0x40D090: main (gs.c:77) ==29897== Address 0x4F4CEE0 is 72 bytes inside a block of size 8,280 free'd ==29897== at 0x4A0560B: free (vg_replace_malloc.c:233) ==29897== by 0x709BAC: alloc_free_chunk (gsalloc.c:1831) ==29897== by 0x70B2DD: i_free_object (gsalloc.c:820) ==29897== by 0x4B5660: name_free_sub (iname.c:540) ==29897== by 0x4B5771: name_scan_sub (iname.c:582) ==29897== by 0x4B589C: names_trace_finish (iname.c:416) ==29897== by 0x4B3BBD: gs_gc_reclaim (igc.c:370) ==29897== by 0x52A071: context_reclaim (zcontext.c:283) ==29897== by 0x485443: ireclaim (ireclaim.c:153) ==29897== by 0x48111E: interp_reclaim (interp.c:427) ==29897== by 0x482B8F: gs_interpret (interp.c:1690) ==29897== by 0x4785BD: gs_main_run_string_end (imain.c:526) this was generated with valgrind -v --track-origins=yes --leak-check=full gs -dSAFER -dCompatibilityLevel=1.3 $OPTIONS -q -dNOPAUSE -dBATCH -sDEVICE=pdfwrite "-sOutputFile=C.pdf" -c .setpdfwrite -f Cappellari_Voronoi_Binning_Review.ps again, this only happens on linux x86_64 but not on i386 Cheers T.
Created attachment 5784 [details] Cappellari_Voronoi_Binning_Review.ps ps2pdf segfaults on attached ps file on linux x86_64
Am afraid I cannot reproduce this on fedora 12 x86_64. I am using svn r10504 (HEAD at the moment of writing). You may need to be more precise about your "svn HEAD". I am using the command line from your valgrind run: gs -dSAFER -dCompatibilityLevel=1.3 -q -dNOPAUSE -dBATCH -sDEVICE=pdfwrite "-sOutputFile=C.pdf" -c .setpdfwrite -f Cappellari_Voronoi_Binning_Review.ps
ah, sorry, the segfault is sensitive to whether fonts are embedded in the ps or not and also on the length of the path in the Fontmap.GS file. In the previous attachment I embedded the fonts to avoid external dependencies -- but indeed it doesn't trigger a segfault in this form. I attach a package (tar.gz) file with a postscript file, a Fontmap and a subdirectory with the type1 fonts. This segfaults for me on Fedora12 x86_64 with svn HEAD 10507 and commandline # ps2pdf Cappellari_Voronoi_Binning_Review.ps Segmentation fault (core dumped) # gs -dSAFER -dCompatibilityLevel=1.4 -q -dNOPAUSE -dBATCH -sDEVICE=pdfwrite -sstdout=%stderr "-sOutputFile=Cappellari_Voronoi_Binning_Review.pdf" -dSAFER -dCompatibilityLevel=1.4 -c .setpdfwrite -f Cappellari_Voronoi_Binning_Review.ps Segmentation fault (core dumped) # echo $? 139 however there is no segfault when I omit the -sstdout=%stderr argument # gs -dSAFER -dCompatibilityLevel=1.4 -q -dNOPAUSE -dBATCH -sDEVICE=pdfwrite "-sOutputFile=Cappellari_Voronoi_Binning_Review.pdf" -dSAFER -dCompatibilityLevel=1.4 -c .setpdfwrite -f Cappellari_Voronoi_Binning_Review.ps # echo $? 0 As mentioned above the segfault is also sensitive to the length of the path to the pfb files in the Fontmap file. I found that it changes from Fedora 12 to CentOS 5. So this is a tricky and elusive segfault. I hope you can reproduce it with the attached package. Cheers T.
Created attachment 5787 [details] package-with-fonts.tar.gz
Reassign to Marcos to see if he can reproduce it on one of our systems
I'm seeing this too. It rarely segfaults for me on x86_64 (but has done once), but valgrind always reports that same error. Fedora bug reports: https://bugzilla.redhat.com/show_bug.cgi?id=465311 https://bugzilla.redhat.com/show_bug.cgi?id=568554 Perhaps bug #690304 is a duplicate of this?
Similar Valgrind warnings are reproduced running: valgrind gs/debugobj/gs -dNOGC -o/dev/null -sDEVICE=nullpage \ comparefiles/Bug689666.pdf The earliest revision that show these warnings is 10822. This revision adds many new names to a list of known glyph names. With the new glyph list the bug goes back to at least rev. 8950. With the old list, these warnings appear first in rev. 11171, which introduces AES encryption. In short, my attempts to find a revision that introduces this bug have failed. The bug doesn't appear on 32-bit Linux. Comparison between 32- and 64-bit systems may lead to the resolution of this bug. Fedora bugs are indeed the duplicates.
*** Bug 691390 has been marked as a duplicate of this bug. ***
with current HEAD (11610) I do not see segfaults any longer and a valgrind run does not show any invalid reads so I believe that the fix for Bug 691380 also fixed this one. Thanks! Cheers T. *** This bug has been marked as a duplicate of bug 691380 ***
(In reply to comment #9) > with current HEAD (11610) I do not see segfaults any longer and a valgrind run > does not show any invalid reads > > so I believe that the fix for Bug 691380 also fixed this one. Thanks! Thanks for testing it, it is very much appreciated!