Bugzilla – Bug 133813
Gimp 2.2.8 fails to start on k6-II (illegal instruction)
Last modified: 2006-01-05 15:25:50 UTC
On my AMD k6-II 500 MHz. running Suse 10.0, Gimp fails to start because of an illegal instruction. The initial setup of .gimp2-2 directory, Tile cache and swap folder is OK. Starting from a terminal (after the initial setup) I get: rjd@dart:~> gimp --verbose INIT: gimp_load_config Parsing '/etc/gimp/2.0/gimprc' Parsing '/home/rjd/.gimp-2.2/gimprc' Illegal instruction kernel:- rjd@dart:~> uname -r 2.6.13-15-default rjd@dart:~> cpuinfo:- rjd@dart:~> cat /proc/cpuinfo processor : 0 vendor_id : AuthenticAMD cpu family : 5 model : 8 model name : AMD-K6(tm) 3D processor stepping : 12 cpu MHz : 501.228 cache size : 64 KB fdiv_bug : no hlt_bug : no f00f_bug : no coma_bug : no fpu : yes fpu_exception : yes cpuid level : 1 wp : yes flags : fpu vme de pse tsc msr mce cx8 pge mmx syscall 3dnow k6_mtrr bogomips : 1004.68 System memory:- 192 Mbyte I can supply any other info you may require.
Please create a backtrace with gdb and/or ltrace/strace and attach it here.
rjd@dart:~> gdb gimp GNU gdb 6.3 Copyright 2004 Free Software Foundation, Inc. GDB is free software, covered by the GNU General Public License, and you are welcome to change it and/or distribute copies of it under certain conditions. Type "show copying" to see the conditions. There is absolutely no warranty for GDB. Type "show warranty" for details. This GDB was configured as "i586-suse-linux"...(no debugging symbols found) Using host libthread_db library "/lib/tls/libthread_db.so.1". (gdb) r Starting program: /opt/gnome/bin/gimp (no debugging symbols found) . .(... more of this) . (no debugging symbols found) [Thread debugging using libthread_db enabled] [New Thread 1084375200 (LWP 5014)] (no debugging symbols found) . .(...more of this) . Program received signal SIGILL, Illegal instruction. [Switching to Thread 1084375200 (LWP 5014)] 0x08250f21 in ?? () (gdb) bt #0 0x08250f21 in ?? () #1 0x0830a300 in _IO_stdin_used () #2 0x40016500 in ?? () #3 0x000009b8 in ?? () #4 0x08260b82 in ?? () #5 0x08359270 in ?? () #6 0x00000042 in ?? () #7 0x00000180 in ?? () #8 0x407feb20 in ?? () from /opt/gnome/lib/libglib-2.0.so.0 #9 0x08359208 in ?? () #10 0x08413c98 in ?? () #11 0xbf97e478 in ?? () #12 0x00000001 in ?? () #13 0x08359208 in ?? () #14 0x08413c98 in ?? () #15 0xbf97e4b8 in ?? () #16 0x082554ce in ?? () #17 0x00000000 in ?? () #18 0x00000001 in ?? () #19 0x00000000 in ?? () #20 0x00000000 in ?? () #21 0x00000000 in ?? () #22 0x00000000 in ?? () #23 0x081a4560 in ?? () #24 0x08414ac8 in ?? () #25 0x08413560 in ?? () #26 0x08413ce0 in ?? () #27 0x08413cb0 in ?? () #28 0x00000006 in ?? () #29 0x08064d20 in ?? () #30 0x0840c9d8 in ?? () #31 0xbf97e568 in ?? () #32 0x080631d5 in ?? () #33 0x08414ac8 in ?? () #34 0x00000000 in ?? () #35 0x00000001 in ?? () #36 0xbf97e558 in ?? () ---Type <return> to continue, or q <return> to quit--- #37 0x00000000 in ?? () #38 0x00000000 in ?? () #39 0x00000001 in ?? () #40 0x00000000 in ?? () #41 0x00000000 in ?? () #42 0x00000001 in ?? () #43 0xbf97e508 in ?? () #44 0x4092a5f3 in malloc () from /lib/tls/libc.so.6 Previous frame inner to this frame (corrupt stack?) (gdb) . . . Last few lines of "strace gimp --verbose" . . . open("/etc/gimp/2.0/gimprc", O_RDONLY|O_LARGEFILE) = 4 read(4, "# This is the system-wide gimprc"..., 4000) = 4000 read(4, " for fonts. This is a colon-sep"..., 4000) = 4000 read(4, "en dialog will be automatically "..., 4000) = 4000 read(4, "B id of the active layer/channel"..., 4000) = 4000 read(4, "der\n# versions. Possible values"..., 4000) = 4000 read(4, "oolbox-window-hint normal)\n\n# Th"..., 4000) = 1356 read(4, "", 4000) = 0 close(4) = 0 write(1, "Parsing \'/home/rjd/.gimp-2.2/gim"..., 37Parsing '/home/rjd/.gimp-2.2/gimprc' ) = 37 open("/home/rjd/.gimp-2.2/gimprc", O_RDONLY|O_LARGEFILE) = 4 read(4, "# GIMP gimprc\n# \n# This is your "..., 4000) = 295 read(4, "", 4000) = 0 close(4) = 0 gettimeofday({1132071436, 843869}, NULL) = 0 open("/home/rjd/.gimp-2.2", O_RDONLY|O_NONBLOCK|O_LARGEFILE|O_DIRECTORY) = 4 fstat64(4, {st_mode=S_IFDIR|0755, st_size=592, ...}) = 0 fcntl64(4, F_SETFD, FD_CLOEXEC) = 0 getdents64(4, /* 23 entries */, 4096) = 720 getdents64(4, /* 0 entries */, 4096) = 0 close(4) = 0 open("/home/rjd/.gimp-2.2/gimpswap.5054", O_RDWR|O_CREAT|O_LARGEFILE, 0600) = 4 close(4) = 0 unlink("/home/rjd/.gimp-2.2/gimpswap.5054") = 0 --- SIGILL (Illegal instruction) @ 0 (0) --- +++ killed by SIGILL +++ rjd@dart:~> . . ................ so it looks as if it didn't get much beyond parsing the .gimprc file. Let me know if this is any help. I guess I could get the source and compile with debugging info.
When creating backtraces with gdb, please install the *-debuginfo packages for the program, as far as it is available -- the backtrace is of nu much use without. We'll need the help of the GNOME maintainers here.
It's possible to recompile GIMP without MMX patch or try newer version from supplementary. (gdb) run Starting program: /opt/gnome/bin/gimp [Thread debugging using libthread_db enabled] [New Thread 1084375200 (LWP 6248)] Program received signal SIGILL, Illegal instruction. [Switching to Thread 1084375200 (LWP 6248)] 0x08250f21 in gimp_composite_init (be_verbose=0, use_cpu_accel=1) at gimp-composite.c:366 366 gimp_composite_options.bits |= GIMP_COMPOSITE_OPTION_NOEXTENSIONS; (gdb) bt #0 0x08250f21 in gimp_composite_init (be_verbose=0, use_cpu_accel=1) at gimp-composite.c:366 #1 0x082554ce in base_init (config=0x83b1e20, be_verbose=1, use_cpu_accel=1) at base.c:102 #2 0x080631d5 in app_run (full_prog_name=0x1 <Address 0x1 out of bounds>, gimp_argc=0, gimp_argv=0xbfae84e8, alternate_system_gimprc=0x0, alternate_gimprc=0x0, session_name=0x1 <Address 0x1 out of bounds>, batch_interpreter=0x1 <Address 0x1 out of bounds>, batch_commands=0x1, no_interface=0, no_data=1, no_fonts=1, no_splash=1, be_verbose=0, use_shm=1, use_cpu_accel=3, console_messages=1, stack_trace_mode=GIMP_STACK_TRACE_QUERY, pdb_compat_mode=GIMP_PDB_COMPAT_ON) at app_procs.c:268 #3 0x08063d19 in main (argc=1, argv=0xbfae84e4) at main.c:473 #4 0x408d8ea0 in __libc_start_main () from /lib/tls/libc.so.6 #5 0x08062f31 in _start () at start.S:119
I found a compiled version of Gimp 2.9 at ftp.gwdg.de/pub/linux/suse/apt/SuSE/10.0-i386/RPMS.suser-guru/gimp-2.2.9-2.guru.suse100.i686.rpm which I downloaded and tried. It also stopped with an illegal instruction. I then downloaded the 2.9 source and built it on my machine. This works OK (except that I had to build it without printing since the duistributiion doesn't include all the required gimp-print files and I didn't want to take the time to get them). The Gimp source mentions MMX, 3DNow and SSE. My K6-2 does MMX and 3dNow but not SSE. Is a determination made at installation time of the processor capabilities, I wonder, and is the rpm thus dependant on the machine doing the packaging? It seems to me that this problem will occur for several Intel Pentium variants too since these also lack SSE (and 3dNow as for that matter).
The problem is caused by our MMX SSE flag settings, which improves speed on MMX and SSE capable processors. We should find a way, either how to auto-detect this feature, or load one of two libraries depending on processor type.
Confirming, that the mmx patch causes the problem.
Michael, could you advice, how to allow MMX/SSE instruction in an assembly code, but don't generate MMX instructions in the C code?
Didn't we have the same problem in mplayer and concluded that this isn't possible? If you want to write SSE register constraints for the operands of asm statements, you have to activate the SSE register set, but by doing that you implicitely also activate _some_ use of SSE for GCC (e.g. structure moves and such). That means the only way is to compile a whole file with -msse (wherein you can put the sse-requiring assembler), and only ever use functions of that file if you determine at runtime that you have SSE capabilities. That's the problem of granularity, i.e. -msse only works file-wise :-(
I have a patch, which fixes GIMP in 10.0. Copiles with MMX/SSE support and starts on K6-2 machine. Should I prepare YaST Online Update or should I fix it only for EDGE/supplementary. If YOU, the recommended or optional?
Fix it only for the next release.
It seems that version 2.2.9 has this problem fixed: http://bugzilla.gnome.org/show_bug.cgi?id=308412 I am just now updating to 2.2.10. It has some problems with MMX/SSE code, but -O0 works-around it. I am closing the bug and expecting, that it's fixed.