[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

[bugs #8498] [MinGW] NSUnarchiver crashes

From: Richard Frith-Macdonald
Subject: [bugs #8498] [MinGW] NSUnarchiver crashes
Date: Sun, 11 Apr 2004 02:43:19 -0400
User-agent: Mozilla/5.0 (Macintosh; U; PPC Mac OS X; en) AppleWebKit/124 (KHTML, like Gecko) Safari/125.1

This mail is an automated notification from the bugs tracker
 of the project: GNUstep.

[bugs #8498] Latest Modifications:

Changes by: 
                Richard Frith-Macdonald <address@hidden>
                Sun 04/11/04 at 06:43 (GMT)

            What     | Removed                   | Added
          Resolution | None                      | Fixed

------------------ Additional Follow-up Comments ----------------------------
I fixed the bug in NSNumber and added a simple mechanism for retaining decoded 
objects ... store them in an NSMutableArray until the NSUnarchiver is 

[bugs #8498] Full Item Snapshot:

URL: <http://savannah.gnu.org/bugs/?func=detailitem&item_id=8498>
Project: GNUstep
Submitted by: Willem Rein Oudshoorn
On: Thu 04/08/04 at 09:45

Category:  Base/Foundation
Severity:  3 - Ordinary
Item Group:  Bug
Resolution:  Fixed
Assigned to:  wim
Status:  Analyzed

Summary:  [MinGW] NSUnarchiver crashes

Original Submission:  It seems that if you call release on an decoded object
that is shared with other objects lead to a crash.

In particular:

Obj1 ---> string
Obj2 ----/

and if in initWithCoder of Obj1 (and Obj2) we have:

[coder decodeValuesOfObjCType: "@", &string];
[string release];

the decoding crashes.  
The funny thing is that this seems to be a windows
specific problem.  It works fine on Linux.

The attached program will demonstrate the problem:

./TestCoder Encode test.enc

this will create test.enc  

./TestCoder Decode test.enc

which decodes the created test.enc.  This crashes
on MinGW but not on Linux and the generated
files test.enc are identical, so it is probably
in de unarchiving code.

Follow-up Comments

Date: Sun 04/11/04 at 06:43         By: CaS
I fixed the bug in NSNumber and added a simple mechanism for retaining decoded 
objects ... store them in an NSMutableArray until the NSUnarchiver is 

Date: Sun 04/11/04 at 03:39         By: gcasa
I have attached a modified version of the original example which causes a 
segfaul in NSUnarchiver.m when unarchiving an NSNumber object.

I believe that this is because the NSNumber object is released and, since 
NSNumber objects are cached, this causes an issue when the object is 
subsequently reused.

I am reverting the previous fix until this problem is corrected. GJC

Date: Fri 04/09/04 at 10:29         By: wim
The attached patch should fix this.  
It will retain the objects in the objMap and release them
when clearing the map.   But note that we really need 
to be carefull when retaining the objects, otherwise code like

- initWithCoder:..
   [self dealloc];
   return something_else;

will crash the unarchiver.  
This rules out the replacement of objMap with an 

If nobody objects I will commit this shortly.

Wim Oudshoorn.

Date: Thu 04/08/04 at 11:58         By: wim
Actually, it is a generic bug, Linux is just lucky!
The bug is as follows:
NSUnarchiver has an ivar, "objMap" which is a map
from "ref" to "Objects".  However the the "Objects"
are NOT retained.  This means that if they are deallocated
the reference in this map becomes invalid.   Solution is
to retain the objects in this map.

File Attachments

Date: Sun 04/11/04 at 03:39  Name: testCoderWithNumber.tar.bz2  Size: 1KB   By: 
Illustrates the problem with encoding numbers.

Date: Fri 04/09/04 at 10:29  Name: NSUnarchiver.patch  Size: 1KB   By: wim
Patch to retain temporary the objects so initwithcoder can release them

Date: Thu 04/08/04 at 09:45  Name: testCoder.tar.bz2  Size: 1KB   By: wim
Demonstrating crash.

For detailed info, follow this link:

  Message sent via/by Savannah

reply via email to

[Prev in Thread] Current Thread [Next in Thread]