GNOME Bugzilla – Bug 673264
Gimp Segfaults on Select -> Rounded Rectangle
Last modified: 2012-05-27 20:41:17 UTC
I built Gimp-gitmaster as of March 25 on Snow-Leopard as a x86_64 bit application. For the most part, Gimp works quite well, especially for photo related activities. However, I get segfault when I use some built-in plugins such as Filters -> decor -> Add belevel. Here I am reporting the Rounded Rectangle select for starters. 1. Open Image. 2. Select Rounded Rectangle. 3. Crash. gdb reports the following: Program received signal EXC_BAD_ACCESS, Could not access memory. Reason: KERN_INVALID_ADDRESS at address: 0x00000000468e0000 0x00007fff85272f10 in objc_msgSend () Backtrace reports: (gdb) backtrace
+ Trace 229986
When I quit gdb, the get the following on the terminal: LibGimpBase-WARNING **: script-fu: gimp_wire_read(): error Build details: gcc 4.7.0 glib 2.31.6 gtk+ 2.24.10 Python 2.7.2 Please let me know if you need more details. Thanks, Partha
"thread apply all bt" is welcome instead of only "backtrace". Plus the backtrace is not very useful anyway, plus wondering why you use glib 2.31.6 which is an old unstable version...
OK, not problems. When I reran gimp-2.7 through gdb, I got this on the terminal: 2012-04-01 13:59:41.867 gimp-2.7[2075:a0f] -[NSCFString timeIntervalSinceNow]: unrecognized selector sent to instance 0x102af69c0 2012-04-01 13:59:41.869 gimp-2.7[2075:a0f] An uncaught exception was raised 2012-04-01 13:59:41.870 gimp-2.7[2075:a0f] -[NSCFString timeIntervalSinceNow]: unrecognized selector sent to instance 0x102af69c0 2012-04-01 13:59:41.871 gimp-2.7[2075:a0f] *** Terminating app due to uncaught exception 'NSInvalidArgumentException', reason: '-[NSCFString timeIntervalSinceNow]: unrecognized selector sent to instance 0x102af69c0' *** Call stack at first throw: ( 0 CoreFoundation 0x00007fff8a77c784 __exceptionPreprocess + 180 1 libobjc.A.dylib 0x00007fff8287ff03 objc_exception_throw + 45 2 CoreFoundation 0x00007fff8a7d6110 +[NSObject(NSObject) doesNotRecognizeSelector:] + 0 3 CoreFoundation 0x00007fff8a74e8ef ___forwarding___ + 751 4 CoreFoundation 0x00007fff8a74aa38 _CF_forwarding_prep_0 + 232 5 AppKit 0x00007fff88dad568 _DPSNextEvent + 2426 6 AppKit 0x00007fff88dac801 -[NSApplication nextEventMatchingMask:untilDate:inMode:dequeue:] + 155 7 libgdk-quartz-2.0.0.dylib 0x000000010101ce0b poll_func + 123 ) terminate called after throwing an instance of 'NSException' Program received signal SIGABRT, Aborted. 0x00007fff8644e0b6 in __kill () (gdb) thread apply all bt
+ Trace 229989
Thread 16 (process 2075)
Thread 14 (process 2075)
Thread 11 (process 2075)
Thread 10 (process 2075)
Thread 9 (process 2075)
Thread 8 (process 2075)
Thread 7 (process 2075)
Thread 6 (process 2075)
Thread 5 (process 2075)
Thread 4 (process 2075)
Finally, I am using glib 2.31.6 since all version past that, starting at 2.31.8 don't compile and I filed a bug report: https://bugzilla.gnome.org/show_bug.cgi?id=672777 Thanks! Partha
Correction, I added to the bug report 672777.
I don't have a Mac or a machine running in 64-bit so I have no way to test this issue. There is nothing in the stack trace that indicates the problem has anything to do with Script-Fu.
I didn't know where else to add the bug report. Do you have a suggestion on what could be going wrong?
Duplicate of bug #674108 ?
Mitch, I ventured a guess that it's a glib problem and not a Gimp problem. But I am not familiar with the innards to be sure and so left it to the experts. Thanks, Partha
I think you found one )) poll_func() in your stack trace is in *the* evil file in gtk+ (gdk/quartz/gdkeventloop-quartz.c), so not a GLib issue.
OK. I will apply the patch you posted on the other thread. What about the report therein that talks about memory leak? Always something to worry about. I will apply anyway to test it to see if this bug goes away. Thanks Mitch.
I might be an expert in the evil file, but not so much on OSX, will ask Kris about the leaks, but I haven's seen any such warnings myself.
Mitch, I applied the patch: http://bugzilla-attachments.gnome.org/attachment.cgi?id=212050 However, the issue is that I get a lot of memory leak warnings: 2012-05-11 08:37:21.237 script-fu[75408:903] *** __NSAutoreleaseNoPool(): Object 0x101db05d0 of class NSConcreteMutableData autoreleased with no pool in place - just leaking 2012-05-11 08:37:21.249 script-fu[75408:903] *** __NSAutoreleaseNoPool(): Object 0x10189abd0 of class NSConcreteMutableData autoreleased with no pool in place - just leaking 2012-05-11 08:37:21.250 script-fu[75408:903] *** __NSAutoreleaseNoPool(): Object 0x101d36e90 of class NSConcreteMutableData autoreleased with no pool in place - just leaking ... The selection of rounded-rectangle does not exactly crash but renders Gimp inoperable. Thanks, Partha
Applying Danial Sabo's patch https://bugzilla.gnome.org/attachment.cgi?id=213845 prevents the memory leak warnings, but script-fu still crashes on rounded rectangle (and friends). It seems to go into some limbo and you never get your focus back. Only way to get out is Cntrl-C.
We obviously run into a deadlock here, evil.
It doesn't occur in the X11 version, so it seems to be specific to Quartz, indeed. In comment #12 Partha wrote 'Danial Sabo's patch ... prevents the memory leak warnings'. Looking at it I found it suppresses collecting some events. So to me it seems, it's only a workaround. IMO silencing warnings isn't a proper way to 'solve' problems. It's burying the head in the sand. There are reasons for warnings, which at least need to be examined. Lately I had memory leaks in a C++ application, too. I couldn't locate their source neither with Valgrind nor with other leak detectors. Finally I found them with the following steps on my Mac: 1. set the environment variable MallocStackLogging to any value. This will activate stacktracing. 2. start the application (GIMP) 3. to find out the process id and memory consumption of the application use the command: top -stats pid,command,vsize. -> Due to the memory leak, the vsize value was increasing constantly. 4. given a process id of 1000 find out the leaks using: leaks 1000 >MyApp-1000-leaks.txt This gave me a detailed list of the leaks, containing a memory dump and a stacktrace of every leak. You might find additional information with the heap command (in this case call: heap -showSizes 1000) Though it was a C++ application, I read this also works for C applications. Maybe these informations are useful for you, too.
Either I am not sure how to use MallocStackLogging or it does not play nice. I did the following: export MallocStackLogging=1000 started Gimp. Got this: gimp(79439) malloc: recording stacks using recorder 0x64 Segmentation fault C'est tout. Then I had to unset MallocStackLogging before I could restart Gimp.
I see nothing wrong in what you've done. What was logged in the output file (see step 4 in comment #14)? Can you post it?
How do I do step 4 given that gimp segfaults and does not start?
Hmm, a hard thing. Lacking more information, this is just a guess: GIMP gets started and has the pid 79439. To me a SEGFAULT indicates a memory issue. Does the SEGFAULT appear suddenly after you started GIMP or do you have enough time to start the leaks command? How about putting these steps into a shell script similar to this: gimp &; leaks gimp >>gimpleaks.txt. Maybe this is quick enough to catch some information from the crashing gimp. Have you otherwise tried with Valgrind? Maybe this can be insightful here, too. What exactly do you mean with 'go into some limbo'? You probably don't mean the dance... ;-)
Fixed by this workaround, pushed to master and gimp-2-8: commit 668891e7455ff9107901b004e7ce9d422041ef71 Author: Daniel Sabo <DanielSabo@gmail.com> Date: Fri May 25 03:42:36 2012 -0700 app: use an idle source to dispatch GTK menu events in ige-mac-menu in order to work around the crashes in bug #673264 and bug #674108. (cherry picked from commit c1786fe753174a92a271a1acfe729c88495012c1) app/gui/ige-mac-menu.c | 22 +++++++++++++++++++++- 1 file changed, 21 insertions(+), 1 deletion(-)