Re: [bugs #8498] [MinGW] NSUnarchiver crashes

[Gregory John Casamento]

In every case, all files .gorm and non-gorm archives are failing when
unarchiving NS*Number objects.

I believe that since the NS*Number objects are cached the release done by the
assign at the following location in NSUnarchiver is causing the crash I'm
seeing:


FROM NSUnarchiver:
                  obj = [c allocWithZone: zone];
                  /*
                   * The objMap array does not retain its contents directly,
                   * so we perform explicit retain/release as we add objects
                   * to and remove objects from the array.
                   */
                  RETAIN(obj);
                  GSIArrayAddItem(objMap, (GSIArrayItem)obj);

                  rep = [obj initWithCoder: self];
                  if (rep != obj)
                    {
---> Dying here!!     ASSIGN(obj, rep);
                      GSIArraySetItemAtIndex(objMap, (GSIArrayItem)obj, xref);
                    }


backtrace:

Program received signal SIGSEGV, Segmentation fault.
[Switching to Thread 16384 (LWP 17734)]
0x4059ecaa in objc_msg_lookup () from /usr/lib/libobjc.so.1
(gdb) up
#1  0x40446354 in -[NSUnarchiver decodeValueOfObjCType:at:] (self=0x84fb888,
_cmd=0x404f1340, type=0x404a764f "@", 
    address=0xbfffdaac) at NSUnarchiver.m:621
(gdb) 
#2  0x40353fdb in -[GSDictionary initWithCoder:] (self=0x84e0148,
_cmd=0x40514710, aCoder=0x84fb888)
    at GSDictionary.m:157
(gdb) down
#1  0x40446354 in -[NSUnarchiver decodeValueOfObjCType:at:] (self=0x84fb888,
_cmd=0x404f1340, type=0x404a764f "@", 
    address=0xbfffdaac) at NSUnarchiver.m:621
(gdb) po rep
17734
(gdb) 
(gdb) po [rep class]
NSIntNumber
(gdb) 

I'm going to go ahead and revert this code.  Wim, please recommit this, when
the issue cited above is corrected.

Thanks, GJC

--- Richard Frith-Macdonald <richard@brainstorm.co.uk> wrote:
> 
> On 10 Apr 2004, at 03:09, Gregory John Casamento wrote:
> 
> > Wim,
> >
> > In the directory:
> >
> > gnustep/dev-apps/test/gormtest
> >
> > There is an application which extensively tests .gorm functionality.
> >
> > GJC
> > --- Wim Oudshoorn <woudshoo@xs4all.nl> wrote:
> >> Gregory John Casamento <greg_casamento@yahoo.com> writes:
> >>
> >>> All,
> >>>
> >>> Initial tests indicate that this breaks .gorm loading for some 
> >>> reason.   I
> >> need
> >>> to do further tests.   I recommend not adding this patch until this 
> >>> problem
> >> has
> >>> been investigated and cleared.
> >>>
> >>> GJC
> >>
> >>
> >> Thanks for testing, is there a simple testcase which I can
> >> run as well?
> 
> The supplied patch didn't retain/release objects in all cases where 
> they are added to
> and removed from the map ... which could have very nasty effects when 
> the map was
> emptied at the end of unarchiving.
> 
> I updated CVS with a version of the code which (afaik) does the 
> rating/release correctly.
> I tested that against some of my own software, and against Wim's test 
> program.
> 
> I couldn't properly test against gnustep/dev-apps/test/gormtest since 
> the AppDelegate.m
> file is missing from CVS and the app wouldn't build ... however I did 
> hack in enough code
> to get it to build and run without crashing., so I'm pretty confident 
> of the fix.
> If the fix causes problems, please revert it.
> 
> 
> 
> _______________________________________________
> Bug-gnustep mailing list
> Bug-gnustep@gnu.org
> http://mail.gnu.org/mailman/listinfo/bug-gnustep


=====
Gregory John Casamento -- CEO/President Open Logic Corp.

__________________________________
Do you Yahoo!?
Yahoo! Tax Center - File online by April 15th
http://taxes.yahoo.com/filing.html