[Top][All Lists]

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

[bugs #8018] NSMutableDictionary writeToFile:atomically:

From: Fred Kiefer
Subject: [bugs #8018] NSMutableDictionary writeToFile:atomically:
Date: Sun, 09 May 2004 16:12:35 -0400
User-agent: Mozilla/5.0 (compatible; Konqueror/3.2; Linux) (KHTML, like Gecko)

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

[bugs #8018] Latest Modifications:

Changes by: 
                Fred Kiefer <address@hidden>
                Sun 05/09/04 at 20:11 (GMT)

            What     | Removed                   | Added
              Status | Open                      | Closed

------------------ Additional Follow-up Comments ----------------------------
Adopted the status field to the resolution field.

[bugs #8018] Full Item Snapshot:

URL: <http://savannah.gnu.org/bugs/?func=detailitem&item_id=8018>
Project: GNUstep
Submitted by: 0
On: Fri 03/05/04 at 12:06

Category:  Base/Foundation
Severity:  5 - Average
Item Group:  Bug
Resolution:  Fixed
Assigned to:  CaS
Status:  Closed

Summary:  NSMutableDictionary writeToFile:atomically:

Original Submission:  The problem is located when a Distant dictionary is an 
Object for a Key in a local dictionary and the local one has to be written to a 
file, no matter if atomically or not.
This causes a SIGSEGV on the process which registered the object trying to 
It has been tested with gnustep-base 1.7.2, 1.9.0, 1.9.1, it is the same.
Tests have been performed with gcc 3.3.2 on i686 architecture.

In attacched files:
t3.m -> exports a dummyObj
t3c.m -> client, creates a dictionary and passes it as a parameter to 
t3-exported remote dummyObj.
dummy.h -> interface for 'dummyObj'
dummy.m -> implementation for 'dummyObj': creates a 1 unit dictionary 
containing the passed dictionary and writes it to file.

Possible (failed) workarounds are commented in dummy.m
On NeXT Runtime the same code runs perfectly.

Follow-up Comments

Date: Sun 05/09/04 at 20:11         By: FredKiefer
Adopted the status field to the resolution field.

Date: Tue 03/16/04 at 14:55         By: None
Thank you. Do you think the latter one to be a libffi problem and that I should 
report them it ?

Date: Mon 03/15/04 at 18:05         By: CaS
Fixed in CVS.
One problem was the use of -getObjects: to retrieve items to write to file ... 
which can't work with distributed objects.
Another problem appeared to happed with libffi and caching a method 
implementation ... I don't understand that one and simply altered the code
a little to avoid the cachign as a workaround ... not a proper solution as, as
far as I can see, the cacheing ought to work.

Date: Fri 03/05/04 at 16:25         By: None
More debugging revealed the problem is more generic: given a remote mutable 
dictionary, a [dict allKeys] call will fail by problems of the DO code.

Date: Fri 03/05/04 at 12:10         By: None
my email is address@hidden

File Attachments

Date: Fri 03/05/04 at 12:10  Name: dummy.h  Size: 114KB   By: None
dummy header

Date: Fri 03/05/04 at 12:09  Name: dummy.m  Size: 735KB   By: None

Date: Fri 03/05/04 at 12:08  Name: t3c.m  Size: 481KB   By: None

Date: Fri 03/05/04 at 12:06  Name: t3.m  Size: 371KB   By: None

For detailed info, follow this link:

  Message sent via/by Savannah

reply via email to

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