The short story is : segfault when linking against libgs and another library that use libjpeg8. Please see http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=653061#30 for a better explanation. I don't think that bug is only relevant to debian and its use of shared libs.
The bug is described in gs/base/sjpegc.c: Ghostscript uses a non-public interface to libjpeg in order to override the library's default memory manager implementation. Ghostscript intentionally overrides the jpeg_get_small and jpeg_get_large symbols. Presumably at the time this code was written there was no other way to tell libjpeg to use a custom allocator. Ghostscript's implementations of jpeg_get_small and jpeg_get_large behave mostly like libjpeg's but examine container_of(cinfo, jpeg_compress_data, cinfo)->memory to get the allocation routines that ghostscript chose for this run. If there is some non-libgs use of libjpeg in the same process image passing jpeg_common_struct pointers that are not from a cinfo object, segfault: #0 0x00007fffef66486b in ?? () from /usr/lib/libgs.so.9 #1 0x00007fffeea3a997 in jinit_memory_mgr (cinfo=0x7ffffffea380) at jmemmgr.c:1059 #2 0x00007fffeea1b32e in jpeg_CreateDecompress (cinfo=0x7ffffffea380, version=<optimized out>, structsize=656) at jdapimin.c:59 #3 0x00007fffe1cee128 in ?? () from /usr/lib/x86_64-linux-gnu/gdk-pixbuf-2.0/2.10.0/loaders/libpixbufloader-jpeg.so #4 0x00007ffff5b09d4e in ?? () from /usr/lib/x86_64-linux-gnu/libgdk_pixbuf-2.0.so.0 #5 0x00007ffff5b0a03c in gdk_pixbuf_new_from_file () from /usr/lib/x86_64-linux-gnu/libgdk_pixbuf-2.0.so.0 Luckily nowadays libjpeg provides some memory management hooks in "struct jpeg_memory_mgr" used for the cinfo->mem field these days. If someone gets a chance to try overriding the memory management methods there instead of globally, that would probably fix this bug.
(In reply to comment #1) > > Luckily nowadays libjpeg provides some memory management hooks in > "struct jpeg_memory_mgr" used for the cinfo->mem field these days. > If someone gets a chance to try overriding the memory management > methods there instead of globally, that would probably fix this bug. Unfortunately, my initial investigation suggests this trivial to implement - it means, at least, writing our own initialization routines for encode and decode. I'm not very sure about that, because the two routines setup more than just the memory manager. I'll look more closely tomorrow. A much simpler workaround (much more suitable for a patch for distribution package) is simply to let libjpeg handle its own memory management when Ghostscript is linked with the shared library version. My preference is to do the latter, simpler workaround for immediate use, and potentially do the more complex "full fix" for release in 9.06.
(In reply to comment #2) > > Unfortunately, my initial investigation suggests this trivial to implement - it Should read "....suggests this is not trivial to implement...."
Trivially removing the jpeg_* functions at the end of base/sjpegc.c fixes the issue for me.
I've committed the first (possibly only) stage: http://git.ghostscript.com/?p=ghostpdl.git;a=commitdiff;h=ceef32 So, we'll no longer do the libjpeg low level memory manager hackery if Ghostscript is linked with a shared libjpeg library. Now, I'm struggling to find an "official" way to setup memory management hooks described above. Currently the only way I see is writing our own version of jpeg_CreateCompress() (separate from the libjpeg one, not replacing the libjpeg one). I'm reluctant to do that because it could turn into a maintenance nightmare! It *looks* to me like that struct jpeg_memory_mgr stuff is still a *link* time option, not a run-time option. If anyone knows different, knows where I could ask (libjpeg development still seems a bit of a "black box"), or knows of an example that proves me wrong, please point me to it!
As mentioned above, I can't find an "official" (dependable!) way to allow the libjpeg memory management functions to be a run-time option (they seem to be purely a link-time option). So I'm closing this as we have a work-around that works. If anyone cares to prove me wrong on the above, please do! Reopen this bug, and point me at the information.