[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: NSZone pointers
From: |
Riccardo Mottola |
Subject: |
Re: NSZone pointers |
Date: |
Mon, 25 Jul 2011 15:07:00 +0200 |
User-agent: |
Mozilla/5.0 (Windows NT 5.1; rv:5.0) Gecko/20110706 Firefox/5.0 SeaMonkey/2.2 |
Hi,
I get a segfault on exit too, both on Windows and on Linux.
On linux x86 it looks lie this for me. Possibly my code is less
optimized than yours and has more information.
Riccardo
[Switching to Thread 0xb66df6c0 (LWP 6404)]
GSToUnicode (dst=0xbf010cac, size=0xbf010ca8,
src=0xb72647fc "failed to lock mutex", slen=20,
enc=NSISOLatin1StringEncoding, zone=0x0, options=0) at Unicode.m:945
945 {
(gdb) bt
#0 GSToUnicode (dst=0xbf010cac, size=0xbf010ca8,
src=0xb72647fc "failed to lock mutex", slen=20,
enc=NSISOLatin1StringEncoding, zone=0x0, options=0) at Unicode.m:945
#1 0xb6fc9c68 in -[GSCString getCharacters:] (self=0xb72f96e8,
_cmd=0xb72cc020, buffer=0xbf010cf0) at GSString.m:1631
#2 0xb6fc41bf in -[GSPlaceholderString initWithFormat:locale:arguments:] (
self=0x92c17d8, _cmd=0xb731a3e0, format=0xb72f96e8, locale=0x0,
argList=0xbf011e40 "") at GSString.m:753
#3 0xb70f489e in -[NSString initWithFormat:arguments:] (self=0x92c17d8,
_cmd=0xb734e5e8, format=0xb72f96e8, argList=0xbf011e40 "")
at NSString.m:1137
#4 0xb7190f26 in +[NSString(GNUstepBase) stringWithFormat:arguments:] (
self=0xb731a220, _cmd=0xb72e8ed0, format=0xb72f96e8,
argList=0xbf011e40 "")
at NSString+GNUstepBase.m:46
#5 0xb7051af9 in +[NSException raise:format:arguments:] (self=0xb72e8ce0,
_cmd=0xb72e8ec8, name=0xb72f9718, format=0xb72f96e8,
argList=0xbf011e40 "")
at NSException.m:847
#6 0xb7052a73 in +[NSException raise:format:] (self=0xb72e8ce0,
_cmd=0xb72f9620, name=0xb72f9718, format=0xb72f96e8) at
NSException.m:835
#7 0xb708b291 in -[NSRecursiveLock lock] (self=0x92f33b8, _cmd=0xb73327e8)
at NSLock.m:254
#8 0xb71409aa in NSZoneFromPointer (ptr=0x92c17d8) at NSZone.m:1947
#9 0xb70a060d in -[NSObject zone] (self=0x92c17d8, _cmd=0xb72cbff0)
Riccardo
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