Created attachment 11534 [details] Strace output Some pdf files generated by matplotlib can not be rasterized by gsc. gsc -q ./fs_components_func.pdf [1] 2031 segmentation fault (core dumped) gsc -q ./fs_components_func.pdf gsc --version 9.15 I use Arch Linux x86_64 and the latest gs from the extra repository. The only patch applied by the maintainers forces the usage of system zlib.
Created attachment 11535 [details] Problem PDF file
Ghostscript is an interpreter, not a compiler....
gsc is used by Scribus to generate previews and rasterize documents with encapsulated pdf files. Previews for some of my files were not working in Scribus, investigation led me to this bug.
I've tried this on 32 and 64-bit Windows and 32-bit Linux and am unable to reproduce a problem either with the 9.15 release or with current code. I'll ask one of my colleagues to try 64-bit Linux shortly as I don't currently have access to a 64-bit Linux. I'm slightly puzzled by your use of 'gsc' as, to the best of my knowledge which is admittedly imperfect on Linux, we don't create a 'gsc' binary on Linux, its called 'gs'. However this may be a quirk of the distribution or something. Until I can get someone to run a 64-bit comparison my suggestion would be to get the current Ghostscript source (or at least the released 9.15 source), build that, and test again. The fact that its using a system zlib could easily be the problem. I'd also be a little surprised if zlib was the only system shared library, if they've decided to use one shared library I would expect that all of them would be shared. You might also try using valgrind or running a debug executable under gdb. I'm afraid the output of strace is not at all helpful.
Oh, and I would not set -q while trying to debug a problem, if Ghostscript is trying to tell you something, you probably want to see it, not hide it.
Created attachment 11536 [details] Stack trace from gdb
I recompiled the same version with debug symbols and run it in GDB. I hope it is more informative.
This 'looks like' a bug which has already been fixed. Its exposed by a change in the pthread library. Fixed in commit 444e0bf9c43bae0261660e6318ba0e514c18d41e (though I'd pull the latest source myself). The fix will be in the 9.16 release which is currently in its second release candidate so you can wait for that, or use any of the other suggested workarounds in comment #19 on bug 695862: http://bugs.ghostscript.com/show_bug.cgi?id=695862 *** This bug has been marked as a duplicate of bug 695862 ***
Only an addendum FYI: (In reply to Ken Sharp from comment #4) > I'm slightly puzzled by your use of 'gsc' as, to the best of my knowledge > which is admittedly imperfect on Linux, we don't create a 'gsc' binary on > Linux, its called 'gs'. However this may be a quirk of the distribution or > something. On Linux plain "make ; make install" creates the "gs" binary but "make so ; make soinstall" creates additionally a "gsc" binary (plus a "gsx" binary). As far as I can tell the difference between the "gs" binary and the "gsc" binary is that "gs" has "libgs" compiled-in while "gsc" is dynamically linked with "libgs".
(In reply to Ken Sharp from comment #8) > This 'looks like' a bug which has already been fixed. Its exposed by a > change in the pthread library. Fixed in commit > 444e0bf9c43bae0261660e6318ba0e514c18d41e (though I'd pull the latest source > myself). > > The fix will be in the 9.16 release which is currently in its second release > candidate so you can wait for that, or use any of the other suggested > workarounds in comment #19 on bug 695862: > > http://bugs.ghostscript.com/show_bug.cgi?id=695862 > > *** This bug has been marked as a duplicate of bug 695862 *** It is almost certainly that bug - it seems a change in the glibc/pthreads implementation has exposed the problem, so people are seeing it as distros roll out the update.
I tried patching makefile as was suggested here: http://bugs.ghostscript.com/show_bug.cgi?id=695862#c19 It works for me now. The same problem indeed.
(In reply to Sergey Malkin from comment #11) > I tried patching makefile as was suggested here: > http://bugs.ghostscript.com/show_bug.cgi?id=695862#c19 > It works for me now. The same problem indeed. That's good to know, thanks for updating us!