Bug#653061: libgs9 exports symbols conflicting with the same symbols in libjpeg8
Hi, i'm unlucky with that bug too, any kind of progress or workaround ? On squeeze system, adding "-lgs" to gcc stuff.c -o stuff `pkg-config gthread-2.0 gtk+-2.0 webkit-1.0 --cflags --libs` -lfcgi -luriparser just makes the program segfault, because webkit uses libjpeg8. Cheers, Jérémy. -- To UNSUBSCRIBE, email to debian-printing-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/4f4d6c4c.6050...@melix.org
Bug#653061: libgs9 exports symbols conflicting with the same symbols in libjpeg8
Bill Allombert wrote:
> The short answer is that it is not possible.
Alas. Thanks for checking.
*checks* Wait, is the long answer that it _is_ possible? :) The
"mem" field seems to do exactly what I'd want.
> But you can use versionned symbols.
Do you mean that libgs should explicitly override
jpeg_get_small@LIBJPEG_8.0 et al instead of using unversioned symbols?
If so, I'd agree, but I don't think it would help with this crash.
Please feel free to skip the following background[*] unless morbidly
curious.
Thanks much,
Jonathan
[*] In ghostscript, the context object when using libjpeg is
the jpeg_compress_data struct. The notable fields for us at the moment
are:
typedef struct jpeg_compress_data_s {
...
gs_memory_t *memory;/* heap for library allocations */
...
struct jpeg_compress_struct cinfo;
...
} jpeg_compress_data;
Ghostscript is designed to be _very_ flexible about the environment it
runs in, since one of the target environments is printer firmware and
saving money on processing power or memory in that context is
desirable. In particular, ghostscript maintains a private heap to
avoid overhead from, for example, unnecessarily maintaining alignment
of strings.
A vtable with memory management routines can be found in the
jpeg_compress_data::memory field. But the jpeg_compress_struct object
provided by non-ghostscript callers is not part of a larger
jpeg_compress_data, so attempts to downcast and access that field
segfault.
Luckily, libgs's custom allocator support is not part of the public
interface documented in its headers, so we are not too constrained in
solving this.
Possible fixes:
a) stop using a custom allocator for libgs's jpeg support
b) set custom allocators in the jpeg_compress_struct::mem field
instead of globally overriding the system-dependent memory manager
c) use a magic value for jpeg_compress_struct::client_data to
distinguish between ghostscript and non-ghostscript callers to the
memory manager and fall back to the stock libjpeg versions for
non-ghostscript calls
Of these, (b) seems the most appealing, but maybe (a) is a better
choice.
--
To UNSUBSCRIBE, email to debian-printing-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/20111229110155.GB29150@elie.Belkin
Bug#653061: libgs9 exports symbols conflicting with the same symbols in libjpeg8
On Fri, Dec 23, 2011 at 11:27:18PM +0100, Bill Allombert wrote: > On Fri, Dec 23, 2011 at 03:46:59PM -0600, Jonathan Nieder wrote: > > Hi, > > > > Jean Brefort wrote: > > > > > Three symbols are concerned: > > > jpeg_mem_init, jpeg_mem_term and jpeg_mem_available. > > > > > > Building an executable using the two libraries might crash. This happens > > > for me > > > with gnumeric (from git) when goffice is built with eps support and when > > > I try > > > to add a jpeg image inside a sheet. > > Hello, > > Since libjpeg8 uses versionned symbols, I would suggest libgs9 to use > different > symbol version for these three symbols. > > > More details would be useful, including a stacktrace or error messages > > if possible. > > > > >From gs/base/sjpegc.c: > > > > Ghostscript uses a non-public interface to libjpeg in order to > > override the library's default memory manager implementation. > > Is it still necessary with libjpeg8 ? > > > Do you know if libjpeg provides a way to use a custom allocator > > without interfering with other modules in the same process image > > that might not want to use it? > > I will ask upstream. The short answer is that it is not possible. But you can use versionned symbols. Cheers, -- Bill. Imagine a large red swirl here. -- To UNSUBSCRIBE, email to debian-printing-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20111228222805.GC2886@yellowpig
Bug#653061: libgs9 exports symbols conflicting with the same symbols in libjpeg8
Sample stack trace: #0 0x7fffef66486b in ?? () from /usr/lib/libgs.so.9 #1 0x7fffeea3a997 in jinit_memory_mgr (cinfo=0x7ffea380) at jmemmgr.c:1059 #2 0x7fffeea1b32e in jpeg_CreateDecompress (cinfo=0x7ffea380, version=, structsize=656) at jdapimin.c:59 #3 0x7fffe1cee128 in ?? () from /usr/lib/x86_64-linux-gnu/gdk-pixbuf-2.0/2.10.0/loaders/libpixbufloader-jpeg.so #4 0x75b09d4e in ?? () from /usr/lib/x86_64-linux-gnu/libgdk_pixbuf-2.0.so.0 #5 0x75b0a03c in gdk_pixbuf_new_from_file () from /usr/lib/x86_64-linux-gnu/libgdk_pixbuf-2.0.so.0 Le vendredi 23 décembre 2011 à 23:27 +0100, Bill Allombert a écrit : > On Fri, Dec 23, 2011 at 03:46:59PM -0600, Jonathan Nieder wrote: > > Hi, > > > > Jean Brefort wrote: > > > > > Three symbols are concerned: > > > jpeg_mem_init, jpeg_mem_term and jpeg_mem_available. > > > > > > Building an executable using the two libraries might crash. This happens > > > for me > > > with gnumeric (from git) when goffice is built with eps support and when > > > I try > > > to add a jpeg image inside a sheet. > > Hello, > > Since libjpeg8 uses versionned symbols, I would suggest libgs9 to use > different > symbol version for these three symbols. > > > More details would be useful, including a stacktrace or error messages > > if possible. > > > > >From gs/base/sjpegc.c: > > > > Ghostscript uses a non-public interface to libjpeg in order to > > override the library's default memory manager implementation. > > Is it still necessary with libjpeg8 ? > > > Do you know if libjpeg provides a way to use a custom allocator > > without interfering with other modules in the same process image > > that might not want to use it? > > I will ask upstream. > > Cheers, -- To UNSUBSCRIBE, email to debian-printing-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/1324711601.2433.1.ca...@vaio.brefort.fr
Bug#653061: libgs9 exports symbols conflicting with the same symbols in libjpeg8
On Fri, Dec 23, 2011 at 03:46:59PM -0600, Jonathan Nieder wrote: > Hi, > > Jean Brefort wrote: > > > Three symbols are concerned: > > jpeg_mem_init, jpeg_mem_term and jpeg_mem_available. > > > > Building an executable using the two libraries might crash. This happens > > for me > > with gnumeric (from git) when goffice is built with eps support and when I > > try > > to add a jpeg image inside a sheet. Hello, Since libjpeg8 uses versionned symbols, I would suggest libgs9 to use different symbol version for these three symbols. > More details would be useful, including a stacktrace or error messages > if possible. > > >From gs/base/sjpegc.c: > > Ghostscript uses a non-public interface to libjpeg in order to > override the library's default memory manager implementation. Is it still necessary with libjpeg8 ? > Do you know if libjpeg provides a way to use a custom allocator > without interfering with other modules in the same process image > that might not want to use it? I will ask upstream. Cheers, -- Bill. Imagine a large red swirl here. -- To UNSUBSCRIBE, email to debian-printing-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20111223222718.GD18843@yellowpig
Bug#653061: libgs9 exports symbols conflicting with the same symbols in libjpeg8
Hi, Jean Brefort wrote: > Three symbols are concerned: > jpeg_mem_init, jpeg_mem_term and jpeg_mem_available. > > Building an executable using the two libraries might crash. This happens for > me > with gnumeric (from git) when goffice is built with eps support and when I try > to add a jpeg image inside a sheet. More details would be useful, including a stacktrace or error messages if possible. >From gs/base/sjpegc.c: Ghostscript uses a non-public interface to libjpeg in order to override the library's default memory manager implementation. Do you know if libjpeg provides a way to use a custom allocator without interfering with other modules in the same process image that might not want to use it? Thanks, Jonathan -- To UNSUBSCRIBE, email to debian-printing-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20111223214658.GC21769@elie.Belkin
Bug#653061: libgs9 exports symbols conflicting with the same symbols in libjpeg8
Package: libgs9 Version: 9.04~dfsg-3 Severity: important Three symbols are concerned: jpeg_mem_init, jpeg_mem_term and jpeg_mem_available. Building an executable using the two libraries might crash. This happens for me with gnumeric (from git) when goffice is built with eps support and when I try to add a jpeg image inside a sheet. -- System Information: Debian Release: wheezy/sid APT prefers unstable APT policy: (500, 'unstable') Architecture: amd64 (x86_64) Kernel: Linux 3.1.0-1-amd64 (SMP w/2 CPU cores) Locale: LANG=fr_FR.UTF-8, LC_CTYPE=fr_FR.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Versions of packages libgs9 depends on: ii gs-cjk-resource 1.20100103-3 ii libc6 2.13-23 ii libcomerr21.42-1 ii libcups2 1.5.0-13 ii libcupsimage2 1.5.0-13 ii libfontconfig12.8.0-3 ii libgcrypt11 1.5.0-3 ii libgnutls26 2.12.14-5 ii libgs9-common 9.04~dfsg-3 ii libgssapi-krb5-2 1.10+dfsg~alpha1-6 ii libidn11 1.23-2 ii libijs-0.35 0.35-8 ii libjasper11.900.1-12 ii libjbig2dec0 0.11-1 ii libjpeg8 8c-2 ii libk5crypto3 1.10+dfsg~alpha1-6 ii libkrb5-3 1.10+dfsg~alpha1-6 ii liblcms2-22.2+git20110628-2 ii libpaper1 1.1.24+nmu1 ii libpng12-01.2.46-3 ii libstdc++64.6.2-9 ii libtiff4 3.9.5-2 ii zlib1g1:1.2.3.4.dfsg-3 libgs9 recommends no packages. libgs9 suggests no packages. -- no debconf information -- To UNSUBSCRIBE, email to debian-printing-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20111223105945.11032.71916.report...@vaio.brefort.fr
