|
Bugzilla – Full Text Bug Listing |
| Summary: | Gimp 2.2.8 fails to start on k6-II (illegal instruction) | ||
|---|---|---|---|
| Product: | [openSUSE] SUSE LINUX 10.0 | Reporter: | Richard Driscoll <rjdriscoll> |
| Component: | X11 Applications | Assignee: | Stanislav Brabec <sbrabec> |
| Status: | RESOLVED FIXED | QA Contact: | Stefan Dirsch <sndirsch> |
| Severity: | Major | ||
| Priority: | P5 - None | ||
| Version: | unspecified | ||
| Target Milestone: | --- | ||
| Hardware: | i686 | ||
| OS: | SuSE Linux 10.0 | ||
| Whiteboard: | |||
| Found By: | Customer | Services Priority: | |
| Business Priority: | Blocker: | --- | |
| Marketing QA Status: | --- | IT Deployment: | --- |
|
Description
Richard Driscoll
2005-11-15 11:33:14 UTC
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. |