[bug #24054] Segmentation fault in GSTest

[Fred Kiefer]

Follow-up Comment #8, bug #24054 (project gnustep):

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.

    _______________________________________________________

Reply to this item at:

  <http://savannah.gnu.org/bugs/?24054>

_______________________________________________
  Nachricht geschickt von/durch Savannah
  http://savannah.gnu.org/