Re: NSSerializer bug

[Richard Frith-Macdonald]

On 22 May 2006, at 01:24, Enrico Sersale wrote:

> With the current SVN I'm getting this with all the applications and  
> many tools:
>
> Starting program: /usr/GNUstep/System/Tools/make_services
> Reading symbols for shared libraries .+.++....... done
>
> Program received signal EXC_BAD_ACCESS, Could not access memory.
> Reason: KERN_PROTECTION_FAILURE at address: 0x00000020
> 0x0005e96f in objc_msg_lookup () at NSCalendarDate.m:1956
> 1956                          info->t[info->offset+0] = (v%10) + '0';
> (gdb) bt
> #0  0x0005e96f in objc_msg_lookup () at NSCalendarDate.m:1956
> #1  0xbffff0ac in ?? ()
> #2  0x0100f400 in -[GSArray dealloc] (self=0x1e92bf8,  
> _cmd=0x12be2e8) at GSArray.m:136
> #3  0x011229b2 in deserializeFromInfo (info=0xbffff0b0) at  
> NSSerializer.m:530
> #4  0x01122f92 in deserializeFromInfo (info=0xbffff0b0) at  
> NSSerializer.m:662
> #5  0x01122f92 in deserializeFromInfo (info=0xbffff0b0) at  
> NSSerializer.m:662
> #6  0x01122f92 in deserializeFromInfo (info=0xbffff0b0) at  
> NSSerializer.m:662
> #7  0x01122f92 in deserializeFromInfo (info=0xbffff0b0) at  
> NSSerializer.m:662
> #8  0x01124017 in +[NSDeserializer  
> deserializePropertyListFromData:mutableContainers:]  
> (self=0x12d9200, _cmd=0x9280, data=0x1e72cc8, flag=0 '\000') at  
> NSSerializer.m:886
> #9  0x00002f19 in mframe_next_arg (typePtr=0x9280 "\022",  
> info=0x1e72cc8) at mframe.m:391
> #10 0x012d9200 in NSZeroSize ()
> #11 0x00009280 in cacheName ()
> #12 0x01e72cc8 in ?? ()
> #13 0x00000000 in _mh_dylib_header ()
> #14 0x001001d0 in setupQuotables () at NSPropertyList.m:173
>
> This is running make_services on darwin but the same thing happens  
> also on linux.
> Reverting to a version <= 22952 fixes the problem.

Thanks for that information ... I spent all morning tracking it  
down.  I couldn't reproduce it on my linux machines or solaris, but  
eventually got it on windows/mingw and was able to run under gdb  
there and eventually figure out the problem.  It turned out to be not  
so much a problem with the recent changes as a pre-existing one with  
the deserialisation code which the changes exposed.  The deserialiser  
was releasing dictionary keys after adding them to the dictionary,  
but the dictionary was taking copies of the keys so releasing the key  
could cause the original to be released ... which was obviously a  
problem if the string as used later.

current svn should fix this by autoreleasing the strings after adding  
them to the dictionary rather than releasing them immediately,