bugGNUstep - Bugs: bug #24054, Segmentation fault in GSTest

Group
 
 

bug #24054: Segmentation fault in GSTest

Submitter:  Fred Kiefer <FredKiefer>
Submitted:  Tue 12 Aug 2008 08:40:59 PM UTC
   
 
Category:  Base/Foundation Severity:  3 - Normal
Item Group:  Bug Status:  Fixed
Privacy:  Public Assigned to:  FredKiefer
Open/Closed:  Closed
* Mandatory Fields

Add a New Comment Rich Markup
   

Jump to the original submission

Mon 25 Aug 2008 03:41:36 PM UTC, comment #10: 

Looks like this was the cause of the problem. The code was cleaning up the autorelease pool cache of the current thread and not of the thread that was being released.

The only remaining problem with the NSAnimation test is that it is leaking GSArray objects.

Fred Kiefer <FredKiefer>
Group Member
Mon 25 Aug 2008 10:37:05 AM UTC, comment #9: 

I changed my printf statement and moved it to different places. This is what I get now:

end thread pool cache 0x823ad04 current thread 0x823ace0 ended thread 0xb40004c0 count 1
push pool 0x823b330 thread 0x823ace0 count 2
pop pool 0x823b330 thread 0x823ace0 count 2
push pool 0x8222ee8 thread 0x823ace0 count 2
pop pool 0x8222ee8 thread 0x823ace0 count 2
push pool 0x8342e90 thread 0x823ace0 count 2
pop pool 0x8342e90 thread 0x823ace0 count 2
free pool cache 0x823ad04 thread 0x823ace0 count 1
pop pool 0x82425b8 thread 0x823ace0 count 1
finished free pool cache 0x823ad04 thread 0x823ace0 count 0
empty pool 0x823b330 thread 0x823ace0

Program received signal SIGSEGV, Segmentation fault.
[Switching to Thread 0xb5920b90 (LWP 9299)]
0xb78b9734 in objc_msg_lookup () from /usr/lib/libobjc.so.2

Some thread finishes and from the endThread: method we try to clean up the corresponding pool cache. But it looks like we clean up the pool cache of the current thread and of course things go horribly wrong after that. At least this is how I interpret the printed results at the moment. I will try to change the code and see if it improves things.

Fred Kiefer <FredKiefer>
Group Member
Sat 23 Aug 2008 09:59:23 PM UTC, comment #8: 

My comment about two threads requesting the same pool was of course nonsense. The pool cache is thread specific.

I added the following line to dealloc on NSAutoreleasePool:

  printf("release an autorelease pool %p thread %p count %d \n", self, GSCurrentThread(), tv->pool_cache_count);

This gives plenty of output. The last few lines before the crash are:

release an autorelease pool 0x827b2d8 thread 0x823f038 count 0
release an autorelease pool 0x827b2d8 thread 0x823f038 count 0
release an autorelease pool 0x822ac30 thread 0x823f038 count 1
release an autorelease pool 0x8192748 thread 0x823f038 count 2
release an autorelease pool 0x822ac30 thread 0x823f038 count 1
release an autorelease pool 0x827b2d8 thread 0x823f038 count 0
release an autorelease pool 0x827b2d8 thread 0x823f038 count 0
release an autorelease pool 0x822ac30 thread 0x823f038 count 1
release an autorelease pool 0x8192748 thread 0x823f038 count 2
[New Thread 0xb477ab90 (LWP 18313)]
release an autorelease pool 0x82c78d0 thread 0xb3e004c0 count 0
release an autorelease pool 0x8174cf0 thread 0xb3e004c0 count 1
[Thread 0xb477ab90 (LWP 18313) exited]
release an autorelease pool 0x822ac30 thread 0x823f038 count 1
release an autorelease pool 0x8192748 thread 0x823f038 count 1
release an autorelease pool 0x822b230 thread 0x823f038 count 1

Program received signal SIGSEGV, Segmentation fault.
[Switching to Thread 0xb577cb90 (LWP 18309)]
0xb7715734 in objc_msg_lookup () from /usr/lib/libobjc.so.2


As you can see (even more when looking at the full listing) the autorelease pools get normally used in a fixed order per thread. For thread 0x823f038 the pool 0x827b2d8 is the last in the cache. When it gets freed there is no other in the cache. The next is 0x822ac30, when it gets freed  0x823f038 is already in the cache. Next is 0x8192748, when it is dealloced the other two are already cached. In the last three lines something different happens. When 0x8192748 gets deallocated there is only one other pool in the cache. This looks like the normal order is broken and shortly after that the seg fault happens.

No prove that this two things are related, but I will look in that further.

Fred Kiefer <FredKiefer>
Group Member
Fri 22 Aug 2008 07:44:27 PM UTC, comment #7: 

Thank you for this additional information. Looks like I will have to do the dirty debugging myself. :-)

From what you wrote I think I will start with some debug statements in the NSAutoreleasePool release or dealloc method.

Now that I looked at the code of NSAutoreleasePool, I expect that the cache pool there is causing the problem. Most likely we hand out the same auto release pool twice to different threads and then it crashes when the second tries to deallocate its reference.

Fred Kiefer <FredKiefer>
Group Member
Fri 22 Aug 2008 06:56:21 PM UTC, comment #6: 

I just reproduced it with my newly built cairo backend in the 64bit world.
Unfortunately I'm away for a week starting early tomorrow (still have to finish packing tonight), so I can't really investigate.

I ran under gdb and looked at the contents of the local variable 'arp' (see NSRunLoop.m line 953) as suggested by the stacktrace.  That's an autorelease pool and it had been deallocated ... which was what caused the crash.

I would guess that this might be a retain/release issue elsewhere in the system, or perhaps something to do with the thread support changes in the last release ... as the problem seems to be trying to use a deallocated autorelease pool, and I don't see how that can be happening unless an autorelease pool is somehow being used by more than one thread or perhaps a retain/release problem elsewhere is releasing the pool when thinking it's releasing another object.

Richard Frith-Macdonald <CaS>
Group Member
Fri 22 Aug 2008 06:34:02 PM UTC, comment #5: 

I recompiled GNUstep from SVN, but the problem persists.
Could you please try it yourself in a32 bit environment?
Or do you have any idea, how I could get more meaningful debugging information?

Fred Kiefer <FredKiefer>
Group Member
Thu 21 Aug 2008 08:53:16 AM UTC, comment #4: 

OK ... I found and fixed the problem which was causing the warning message ... but that may have nothing to do with the original segmentation fault issue (I still haven't reproduced that on my system).

Richard Frith-Macdonald <CaS>
Group Member
Thu 21 Aug 2008 06:29:33 AM UTC, comment #3: 

Yes, I'm running a 64bit debian system, so it's quite possible there is something in the mart backend which s not 64bit clean.

Richard Frith-Macdonald <CaS>
Group Member
Wed 20 Aug 2008 09:38:54 PM UTC, comment #2: 

Strange this may be due to system differences. I am working on a 32 bit system and you are most likely using your 64 bit one.

Greg gets similar errors from art on his 64 bit system but I havent't been able to reproduce this.

I will recompile base,gui back and GSTest from SVN, but don't expect much differences there.

Fred Kiefer <FredKiefer>
Group Member
Wed 20 Aug 2008 07:36:04 PM UTC, comment #1: 

So far I can't reproduce this with current svn on my system.
The animation test seems to run fine, but I do get a stream of warning messages logged saying 'invalid type 1065353216'.
This seems to be coming from the art backend.

Richard Frith-Macdonald <CaS>
Group Member
Tue 12 Aug 2008 08:40:59 PM UTC, original submission:  

Starting the NSAnimationTest in GSTest results in a segmetnation fault with the following back trace:

Program received signal SIGSEGV, Segmentation fault.
[Switching to Thread 0xb58ddb90 (LWP 7825)]
0xb7876734 in objc_msg_lookup () from /usr/lib/libobjc.so.2
(gdb) bt
#0  0xb7876734 in objc_msg_lookup () from /usr/lib/libobjc.so.2
#1  0xb7a6c662 in -[NSRunLoop limitDateForMode:] (self=0x823d1e8,
    _cmd=0xb7c499a0, mode=0xb7f73760) at NSRunLoop.m:953
#2  0xb7a6d751 in -[NSRunLoop runMode:beforeDate:] (self=0x823d1e8,
    _cmd=0xb7f745b8, mode=0xb7f73760, date=0x820f5c0) at NSRunLoop.m:1222
#3  0xb7d34e5e in -[NSAnimation(Private) _gs:startAnimationInOwnLoop] (
    self=0x8291ed8, _cmd=0xb7f74518) at NSAnimation.m:1138
#4  0xb7d34c4b in -[NSAnimation(Private) _gs:startThreadedAnimation] (
    self=0x8291ed8, _cmd=0xb7f74538) at NSAnimation.m:1125
#5  0xb7a35f68 in -[NSObject performSelector:withObject:] (
    self=0x8291ed8, _cmd=0xb7c552f0, aSelector=0xb7f74538, anObject=0x0)
    at NSObject.m:1980
#6  0xb7a9c7c9 in -[NSThread main] (self=0x8233af0, _cmd=0xb7c55300)
    at NSThread.m:765
#7  0xb78777a0 in ?? () from /usr/lib/libobjc.so.2
#8  0xb7887175 in start_thread () from /lib/libpthread.so.0
#9  0xb77cadce in clone () from /lib/libc.so.6
(gdb)              

As usual this is GNUstep from SVN and the art backend.
I am not sure whether this really is a base problem, we just have to start somewhere and this looks like the most probable place to look.

Fred Kiefer <FredKiefer>
Group Member

 

(Note: upload size limit is set to 16384 kB, after insertion of the required escape characters.)

Attach Files:
   
   
Comment:
   

No files currently attached

 

Depends on the following items: None found

Items that depend on this one: None found

 

Carbon-Copy List
  • -email is unavailable- added by CaS (Posted a comment)
  • -email is unavailable- added by FredKiefer (Submitted the item)
  •  

    There are 0 votes so far. Votes easily highlight which items people would like to see resolved in priority, independently of the priority of the item set by tracker managers.

    Only logged-in users can vote.

     

    Follow 4 latest changes.

    Date Changed by Updated Field Previous Value => Replaced by
    2008-09-05 FredKiefer Open/ClosedIn Test Closed
    2008-08-25 FredKiefer StatusNone Fixed
        Assigned toNone FredKiefer
        Open/ClosedOpen In Test

    Back to the top

    Powered by Savane 3.13-02a9.
    Corresponding source code