| Summary: | ps2pdf segfaults when converting the attached ps file on linux x86_64 | ||
|---|---|---|---|
| Product: | Ghostscript | Reporter: | keinbiervorvier <keinbiervorvier> |
| Component: | PS Interpreter | Assignee: | Alex Cherepanov <alex> |
| Status: | RESOLVED DUPLICATE | ||
| Severity: | normal | CC: | alex, chris.liddell, daw-misc, htl10, twaugh |
| Priority: | P4 | ||
| Version: | master | ||
| Hardware: | PC | ||
| OS: | Linux | ||
| Customer: | Word Size: | --- | |
| Attachments: |
Cappellari_Voronoi_Binning_Review.ps
package-with-fonts.tar.gz |
||
|
Description
keinbiervorvier
2009-12-15 20:51:19 UTC
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! |