GNOME Bugzilla – Bug 410827
crash in gThumb Image Viewer: Viewing an svg image in ...
Last modified: 2007-02-24 14:32:04 UTC
What were you doing when the application crashed? Viewing an svg image in /usr/share/icons/gnome/scalable/devices. Thumbnailing works OK, but image viewer crashes. Distribution: Fedora Core release 6 (Zod) Gnome Release: 2.16.3 2007-01-31 (Red Hat, Inc) BugBuddy Version: 2.16.0 System: Linux 2.6.18-1.2868.fc6 #1 SMP Fri Dec 15 17:32:54 EST 2006 i686 X Vendor: The XFree86 Project, Inc X Vendor Release: 40300000 Selinux: No Accessibility: Disabled Memory status: size: 107143168 vsize: 0 resident: 107143168 share: 0 rss: 19439616 rss_rlim: 0 CPU usage: start_time: 1172156673 rtime: 0 utime: 143 stime: 0 cutime:131 cstime: 0 timeout: 12 it_real_value: 0 frequency: 0 Backtrace was generated from '/usr/bin/gthumb' Using host libthread_db library "/lib/libthread_db.so.1". [Thread debugging using libthread_db enabled] [New Thread -1209014560 (LWP 3286)] [New Thread -1305322608 (LWP 3303)] [New Thread -1305289840 (LWP 3302)] [New Thread -1305257072 (LWP 3301)] [New Thread -1252775024 (LWP 3294)] [New Thread -1252742256 (LWP 3293)] 0x0076a402 in __kernel_vsyscall ()
+ Trace 112913
Thread 3 (Thread -1305289840 (LWP 3302))
*** Bug 410801 has been marked as a duplicate of this bug. ***
Is the stack size. 64K in g_thread_create_full works for me, the used stack doesn't only depends from gthumb, but also of how much the libraries need. So maybe putting about 512K is better.
Great catch, Manuel, thanks! How did you identify it as a stack issue? - Mike
With a little of luck. As the backtrace is corrupt, it could mean that the cpu executed random instructions. (so something writed to a place that it shouldn't) In the end of backtrace (runned in gdb) it shows a valid frame the function pthread_mutex_destroy, so i put a breakpoint in that function, and restarted, everytime it was hitted i saw the backtrace, in a attempt to catck which gthumb code was calling it. With this i saw that image-loader was involded, so i open the file, to see what is before/after that function. By change i noted the comment, i think "let's try".
+ Trace 113220
Is that what you mean by a corrupt stacktrace? (I reduced the stack size, so I need to learn to identify stack issues more quickly!) - Mike
Program received signal SIGSEGV, Segmentation fault.
+ Trace 113510
Thread NaN (LWP 4930)
eax 0xfffffffc -4 ecx 0x59595959 1499027801 edx 0x59595959 1499027801 ebx 0x85bcf0c 140234508 esp 0xb5a813d0 0xb5a813d0 ebp 0x59595959 0x59595959 esi 0x0 0 edi 0x3 3 eip 0x59595959 0x59595959 eflags 0x10206 [ PF IF RF ] cs 0x73 115 ss 0x7b 123 ds 0x7b 123 es 0x7b 123 fs 0x0 0 gs 0x33 51 (gdb) x /20x $esp 0xb5a813d0: 0x59595959 0x59595959 0x59595959 0x59595959 0xb5a813e0: 0x59595959 0x59595959 0x59595959 0x59595959 0xb5a813f0: 0x59595959 0x59595959 0x59595959 0x59595959 0xb5a81400: 0x085c78c0 0x08517c98 0xb5a81448 0xb7a923e0 0xb5a81410: 0x08266c38 0xb7a9601e 0x00000000 0x00000000 (gdb) x 0x59595959 0x59595959: Cannot access memory at address 0x59595959 This is what i get. You can see the 0x59595959 is over where, but this is not a valid address for memory. The segmentation fault was caused when the cpu try to fetch the next instruction in this address (eip = program counter register). So how did the eip get the 0x59595959, provably something (maybe another thread) writed to stack at a address, that had the return address from a function, when the function returned the eip was set with trash. One reason for this to happen, is that the stack grow more than the size allocated for her. In a backtrace the address that it shows, is the return address of a function, it points to the start of the next instruction after a function call. So in a valid backtrace, this address must be accessible, and must point to a valid intruction.