GNOME Bugzilla – Bug 91384
unaligned access when displaying an image
Last modified: 2004-09-13 09:53:57 UTC
Example: Unaligned access pid=6069 <gimp-1.3> va=0x11ffff6a4 pc=0x3ff800dfd30 ra=0x3ff800dfcbc inst=0xb5c30000 This occurs every time I update the preview of an image, or I select an image whose preview has already been updated, or when I open an image (when the image is finally displayed).
I am not too familiar with OSF/1, but I know that some compilers or debuggers have an option to send a signal to a process when it does an unaligned data access. It would be very useful if you could enable that option and get a stack trace showing where the problem occurs.
Unfortunately, the -mstrict-align option of GCC is not available for the DEC Alpha architecture. Moreover, GDB discovers one of its internal errors when I try applying it to Gimp! As a further indication, when I call Gimp and it opens five windows (toolbox, three Gimp Docks and the tip-of-the-day), the unaligned access error occurs exactly 12 times. Opening a new image, drawing something and saving it as an xcf file triggers the access error once. And the instruction is always the same one, at the same location.
Well... Maybe you should recompile and reinstall a more recent version of gdb and see if it works better? Otherwise, I think that OSF/1 has dbx or some other debugger available as part of the default installation. But maybe I am wrong. It would be nice if you could set a breakpoint at the address that is reported by the warning message.
The version of gdb I use is the last one, dated July 23 of the present year. I cannot use dbx, because the needed license is not installed. Moreover, how to place a breakpooint when I only have an absolute, numerical address? The only more precise information I can get is that the unaligned access occurs when displaying the image preview in the Open Image window. If the preview comes from xv, and is considered obsolete, there is no error. If I ask for updating a preview which cannot be built (unrecognized file), the error does occur.
It's a pity that you cannot use gdb nor dbx. Regarding the breakpoints, gdb allows you to set a breakpoint at an absolute address by using something like this: "break *0x3ff800dfd30". In dbx, you would do the same with "stopi at 0x3ff800dfd30" (assuming that the OSF/1 version of dbx is not too different from the Solaris version that I am using). You mention that you get the warning when the thumbnails are displayed or refreshed, and also when you open the image. Do you also get the warning if you open the image from the command line, using something like "gimp myimage.png" (in addition to the 12 warnings that you mentioned above)? If yes, do you get the warning several times if you open more than one image from the command line?
I get the impression that gdb fails because of the very large size of the symbol table (the gimp image is 67Mb unstripped). I tried putting breaks in the various addresses given by the warning. Those that work always are in readv () from /usr/shlib/libc.so. The bt command does not give any useful information. The unaligned access warning does not occur when I open an image, but when I select it in the Open image window and the preview has already been updated. I started a gimp without any dialog windows. Opening an image from the command line does not trigger the warning. Opening the Brush dialog triggers it 6 times. Opening the document history dialog triggers it twice the number of documents in the history. Other dialogs do not trigger it.
Hmmm... Without a stack trace, it is hard to guess where the problem could be. Does OSF/1 have a command like "truss" (Solaris) or "strace" (Linux) that shows the system calls performed during the execution of a program? That could give some useful information. Also, this may be a stupid question, but did you try disabling any compiler optimizations while building glib, gtk+ and gimp? I don't think this changes much for the debugger, but this could be a source of problems. It is very interesting to know that opening an image from the command line does not trigger the warning. Did you also try the Undo History dialog that you can get from an open image? Does it also generate a warning, or is does it work without problems like the other dialogs (except for the brushes)?
I don't know in OSF1 of anything similar to truss of strace. If it exists, certainly I don't have the license. I'm trying compiling again the Gimp without any optimisation. I already compiled and tested it on another Alpha computer, with gcc-3.1 and much more memory. An older version gdb failed before loading the symbol table. The newest version produces the same error as on the previous computer. The undo dialog does not trigger the unaligned access warning.
I am really confused now. I thought that the warning could be caused by the preview widgets, but then you should have seen it in the Undo History window. If it doesn't show up there, then the problem comes from some other part of the code. I hope that you will be able to find a way to debug the GIMP on OSF/1...
I compiled gimp without any optimisation. The result is worse! ./gimp-1.3 --verbose parsing "/usr/local/etc/gimp/1.3/gimprc" parsing "/usr/local/.gimp-1.3/gimprc" Adding theme 'Default' (/usr/local/share/gimp/1.3/themes/Default) Parsing '/usr/local/share/gimp/1.3/themes/Default/gtkrc' Parsing '/usr/local/.gimp-1.3/gtkrc' loading module: '/usr/local/lib/gimp/1.3/modules/libcolorsel_triangle.so' loading module: '/usr/local/lib/gimp/1.3/modules/libcdisplay_gamma.so' loading module: '/usr/local/lib/gimp/1.3/modules/libcdisplay_highcontrast.so' ** (gimp-1.3:28094): WARNING **: Could not find XftConfig file cannot open file "/usr/X11R6/lib/X11/XftConfig" querying plug-in: "/usr/local/lib/gimp/1.3/plug-ins/tool-safe-mode" writing "/usr/local/.gimp-1.3/pluginrc" initializing plug-in: "/usr/local/lib/gimp/1.3/plug-ins/tool-safe-mode" Unaligned access pid=28094 <gimp-1.3> va=0x11ffff68c pc=0x30005829894 ra=0x30005829880 inst=0x9d4f0000 zsh: 28094 illegal hardware instruction (core dumped) GDB cannot tell me more. I filed also a bug report for GDB...
Do you perhaps have a chance to try a never version of GIMP-1.3 and report back?
Changes at the request of Dave Neary on the developer mailing list. I am changing many of the bugzilla reports that have not specified a target milestone to Future milestone. Hope that is acceptable.
Isn't this just a duplicate of the tool-safe-mode bug? Remove that plug-in, and all will be well. And please upgrade to a 2.0 pre-release, it would be nice to have a confirmation that we work on OSF/1. Cheers, Dave. *** This bug has been marked as a duplicate of 118517 ***
This has absolutely nothing to do with tool-safe-mode. The reporter says it happens each time when updating the image's view.
Bumping a bunch of bugs which won't block the 2.0 release to 2.0.1. Dave.
Is this problem still reproducable with GIMP-2.0 at all ?
I have Tru64 access and expertise, but unfortunately I've been stymied by another problem (SEGV when starting script-fu) that hasn't allowed me to get past startup. It's bug # 129867. I honestly don't think it's a gimp bug, I think it's glib bug, but I haven't had a chance to check on it. I can perhaps give ol some help though. Regarding debuggers: gdb works poorly on OSF/1 and Tru64, because it (really libbfd I think) doesn't have full object file and core file support. Some versions of ladebug do not require a developer license, and ladebug is the best debugger available from Compaq/HP. Try downloading that, and see if that works. Regarding truss: The 5.x Tru64 series has some system V utilities, including truss, in /usr/opt/svr4. I think the products are on the "Associated Products" CDs. I'm not sure if it requires a license to install, but I would try getting that installed. If that doesn't work, there is a free truss-like program called alpha-trace, available from John Hascall at Iowa State University. It's available at ftp://ftp.iastate.edu/pub/unix/osf1/trace Regarding unaligned accesses: These can be turned into full bus errors (for easier debugging) by using the `uac' command. Basically, just run uac p sigbus and then fire up gimp under a debugger (or system call tracer a la alpha-trace, if you can't find a working debugger that doesn't require a license) and work with it normally. Instead of unaligned access messages, you'll get a bus error. Should make it easier to debug where this is happening. Hope this helps.
Removing the script-fu plug-in from the plug-in path would probably get you further.
Bumping this bug-report to the 2.0.2 milestone. We are still interested to fix this but it should not block the 2.0.1 release.
I took Sven's suggestion and removed script-fu from my 2.0.1 plug-ins directory, to get by the problem I'm running into with bug # 129867. I have tried all the things that ol mentioned in comment #6, and none of them trigger an unaligned access warning from the gimp. I'm wondering if Yosh nailed this problem when he was doing 64 bit fixes for IA64 a while back? ol, can you still reproduce this problem with any recent gimp version? If you can still reproduce, could you try some of the things I suggested in comment #17? I would be happy to help you get ladebug going and/or help with the other bits, if needed.
Is this still an issue? Judging from Tim's last comment it looks as if this problem might have been fixed in the meantime.
Moving all bugs remaining on the 2.0.3 milestone to 2.0.4.
I vote closing this as either NOTABUG or FIXED. Dave.
Moving remaining bugs from milestone 2.0.4 to milestone 2.0.4
Let's assume this was FIXED then.