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

 
 

You are not allowed to post comments on this tracker with your current authentication level.

bug #24054: Segmentation fault in GSTest

Submitted by:  Fred Kiefer <FredKiefer>
Submitted on:  Tue 12 Aug 2008 08:40:59 PM UTC  
 
Category: Base/FoundationSeverity: 3 - Normal
Item Group: BugStatus: Fixed
Privacy: PublicAssigned to: Fred Kiefer <FredKiefer>
Open/Closed: Closed

(Jump to the original submission 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>
Project MemberIn charge of this item.
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>
Project MemberIn charge of this item.
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>
Project MemberIn charge of this item.
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>
Project MemberIn charge of this item.
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>
Project 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>
Project MemberIn charge of this item.
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>
Project 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>
Project 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>
Project MemberIn charge of this item.
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>
Project 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>
Project MemberIn charge of this item.

 

No files currently attached

 

Depends on the following items: None found

Items that depend on this one: None found

 

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

    Do you think this task is very important?
    If so, you can click here to add your encouragement to it.
    This task has 0 encouragements so far.

    Only logged-in users can vote.

     

    Please enter the title of George Orwell's famous dystopian book (it's a date):

     

     

    Follow 4 latest changes.

    Date Changed By Updated Field Previous Value => Replaced By
    Fri 05 Sep 2008 09:04:13 PM UTCFredKieferOpen/ClosedIn Test=>Closed
    Mon 25 Aug 2008 03:41:36 PM UTCFredKieferStatusNone=>Fixed
      Assigned toNone=>FredKiefer
      Open/ClosedOpen=>In Test

    Back to the top


    Powered by Savane 3.1-cleanup1