GNOME Bugzilla – Bug 138357
attempting to load a JPEG image fails on ia64
Last modified: 2004-04-10 02:58:37 UTC
Attempting to load any image on ia64 leads to errors such as the following: when GIMP is built with GCC (3.3.3): /usr/lib/gimp/2.0/plug-ins/jpeg: relocation error: /usr/lib/libgimp-2.0.so.0: undefined symbol: __udivsi3 (there are many other occurences of this symbol being missing reported as GIMP loads) when GIMP is built with the Intel C compiler (8.0.058_pl063.1): /home/duraid/gimp/lib/gimp/2.0/plug-ins/jpeg: fatal error: Bus error (this is the first and only warning emitted to the console for the entire GIMP run, i.e. GIMP loads silently)
Oops, time for the paper bag! Replace "image" with "JPEG image" in the above - loading a PNG seems to work fine, as does loading a TIFF. Finally, running the Intel compiler version again, I notice the following: jpeg(4420): unaligned access to 0x60000fffffffb058, ip=0x2000000000fa7390 (just before the bus error) I don't recall GIMP ever doing unaligned accesses like this before (certainly not the JPEG plugin) so perhaps one can get an ip that is related to some change that has broken the JPEG plugin on this platform.
undefined symbol: __udivsi3 is typically caused by mismatched libgcc.a versions, so something is wrong with your gcc setup. As for the problems with the intel compiler, it'd help to get a stack trace.
JPEG loading works fine for me with gcc 3.2.2 on ia64. It could be that a) the jpeg plugin is doing something wrong, but gcc lets us get away with it or b) icc is emitting buggy code. Either way, a stack trace would help.
What's the easiest way to get a stack trace from a plugin? I seem to get: (gdb) where
+ Trace 45474
:/ (for the intel one. the bug is present regardless of compiler optimization options, so I'd be a *little* sceptical that icc is emitting bad code, but still....)
Debugging a plug-in is described in the file debug-plug-ins.txt included in the GIMP tarball (also mentioned on in http://developer.gimp.org/faq.html) Sincerely, Brix
OK, I think I know what's going on here. The problem is in fact the unaligned access: on ia64, jmp_buf (i.e. jerr.setjmp_buffer of line 776 of plug-ins/common/jpeg.c) has to be 16-byte aligned. The quick and nasty hack is to reorder the members of my_error_mgr so that it reads: typedef struct my_error_mgr { /* On ia64, it is necessary to 16-byte align jmp_buf */ jmp_buf setjmp_buffer; /* for return to caller */ struct jpeg_error_mgr pub; /* "public" fields */ } *my_error_ptr; patch follows..
Created attachment 26075 [details] [review] fix for the jpeg plugin to work on ia64 This patch makes things work, but it isn't *fully* tested: haven't tried loading bogus JPEG images (or otherwise force the JPEG code to error)
P.S. May I congratulate the GIMP team on being 100% Intel C compliant ;) There are some really nice speed gains on itanium systems...
Ah, that's why it tripped with icc but not gcc.. from bits/setjmp.h: typedef long __jmp_buf[_JBLEN] __attribute__ ((aligned (16))); /* guarantees 128-bit alignment! */ I guess icc (or at least the icc version you used) doesn't honor that gcc attribute. There's a fix for that here: http://sources.redhat.com/ml/libc-hacker/2003-03/msg00148.html but it doesn't seem to be in the glibc tree yet. The workaround in your patch is fine, I'll commit it, thanks. Next time please use diff -u output though.
2004-03-29 Manish Singh <yosh@gimp.org> * plug-ins/common/jpeg.c (struct my_error_mgr): Move setjump_buffer to the beginning of the structure, to make sure it is aligned on a 16-byte boundary for ia64, even with icc. Fixes #138357.
Ugh, that didn't exactly work, please test the following patch that went with this commit and reopen the bug if it still happens for you. 2004-04-09 Manish Singh <yosh@gimp.org> * plug-ins/common/jpeg.c: Uglier workaround for bug #138357, since the previous one did break error handling. Fixes bug #139571.
Created attachment 26536 [details] [review] Uglier workaround
And really, if current icc on ia64 doesn't honor __attribute__ (aligned), that would be a bug in icc since it claims to support gccisms.
I was using 'icc -no-gcc' because I *don't* want my compiler accepting GCCisms. Do you? If so, better document that GIMP requires GCC to build. If not, better fix GIMP so that it doesn't. That's what this bug is about, right? Also, an unfortunate discovery: it's not just the JPEG plugin that's like this. PPM too, and probably others (all of them?) PNG didn't seem to have a problem though, I *think*. Hmm.
Well, icc -no-gcc is a bad idea on ia64, because until glibc is changed, jmp_buf's aren't guaranteed to be aligned properly. Perhaps there's other things like this too in glibc so you might run into other problems later. It's not GIMP that needs it, it's glibc. We're just attempting to workaround it, which is leading to ugly hacks. I suggest you stop using -no-gcc.