Re: NSZone pointers

[David Chisnall]

Interesting...

This lock is only used if zone_list is not 0 (i.e. if there are zones other 
than the default malloc() zone registered).  

Can you see what is creating the other zone[s]?  I don't get this crash, 
because nothing I run is creating any other zones.  According to Riccardo, 
things in the test suite are crashing for him, which means that there is 
something in -base creating zones - I'm surprised it would only do that on some 
platforms.

David

On 25 Jul 2011, at 13:39, Fred Kiefer wrote:

> With current base SVN code I found a rather annoying problem with the new 
> NSZone implementation. For me all programs now segmentation fault at exit. 
> The stack is corrupted, but putting a break point into NSExecption 
> raise:format: gives something useful:
> 
> 
> Breakpoint 1, +[NSException raise:format:] (self=0x7ffff7557a00, 
> _cmd=0x7ffff7572a80,
>    name=0x7ffff7572ce0, format=0x7ffff7572c60) at NSException.m:831
> 831     {
> (gdb) bt
> #0  +[NSException raise:format:] (self=0x7ffff7557a00, _cmd=0x7ffff7572a80,
>    name=0x7ffff7572ce0, format=0x7ffff7572c60) at NSException.m:831
> #1  0x00007ffff718d145 in NSZoneFromPointer (ptr=0x68a250) at NSZone.m:1947
> #2  0x00007ffff70f5eac in NSDeallocateObject (self=0x68a258, _cmd=<value 
> optimized out>)
>    at NSObject.m:861
> #3  -[NSObject dealloc] (self=0x68a258, _cmd=<value optimized out>) at 
> NSObject.m:1417
> #4  0x00007ffff70dfe65 in -[NSRecursiveLock dealloc] (self=0x68a258,
>    _cmd=<value optimized out>) at NSLock.m:238
> #5  0x00007ffff62c55a1 in __run_exit_handlers (status=0, listp=0x7ffff65f74a8,
>    run_list_atexit=true) at exit.c:78
> #6  0x00007ffff62c55f5 in exit (status=-145393152) at exit.c:100
> #7  0x00007ffff77eff64 in -[NSApplication replyToApplicationShouldTerminate:] 
> (
>    self=<value optimized out>, _cmd=<value optimized out>,
>    shouldTerminate=<value optimized out>) at NSApplication.m:3513
> #8  0x00007ffff77e8149 in -[NSApplication sendAction:to:from:] (self=<value 
> optimized out>,
>    _cmd=<value optimized out>, aSelector=0x7ffff7db91a0, aTarget=<value 
> optimized out>,
>    sender=0xb1ec58) at NSApplication.m:2232
> #9  0x00007ffff78a3ce4 in -[NSMenu performActionForItemAtIndex:] 
> (self=0xa3ffb8,
>    _cmd=<value optimized out>, index=<value optimized out>) at NSMenu.m:1323
> #10 0x00007ffff78ac864 in -[NSMenuView _trackWithEvent:] (self=<value 
> optimized out>,
> 
> I think that the implementation of your exit handlers that try to clean up 
> memory to allow tools like valgrind to better report lost memory chunks and 
> the new NSZone implementation clash here. Most likely the NSRecursiveLock we 
> see here being deallocated is gnustep_global_lock and the NSZoneFromPointer 
> code uses this lock to protect its operation.
> 
> The best way out of this that I see is to change the code in handleExit() to 
> move the global lock into a local variable first, nil the global variable and 
> only then release the object.
> 
> Any objection to this?
> 
> _______________________________________________
> Gnustep-dev mailing list
> address@hidden
> https://lists.gnu.org/mailman/listinfo/gnustep-dev


-- Sent from my brain