Re: I don't understand why this is leaking...
On 9 Aug 2008, at 17:39:20 -0600, Jonathan deWerd
[EMAIL PROTECTED]wrote:
On Aug 9, 2008, at 4:48 PM, Cate Tony wrote:
This code is leaking:
- (void)saveItemExtensions:(id)sender
{
NSMutableString* itemExtensionsFilePath = [NSMutableString
stringWithString:@~/Library/Preferences/MyApp/extensions.abc];
NSDictionary* extensions = [NSDictionary dictionaryWithDictionary:
[itemDataSource itemExtensions]];
[itemExtensionsFilePath setString:[itemExtensionsFilePath
stringByExpandingTildeInPath]];
[[NSArchiver archivedDataWithRootObject:extensions]
itemExtensionsFilePath atomically: YES];
}
- (void)encodeWithCoder:(NSCoder *)coder
{
[coder encodeObject: string1];
[coder encodeObject: string2];
[coder encodeObject: string3];
[coder encodeObject: string4];
[coder encodeObject: string5];
[coder encodeObject: string6];
[coder encodeObject: string7];
[coder encodeObject: string8];
}
According to MallocDebug, the leak is in the encodeWithCoder method.
Things I've tried:
1 [coder encodeObject: [string1 autorelease]]; Which, of course,
caused a crash
2 [coder encodeObject: [string1 copy]]; no diff
3 [coder encodeObject: [[string1 copy] autorelease]]; no diff
4 Drinking beer...
Can anyone explain this to me?
Tony
What is coder? It could be that coder is deferring the encoding
(saving copies of string*), and then the coder itself is never getting
released. Have Instruments make sure that the coder is actually going
away after the encoding is done. Also check to make sure the encoded
data is going away when it is no longer needed. Sometimes the leak
isn't exactly where MallocDebug says the object was allocated: -retain
increments the retain count as surly as -alloc. What do the individual
string* histories look like in Instruments? Speaking of Instruments,
could you give us (not the mailing list, I don't think it allows
attachments, but you could email me separately) an instruments session
to look at? It would greatly facilitate proceedings :)
Also, why are you using non-keyed encoding? -encodeObject:forKey: is
the preferred way of doing things nowadays...
Well, it may be the preferred way, but it is not always the best, nor
even the correct way.
Two reasons:
1. the resulting files are much bigger
2. NSKeyedArchiver can only store certain strings (tested in
10.4.11), which makes it absolutely unusable for the storage of
strings if the possible values are not known in advance.
Kind regards,
Gerriet.
___
Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)
Please do not post admin requests or moderator comments to the list.
Contact the moderators at cocoa-dev-admins(at)lists.apple.com
Help/Unsubscribe/Update your Subscription:
http://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com
This email sent to [EMAIL PROTECTED]
Re: I don't understand why this is leaking...
Am Di,12.08.2008 um 10:42 schrieb Gerriet M. Denkmann:
On 9 Aug 2008, at 17:39:20 -0600, Jonathan deWerd [EMAIL PROTECTED]
wrote:
On Aug 9, 2008, at 4:48 PM, Cate Tony wrote:
This code is leaking:
- (void)saveItemExtensions:(id)sender
{
NSMutableString* itemExtensionsFilePath = [NSMutableString
stringWithString:@~/Library/Preferences/MyApp/extensions.abc];
NSDictionary* extensions = [NSDictionary dictionaryWithDictionary:
[itemDataSource itemExtensions]];
[itemExtensionsFilePath setString:[itemExtensionsFilePath
stringByExpandingTildeInPath]];
[[NSArchiver archivedDataWithRootObject:extensions]
itemExtensionsFilePath atomically: YES];
}
- (void)encodeWithCoder:(NSCoder *)coder
{
[coder encodeObject: string1];
[coder encodeObject: string2];
[coder encodeObject: string3];
[coder encodeObject: string4];
[coder encodeObject: string5];
[coder encodeObject: string6];
[coder encodeObject: string7];
[coder encodeObject: string8];
}
According to MallocDebug, the leak is in the encodeWithCoder method.
Things I've tried:
1 [coder encodeObject: [string1 autorelease]]; Which, of course,
caused a crash
2 [coder encodeObject: [string1 copy]]; no diff
3 [coder encodeObject: [[string1 copy] autorelease]]; no diff
4 Drinking beer...
Can anyone explain this to me?
Tony
What is coder? It could be that coder is deferring the encoding
(saving copies of string*), and then the coder itself is never
getting
released. Have Instruments make sure that the coder is actually going
away after the encoding is done. Also check to make sure the encoded
data is going away when it is no longer needed. Sometimes the leak
isn't exactly where MallocDebug says the object was allocated: -
retain
increments the retain count as surly as -alloc. What do the
individual
string* histories look like in Instruments? Speaking of Instruments,
could you give us (not the mailing list, I don't think it allows
attachments, but you could email me separately) an instruments
session
to look at? It would greatly facilitate proceedings :)
Also, why are you using non-keyed encoding? -encodeObject:forKey: is
the preferred way of doing things nowadays...
Well, it may be the preferred way, but it is not always the best,
nor even the correct way.
Two reasons:
1. the resulting files are much bigger
2. NSKeyedArchiver can only store certain strings (tested in
10.4.11), which makes it absolutely unusable for the storage of
strings if the possible values are not known in advance.
Do you have an example for that?
Amin
Kind regards,
Gerriet.
___
Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)
Please do not post admin requests or moderator comments to the list.
Contact the moderators at cocoa-dev-admins(at)lists.apple.com
Help/Unsubscribe/Update your Subscription:
http://lists.apple.com/mailman/options/cocoa-dev/negm-awad%40cocoading.de
This email sent to [EMAIL PROTECTED]
Amin Negm-Awad
[EMAIL PROTECTED]
___
Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)
Please do not post admin requests or moderator comments to the list.
Contact the moderators at cocoa-dev-admins(at)lists.apple.com
Help/Unsubscribe/Update your Subscription:
http://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com
This email sent to [EMAIL PROTECTED]
Re: I don't understand why this is leaking...
On 12 Aug 2008, at 6:42 pm, Gerriet M. Denkmann wrote: 2. NSKeyedArchiver can only store certain strings (tested in 10.4.11), which makes it absolutely unusable for the storage of strings if the possible values are not known in advance. Eh? That's just not true. Can you provide an example of a string that it can't store? Anything that's NSCoding compliant can be stored, and NSString is. I'm sure if it weren't someone would have raised merry hell about it before now. Something's fishy... As for file sizes, is that really all that relevant these days? Archives don't store huge amount of overhead compared to the data itself - saving a few bytes here and there is not worth the pain of losing the convenience of keyed archiving. Non-keyed archiving produces inherently very fragile file formats, which are a lot of work to maintain. Keyed archiving on the other hand, makes handling format changes trivial. cheers, Graham ___ Cocoa-dev mailing list (Cocoa-dev@lists.apple.com) Please do not post admin requests or moderator comments to the list. Contact the moderators at cocoa-dev-admins(at)lists.apple.com Help/Unsubscribe/Update your Subscription: http://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to [EMAIL PROTECTED]
Re: I don't understand why this is leaking...
On 12 Aug 2008, at 15:50, Negm-Awad Amin wrote:
Am Di,12.08.2008 um 10:42 schrieb Gerriet M. Denkmann:
On 9 Aug 2008, at 17:39:20 -0600, Jonathan deWerd
[EMAIL PROTECTED]wrote:
On Aug 9, 2008, at 4:48 PM, Cate Tony wrote:
[...]
Also, why are you using non-keyed encoding? -encodeObject:forKey: is
the preferred way of doing things nowadays...
Well, it may be the preferred way, but it is not always the best,
nor even the correct way.
Two reasons:
1. the resulting files are much bigger
2. NSKeyedArchiver can only store certain strings (tested in
10.4.11), which makes it absolutely unusable for the storage of
strings if the possible values are not known in advance.
Do you have an example for that?
Yes, I have.
1. Simple Test:
In IB create new window, add NSTextField with content
$null (without the quotes) save in 10.2 or later format. Close.
Open again. Look at your string.
2. A whole new project:
- main.m --
#import Foundation/Foundation.h
#import TwoStrings.h
int main (int argc, const char * argv[])
{
NSAutoreleasePool * pool = [[NSAutoreleasePool alloc] init];
NSString *s1 = @$null; // NSKeyedArchiver cannot handle this -
last tested 10.4.11
NSString *s2 = @$Null;
TwoStrings *to = [ [ TwoStrings alloc ] initWith: s1 and: s2 ];
NSLog(@ original: %@, to);
NSData *dataA = [ NSArchiver archivedDataWithRootObject: to ];
TwoStrings *ta = [ NSUnarchiver unarchiveObjectWithData: dataA ];
NSLog(@ Archiver: %@ %3u bytes, ta, [ dataA length ]);
NSData *dataK = [ NSKeyedArchiver archivedDataWithRootObject: to ];
TwoStrings *tk = [ NSKeyedUnarchiver unarchiveObjectWithData: dataK ];
NSLog(@ KeyedArchiver: %@ %3u bytes, tk, [ dataK length ]);
[pool release];
return 0;
}
- TwoStrings.h --
@interface TwoStrings : NSObject
{
NSString *s1;
NSString *s2;
}
- initWith:(NSString *)sender and: (NSString *)s ;
@end
- TwoStrings.m --
#import TwoStrings.h
@implementation TwoStrings
- initWith:(NSString *)sender and: (NSString *)s ;
{
self = [ super init ];
if ( self == nil ) return nil;
s1 = [ sender retain ];
s2 = [ s retain ];
return self;
}
- (void)dealloc
{
[ s1 release ];
[ s2 release ];
[ super dealloc ];
}
- (NSString *)description
{
NSString *s = [ NSString stringWithFormat: @%@ %p s1=\[EMAIL PROTECTED] s1=\%@
\,[ self class], self, s1, s2 ];
return s;
}
- (void)encodeWithCoder:(NSCoder *)coder
{
//[super encodeWithCoder:coder]; // not for direct subclasses of
NSObject
if ( [coder allowsKeyedCoding] )
{
[ coder encodeObject: s1forKey: @s1 ];
[ coder encodeObject: s2forKey: @s2 ];
}
else
{
[ coder encodeObject: s1 ];
[ coder encodeObject: s2 ];
};
}
- (id)initWithCoder:(NSCoder *)decoder
{
//self = [super initWithCoder:decoder]; // not for direct subclasses
of NSObject
if ( [decoder allowsKeyedCoding] )
{
s1 = [ decoder decodeObjectForKey: @s1 ];
s2 = [ decoder decodeObjectForKey: @s2 ];
}
else
{
s1 = [ decoder decodeObject ];
s2 = [ decoder decodeObject ];
};
[ s1 retain ];
[ s2 retain ];
return self;
}
@end
- End of project --
Maybe this will work on Leopard. On Tiger it does not. (No crash, nor
error message either).
Kind regards,
Gerriet.
___
Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)
Please do not post admin requests or moderator comments to the list.
Contact the moderators at cocoa-dev-admins(at)lists.apple.com
Help/Unsubscribe/Update your Subscription:
http://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com
This email sent to [EMAIL PROTECTED]
Re: I don't understand why this is leaking...
On 12 Aug 2008, at 17:19, Graham Cox wrote: On 12 Aug 2008, at 6:42 pm, Gerriet M. Denkmann wrote: 2. NSKeyedArchiver can only store certain strings (tested in 10.4.11), which makes it absolutely unusable for the storage of strings if the possible values are not known in advance. Eh? That's just not true. Well, this is a bold statement. Can you prove it? Can you provide an example of a string that it can't store? What about your previous sentence, if I could? Anything that's NSCoding compliant can be stored, and NSString is. Well, I admit that all NSStrings should be able to be stored. I'm sure if it weren't someone would have raised merry hell about it before now. Something's fishy... Reminds of a very rational being walking the streets with his son. The son: Hey dad, there's a hundred dollar note! Dad: No son, this cannot be. If the note were real, somebody would have picked it up long ago. As for file sizes, is that really all that relevant these days? Archives don't store huge amount of overhead compared to the data itself - saving a few bytes here and there is not worth the pain of losing the convenience of keyed archiving. A factor of two or three may be considered a few bytes here and there or might amount to some pain. All according to taste and situation. Non-keyed archiving produces inherently very fragile file formats, which are a lot of work to maintain. Keyed archiving on the other hand, makes handling format changes trivial. This is absolutely correct. Kind regards, Gerriet. ___ Cocoa-dev mailing list (Cocoa-dev@lists.apple.com) Please do not post admin requests or moderator comments to the list. Contact the moderators at cocoa-dev-admins(at)lists.apple.com Help/Unsubscribe/Update your Subscription: http://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to [EMAIL PROTECTED]
Re: I don't understand why this is leaking...
On 12 Aug 2008, at 8:40 pm, Gerriet M. Denkmann wrote: I'm sure if it weren't someone would have raised merry hell about it before now. Something's fishy... Reminds of a very rational being walking the streets with his son. The son: Hey dad, there's a hundred dollar note! Dad: No son, this cannot be. If the note were real, somebody would have picked it up long ago. OK, fair comment. But let's look at the string you can't store: $null This reminds *me* of the old joke: Doctor, doctor, it hurts when I do this! (...) Well, don't do that then... If that's the one string you can't store, presumably because it's used as a marker within the archive, then don't try to store what is a reserved byte sequence. For its purpose, you can find an easy way around it. What you seemed to be implying was that there is a whole class of string sequences that broke keyed archiving, which of course would be far worse than this one apparently reserved string. If you need to store $null, just substitute another string to stand for it, archive that, and reverse the substitution when you decode. If that is the argument between using keyed versus non-keyed archiving, it's an awful lot to lose for a very minor inconvenience for this one case. And, yes, I would probably agree that Apple should be performing this substitution in their code rather than exposing this bug - but then again it would only be shifting the problem onto whatever substitution string they chose, though that could be made very much less likely to collide. As for file sizes, is that really all that relevant these days? Archives don't store huge amount of overhead compared to the data itself - saving a few bytes here and there is not worth the pain of losing the convenience of keyed archiving. A factor of two or three may be considered a few bytes here and there or might amount to some pain. All according to taste and situation. True enough, but. A factor of two or three? Depends on what your data is. If you're archiving a large image or video sequence, the archive overhead is going to be an infinitesimal fraction of this. And if not, then you're likely talking about small files anyway. 10K or 30K? It hardly matters. Even if 20K of the file is not data, who cares? I know I'm willing to spend 20K (or even 200K) to read the remaining 10K (or 100K) so very conveniently. Last time I cared about 10K versus 30K was when Macs had an optional external 20MB(!) Hard Disk and 800K floppies. So yes, according to your taste and situation. But surely the pain of using non-keyed archiving *by far* outweighs these considerations? cheers, Graham ___ Cocoa-dev mailing list (Cocoa-dev@lists.apple.com) Please do not post admin requests or moderator comments to the list. Contact the moderators at cocoa-dev-admins(at)lists.apple.com Help/Unsubscribe/Update your Subscription: http://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to [EMAIL PROTECTED]
Re: I don't understand why this is leaking...
Probably $null is a reserved word. -encodeWithCoder: (NSString) and -
initWithCoder: (NSString) should escape that. No good …
Amin
Am Di,12.08.2008 um 12:25 schrieb Gerriet M. Denkmann:
On 12 Aug 2008, at 15:50, Negm-Awad Amin wrote:
Am Di,12.08.2008 um 10:42 schrieb Gerriet M. Denkmann:
On 9 Aug 2008, at 17:39:20 -0600, Jonathan deWerd [EMAIL PROTECTED]
wrote:
On Aug 9, 2008, at 4:48 PM, Cate Tony wrote:
[...]
Also, why are you using non-keyed encoding? -encodeObject:forKey:
is
the preferred way of doing things nowadays...
Well, it may be the preferred way, but it is not always the best,
nor even the correct way.
Two reasons:
1. the resulting files are much bigger
2. NSKeyedArchiver can only store certain strings (tested in
10.4.11), which makes it absolutely unusable for the storage of
strings if the possible values are not known in advance.
Do you have an example for that?
Yes, I have.
1. Simple Test:
In IB create new window, add NSTextField with content
$null (without the quotes) save in 10.2 or later format. Close.
Open again. Look at your string.
2. A whole new project:
- main.m --
#import Foundation/Foundation.h
#import TwoStrings.h
int main (int argc, const char * argv[])
{
NSAutoreleasePool * pool = [[NSAutoreleasePool alloc] init];
NSString *s1 = @$null; // NSKeyedArchiver cannot handle this -
last tested 10.4.11
NSString *s2 = @$Null;
TwoStrings *to = [ [ TwoStrings alloc ] initWith: s1 and: s2 ];
NSLog(@ original: %@, to);
NSData *dataA = [ NSArchiver archivedDataWithRootObject: to ];
TwoStrings *ta = [ NSUnarchiver unarchiveObjectWithData: dataA ];
NSLog(@ Archiver: %@ %3u bytes, ta, [ dataA length ]);
NSData *dataK = [ NSKeyedArchiver archivedDataWithRootObject: to ];
TwoStrings *tk = [ NSKeyedUnarchiver unarchiveObjectWithData:
dataK ];
NSLog(@ KeyedArchiver: %@ %3u bytes, tk, [ dataK length ]);
[pool release];
return 0;
}
- TwoStrings.h --
@interface TwoStrings : NSObject
{
NSString *s1;
NSString *s2;
}
- initWith:(NSString *)sender and: (NSString *)s ;
@end
- TwoStrings.m --
#import TwoStrings.h
@implementation TwoStrings
- initWith:(NSString *)sender and: (NSString *)s ;
{
self = [ super init ];
if ( self == nil ) return nil;
s1 = [ sender retain ];
s2 = [ s retain ];
return self;
}
- (void)dealloc
{
[ s1 release ];
[ s2 release ];
[ super dealloc ];
}
- (NSString *)description
{
NSString *s = [ NSString stringWithFormat: @%@ %p s1=\[EMAIL PROTECTED] s1=
\[EMAIL PROTECTED],[ self class], self, s1, s2 ];
return s;
}
- (void)encodeWithCoder:(NSCoder *)coder
{
//[super encodeWithCoder:coder]; // not for direct subclasses of
NSObject
if ( [coder allowsKeyedCoding] )
{
[ coder encodeObject: s1forKey: @s1 ];
[ coder encodeObject: s2forKey: @s2 ];
}
else
{
[ coder encodeObject: s1 ];
[ coder encodeObject: s2 ];
};
}
- (id)initWithCoder:(NSCoder *)decoder
{
//self = [super initWithCoder:decoder]; // not for direct
subclasses of NSObject
if ( [decoder allowsKeyedCoding] )
{
s1 = [ decoder decodeObjectForKey: @s1 ];
s2 = [ decoder decodeObjectForKey: @s2 ];
}
else
{
s1 = [ decoder decodeObject ];
s2 = [ decoder decodeObject ];
};
[ s1 retain ];
[ s2 retain ];
return self;
}
@end
- End of project --
Maybe this will work on Leopard. On Tiger it does not. (No crash,
nor error message either).
Kind regards,
Gerriet.
Amin Negm-Awad
[EMAIL PROTECTED]
___
Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)
Please do not post admin requests or moderator comments to the list.
Contact the moderators at cocoa-dev-admins(at)lists.apple.com
Help/Unsubscribe/Update your Subscription:
http://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com
This email sent to [EMAIL PROTECTED]
Re: I don't understand why this is leaking...
On Tue, Aug 12, 2008 at 10:25 PM, Gerriet M. Denkmann [EMAIL PROTECTED] wrote: Yes, I have. 1. Simple Test: In IB create new window, add NSTextField with content $null (without the quotes) save in 10.2 or later format. Close. Open again. Look at your string. [...] Maybe this will work on Leopard. On Tiger it does not. (No crash, nor error message either). I tested this in Leopard, 2.x NIBs have this problem, but 3.X NIBs and XIBs do not. It looks like it was a bug that's fixed in Leopard, but preserved in some cases for backwards compatability. Although, I wouldn't consider this bug much of a reason for not using keyed archiving. Even though NS(Un)Archiver aren't deprecated, they have been replaced. Phil ___ Cocoa-dev mailing list (Cocoa-dev@lists.apple.com) Please do not post admin requests or moderator comments to the list. Contact the moderators at cocoa-dev-admins(at)lists.apple.com Help/Unsubscribe/Update your Subscription: http://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to [EMAIL PROTECTED]
Re: I don't understand why this is leaking...
On 12 Aug 2008, at 18:26, Negm-Awad Amin wrote:
Probably $null is a reserved word. -encodeWithCoder: (NSString) and
-initWithCoder: (NSString) should escape that. No good …
Wenn es das wäre, dann hätte man das sicherlich documentiert.
(This as a challenge for our English-speaking (or should one say:
germanilly challenged ?) list-members).
Herzliche Grüße aus Bangkok
Gerriet.
A: Yes.
| Q: Are you sure?
| | A: Because it reverses the logical flow of conversation.
| | | Q: Why is top posting frowned upon?
Amin
Am Di,12.08.2008 um 12:25 schrieb Gerriet M. Denkmann:
On 12 Aug 2008, at 15:50, Negm-Awad Amin wrote:
Am Di,12.08.2008 um 10:42 schrieb Gerriet M. Denkmann:
On 9 Aug 2008, at 17:39:20 -0600, Jonathan deWerd
[EMAIL PROTECTED]wrote:
On Aug 9, 2008, at 4:48 PM, Cate Tony wrote:
[...]
Also, why are you using non-keyed encoding? -
encodeObject:forKey: is
the preferred way of doing things nowadays...
Well, it may be the preferred way, but it is not always the
best, nor even the correct way.
Two reasons:
1. the resulting files are much bigger
2. NSKeyedArchiver can only store certain strings (tested in
10.4.11), which makes it absolutely unusable for the storage of
strings if the possible values are not known in advance.
Do you have an example for that?
Yes, I have.
1. Simple Test:
In IB create new window, add NSTextField with content
$null (without the quotes) save in 10.2 or later format. Close.
Open again. Look at your string.
2. A whole new project:
- main.m --
#import Foundation/Foundation.h
#import TwoStrings.h
int main (int argc, const char * argv[])
{
NSAutoreleasePool * pool = [[NSAutoreleasePool alloc] init];
NSString *s1 = @$null; // NSKeyedArchiver cannot handle this -
last tested 10.4.11
NSString *s2 = @$Null;
TwoStrings *to = [ [ TwoStrings alloc ] initWith: s1 and: s2 ];
NSLog(@ original: %@, to);
NSData *dataA = [ NSArchiver archivedDataWithRootObject: to ];
TwoStrings *ta = [ NSUnarchiver unarchiveObjectWithData: dataA ];
NSLog(@ Archiver: %@ %3u bytes, ta, [ dataA length ]);
NSData *dataK = [ NSKeyedArchiver archivedDataWithRootObject: to ];
TwoStrings *tk = [ NSKeyedUnarchiver unarchiveObjectWithData:
dataK ];
NSLog(@ KeyedArchiver: %@ %3u bytes, tk, [ dataK length ]);
[pool release];
return 0;
}
- TwoStrings.h --
@interface TwoStrings : NSObject
{
NSString *s1;
NSString *s2;
}
- initWith:(NSString *)sender and: (NSString *)s ;
@end
- TwoStrings.m --
#import TwoStrings.h
@implementation TwoStrings
- initWith:(NSString *)sender and: (NSString *)s ;
{
self = [ super init ];
if ( self == nil ) return nil;
s1 = [ sender retain ];
s2 = [ s retain ];
return self;
}
- (void)dealloc
{
[ s1 release ];
[ s2 release ];
[ super dealloc ];
}
- (NSString *)description
{
NSString *s = [ NSString stringWithFormat: @%@ %p s1=\[EMAIL PROTECTED] s1=
\[EMAIL PROTECTED],[ self class], self, s1, s2 ];
return s;
}
- (void)encodeWithCoder:(NSCoder *)coder
{
//[super encodeWithCoder:coder]; // not for direct subclasses of
NSObject
if ( [coder allowsKeyedCoding] )
{
[ coder encodeObject: s1forKey: @s1 ];
[ coder encodeObject: s2forKey: @s2 ];
}
else
{
[ coder encodeObject: s1 ];
[ coder encodeObject: s2 ];
};
}
- (id)initWithCoder:(NSCoder *)decoder
{
//self = [super initWithCoder:decoder]; // not for direct
subclasses of NSObject
if ( [decoder allowsKeyedCoding] )
{
s1 = [ decoder decodeObjectForKey: @s1 ];
s2 = [ decoder decodeObjectForKey: @s2 ];
}
else
{
s1 = [ decoder decodeObject ];
s2 = [ decoder decodeObject ];
};
[ s1 retain ];
[ s2 retain ];
return self;
}
@end
- End of project --
Maybe this will work on Leopard. On Tiger it does not. (No crash,
nor error message either).
Kind regards,
Gerriet.
Amin Negm-Awad
[EMAIL PROTECTED]
___
Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)
Please do not post admin requests or moderator comments to the list.
Contact the moderators at cocoa-dev-admins(at)lists.apple.com
Help/Unsubscribe/Update your Subscription:
http://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com
This email sent to [EMAIL PROTECTED]
Re: I don't understand why this is leaking...
On 12 Aug 2008, at 18:05, Graham Cox wrote: On 12 Aug 2008, at 8:40 pm, Gerriet M. Denkmann wrote: I'm sure if it weren't someone would have raised merry hell about it before now. Something's fishy... Reminds of a very rational being walking the streets with his son. The son: Hey dad, there's a hundred dollar note! Dad: No son, this cannot be. If the note were real, somebody would have picked it up long ago. OK, fair comment. But let's look at the string you can't store: $null This reminds *me* of the old joke: Doctor, doctor, it hurts when I do this! (...) Well, don't do that then... If that's the one string you can't store, presumably because it's used as a marker within the archive, then don't try to store what is a reserved byte sequence. It it were a reserved word, it would be documented so. Fact is, there is absolutly no need for reserved words. Nil should be stored as a reference to $objects[0], which is incidentally (as it has to be something) a string with value $null. And on unarchiving the unarchiver should check whether the string is a reference to the first object (and return nil) or else return its value (be it $null or whatever). Checking the value and returning nil if it is $null is a rather silly bug. For its purpose, you can find an easy way around it. What you seemed to be implying was that there is a whole class of string sequences that broke keyed archiving, which of course would be far worse than this one apparently reserved string. Yes, my statement: can store only certain strings while absolutely correct, was kind of sensational. And I admit that there are situations where the convenience of keyed archiving outweights the memory bloat (even *by far*) - and that there are other situation where it is more important to keep files or memory small. Kind regards, Gerriet. ___ Cocoa-dev mailing list (Cocoa-dev@lists.apple.com) Please do not post admin requests or moderator comments to the list. Contact the moderators at cocoa-dev-admins(at)lists.apple.com Help/Unsubscribe/Update your Subscription: http://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to [EMAIL PROTECTED]
Re: I don't understand why this is leaking...
Am Di,12.08.2008 um 14:11 schrieb Gerriet M. Denkmann:
On 12 Aug 2008, at 18:26, Negm-Awad Amin wrote:
Probably $null is a reserved word. -encodeWithCoder: (NSString) and
-initWithCoder: (NSString) should escape that. No good …
Wenn es das wäre, dann hätte man das sicherlich documentiert.
(This as a challenge for our English-speaking (or should one say:
germanilly challenged ?) list-members).
The challenglish continues :-)
Ich denke, dass man das einfach nicht bedacht hat. Vom Standpunkt von
NSString existiert dieses Problem ja nicht. Erst in Verbindung mit dem
Coder wird dieser das anders interpretieren.
Aber gut, dass es gefixt ist. So etwas kann einen ja in den Wahnsinn
treiben.
Herzliche Grüße aus Bangkok
Liebe Grüße
Amin
Gerriet.
A: Yes.
| Q: Are you sure?
| | A: Because it reverses the logical flow of conversation.
| | | Q: Why is top posting frowned upon?
Amin
Am Di,12.08.2008 um 12:25 schrieb Gerriet M. Denkmann:
On 12 Aug 2008, at 15:50, Negm-Awad Amin wrote:
Am Di,12.08.2008 um 10:42 schrieb Gerriet M. Denkmann:
On 9 Aug 2008, at 17:39:20 -0600, Jonathan deWerd [EMAIL PROTECTED]
wrote:
On Aug 9, 2008, at 4:48 PM, Cate Tony wrote:
[...]
Also, why are you using non-keyed encoding? -
encodeObject:forKey: is
the preferred way of doing things nowadays...
Well, it may be the preferred way, but it is not always the
best, nor even the correct way.
Two reasons:
1. the resulting files are much bigger
2. NSKeyedArchiver can only store certain strings (tested in
10.4.11), which makes it absolutely unusable for the storage of
strings if the possible values are not known in advance.
Do you have an example for that?
Yes, I have.
1. Simple Test:
In IB create new window, add NSTextField with content
$null (without the quotes) save in 10.2 or later format. Close.
Open again. Look at your string.
2. A whole new project:
- main.m --
#import Foundation/Foundation.h
#import TwoStrings.h
int main (int argc, const char * argv[])
{
NSAutoreleasePool * pool = [[NSAutoreleasePool alloc] init];
NSString *s1 = @$null; // NSKeyedArchiver cannot handle this -
last tested 10.4.11
NSString *s2 = @$Null;
TwoStrings *to = [ [ TwoStrings alloc ] initWith: s1 and: s2 ];
NSLog(@ original: %@, to);
NSData *dataA = [ NSArchiver archivedDataWithRootObject: to ];
TwoStrings *ta = [ NSUnarchiver unarchiveObjectWithData: dataA ];
NSLog(@ Archiver: %@ %3u bytes, ta, [ dataA length ]);
NSData *dataK = [ NSKeyedArchiver archivedDataWithRootObject:
to ];
TwoStrings *tk = [ NSKeyedUnarchiver unarchiveObjectWithData:
dataK ];
NSLog(@ KeyedArchiver: %@ %3u bytes, tk, [ dataK length ]);
[pool release];
return 0;
}
- TwoStrings.h --
@interface TwoStrings : NSObject
{
NSString *s1;
NSString *s2;
}
- initWith:(NSString *)sender and: (NSString *)s ;
@end
- TwoStrings.m --
#import TwoStrings.h
@implementation TwoStrings
- initWith:(NSString *)sender and: (NSString *)s ;
{
self = [ super init ];
if ( self == nil ) return nil;
s1 = [ sender retain ];
s2 = [ s retain ];
return self;
}
- (void)dealloc
{
[ s1 release ];
[ s2 release ];
[ super dealloc ];
}
- (NSString *)description
{
NSString *s = [ NSString stringWithFormat: @%@ %p s1=\[EMAIL PROTECTED] s1=
\[EMAIL PROTECTED],[ self class], self, s1, s2 ];
return s;
}
- (void)encodeWithCoder:(NSCoder *)coder
{
//[super encodeWithCoder:coder]; // not for direct subclasses of
NSObject
if ( [coder allowsKeyedCoding] )
{
[ coder encodeObject: s1forKey: @s1 ];
[ coder encodeObject: s2forKey: @s2 ];
}
else
{
[ coder encodeObject: s1 ];
[ coder encodeObject: s2 ];
};
}
- (id)initWithCoder:(NSCoder *)decoder
{
//self = [super initWithCoder:decoder]; // not for direct
subclasses of NSObject
if ( [decoder allowsKeyedCoding] )
{
s1 = [ decoder decodeObjectForKey: @s1 ];
s2 = [ decoder decodeObjectForKey: @s2 ];
}
else
{
s1 = [ decoder decodeObject ];
s2 = [ decoder decodeObject ];
};
[ s1 retain ];
[ s2 retain ];
return self;
}
@end
- End of project --
Maybe this will work on Leopard. On Tiger it does not. (No crash,
nor error message either).
Kind regards,
Gerriet.
Amin Negm-Awad
[EMAIL PROTECTED]
Amin Negm-Awad
[EMAIL PROTECTED]
Re: I don't understand why this is leaking...
On Aug 12, 2008, at 4:49 AM, Phil wrote: On Tue, Aug 12, 2008 at 10:25 PM, Gerriet M. Denkmann [EMAIL PROTECTED] wrote: Yes, I have. 1. Simple Test: In IB create new window, add NSTextField with content $null (without the quotes) save in 10.2 or later format. Close. Open again. Look at your string. [...] Maybe this will work on Leopard. On Tiger it does not. (No crash, nor error message either). I tested this in Leopard, 2.x NIBs have this problem, but 3.X NIBs and XIBs do not. It looks like it was a bug that's fixed in Leopard, but preserved in some cases for backwards compatability. Although, I wouldn't consider this bug much of a reason for not using keyed archiving. Even though NS(Un)Archiver aren't deprecated, they have been replaced. Sequential archives are still required for Distributed Objects, since NSPortCoder doesn't support keyed archiving. This is in spite of the AppKit release notes comment By the way, in case you missed it, you should really be using keyed archiving. -- Adam smime.p7s Description: S/MIME cryptographic signature ___ Cocoa-dev mailing list (Cocoa-dev@lists.apple.com) Please do not post admin requests or moderator comments to the list. Contact the moderators at cocoa-dev-admins(at)lists.apple.com Help/Unsubscribe/Update your Subscription: http://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to [EMAIL PROTECTED]
Re: I don't understand why this is leaking...
On Aug 12, 2008, at 07:49 , Phil wrote: On Tue, Aug 12, 2008 at 10:25 PM, Gerriet M. Denkmann [EMAIL PROTECTED] wrote: Yes, I have. 1. Simple Test: In IB create new window, add NSTextField with content $null (without the quotes) save in 10.2 or later format. Close. Open again. Look at your string. [...] Maybe this will work on Leopard. On Tiger it does not. (No crash, nor error message either). I tested this in Leopard, 2.x NIBs have this problem, but 3.X NIBs and XIBs do not. It looks like it was a bug that's fixed in Leopard, but preserved in some cases for backwards compatability. Although, I wouldn't consider this bug much of a reason for not using keyed archiving. Even though NS(Un)Archiver aren't deprecated, they have been replaced. Just for fun I tested the example program built from the command line in Leopard (10.5.4 9E17) running XCode 3.1 (latest build) and the current Foundation library... the problem as demonstrated by the example code still exists... the string @$null gets decoded as a nil pointer instead of a string with the word $null. Jason smime.p7s Description: S/MIME cryptographic signature ___ Cocoa-dev mailing list (Cocoa-dev@lists.apple.com) Please do not post admin requests or moderator comments to the list. Contact the moderators at cocoa-dev-admins(at)lists.apple.com Help/Unsubscribe/Update your Subscription: http://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to [EMAIL PROTECTED]
Re: I don't understand why this is leaking...
On Tue, Aug 12, 2008 at 7:05 AM, Graham Cox [EMAIL PROTECTED] wrote: On 12 Aug 2008, at 8:40 pm, Gerriet M. Denkmann wrote: I'm sure if it weren't someone would have raised merry hell about it before now. Something's fishy... Reminds of a very rational being walking the streets with his son. The son: Hey dad, there's a hundred dollar note! Dad: No son, this cannot be. If the note were real, somebody would have picked it up long ago. OK, fair comment. But let's look at the string you can't store: $null This reminds *me* of the old joke: Doctor, doctor, it hurts when I do this! (...) Well, don't do that then... More like this: Doctor, doctor, when I pump my arm, turn my head like this, and say the words 'klaatu barada nikto' I pass out on the floor! This isn't pain, it's a major malfunction. Any reasonable doctor would immediately get this person some medical care. Likewise, this NSKeyedArchiver behavior is a serious bug. You seem to be mixing up the difficulty in provoking it with mildness in effect. It may only happen in rare circumstances, but when it does happen, what happens is very bad behavior. Mike ___ Cocoa-dev mailing list (Cocoa-dev@lists.apple.com) Please do not post admin requests or moderator comments to the list. Contact the moderators at cocoa-dev-admins(at)lists.apple.com Help/Unsubscribe/Update your Subscription: http://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to [EMAIL PROTECTED]
I don't understand why this is leaking...
About $Null: It it were a reserved word, it would be documented so. The Archives and Serializations Programming Guide for Cocoa says: Keyed Archives ... Naming Values ... You should avoid using “$” as a prefix for your keys. The keyed archiver and unarchiver use keys prefixed with “$” for internal values. Although they test for and mangle user-defined keys that have a “$” prefix, this overhead slows down archiving performance. ... Greetings Klaus ___ Cocoa-dev mailing list (Cocoa-dev@lists.apple.com) Please do not post admin requests or moderator comments to the list. Contact the moderators at cocoa-dev-admins(at)lists.apple.com Help/Unsubscribe/Update your Subscription: http://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to [EMAIL PROTECTED]
Re: I don't understand why this is leaking...
On Tue, Aug 12, 2008 at 12:50 PM, Klaus Backert [EMAIL PROTECTED] wrote: You should avoid using $ as a prefix for your keys. The keyed archiver and unarchiver use keys prefixed with $ for internal values. Although they test for and mangle user-defined keys that have a $ prefix, this overhead slows down archiving performance. But this isn't a key, it's a value... :( --Kyle Sluder ___ Cocoa-dev mailing list (Cocoa-dev@lists.apple.com) Please do not post admin requests or moderator comments to the list. Contact the moderators at cocoa-dev-admins(at)lists.apple.com Help/Unsubscribe/Update your Subscription: http://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to [EMAIL PROTECTED]
Re: I don't understand why this is leaking...
On Tue, Aug 12, 2008 at 12:50 PM, Klaus Backert [EMAIL PROTECTED] wrote: About $Null: It it were a reserved word, it would be documented so. The Archives and Serializations Programming Guide for Cocoa says: Keyed Archives ... Naming Values ... You should avoid using $ as a prefix for your keys. The keyed archiver and unarchiver use keys prefixed with $ for internal values. Although they test for and mangle user-defined keys that have a $ prefix, this overhead slows down archiving performance. ... This is not a reserved word. This is merely a class of keys which can result in lower archiving performance (although still perfectly correct behavior). What's being discussed here is a case where a certain *value* (not a key) results in incorrect *behavior* (not just reduced speed). Mike ___ Cocoa-dev mailing list (Cocoa-dev@lists.apple.com) Please do not post admin requests or moderator comments to the list. Contact the moderators at cocoa-dev-admins(at)lists.apple.com Help/Unsubscribe/Update your Subscription: http://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to [EMAIL PROTECTED]
Re: I don't understand why this is leaking...
On Aug 12, 2008, at 12:50 , Klaus Backert wrote: About $Null: It it were a reserved word, it would be documented so. The Archives and Serializations Programming Guide for Cocoa says: Keyed Archives ... Naming Values ... You should avoid using “$” as a prefix for your keys. The keyed archiver and unarchiver use keys prefixed with “$” for internal values. Although they test for and mangle user-defined keys that have a “$” prefix, this overhead slows down archiving performance. ... In this case, however, it's the actual value being encoded... not the key name. Also, if you read it, it suggests that you shouldn't use it for performance reasons. It specifically states that it is supposed to properly mangle the $ in a key name (causing the performance loss)... smime.p7s Description: S/MIME cryptographic signature ___ Cocoa-dev mailing list (Cocoa-dev@lists.apple.com) Please do not post admin requests or moderator comments to the list. Contact the moderators at cocoa-dev-admins(at)lists.apple.com Help/Unsubscribe/Update your Subscription: http://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to [EMAIL PROTECTED]
I don't understand why this is leaking...
Am 12.08.2008 um 19:05 schrieb Jason Coco: On Aug 12, 2008, at 12:50 , Klaus Backert wrote: About $Null: It it were a reserved word, it would be documented so. The Archives and Serializations Programming Guide for Cocoa says: Keyed Archives ... Naming Values ... You should avoid using “$” as a prefix for your keys. The keyed archiver and unarchiver use keys prefixed with “$” for internal values. Although they test for and mangle user-defined keys that have a “$” prefix, this overhead slows down archiving performance. ... In this case, however, it's the actual value being encoded... not the key name. Also, if you read it, it suggests that you shouldn't use it for performance reasons. It specifically states that it is supposed to properly mangle the $ in a key name (causing the performance loss)... That's right. Sorry, I confused this. But talking about ... I read nothing in the documentation what using $-prefixed *keys* for internal values *exactly* does. It improves performance, okay, but it can be anything else, and a different thing tomorrow. I handle this implementation detail in the usual way. I will stay away from $- prefixed keys. Back to $-prefixed *values*: Gerriet Denkmann already realized something – which is not documented, as far as I know. A keyed archive contains a $object array, and the element $object[0] has the value $null. Implementation detail! I performed a test with my current project. I changed a certain value of a string variable to $null, saved it as a keyed archive in binary property list format – with the $null value anywhere in the middle –, opened the saved archive in a new document, and ... ***crash***: 2008-08-12 20:04:58.549 Blotto[24783] NSExceptionHandler has recorded the following exception: NSInvalidArgumentException -- *** -[NSPlaceholderDictionary initWithObjects:forKeys:]: number of objects (0) not equal to number of keys (21) Stack trace: 0x966eaf10 0x92c10e0c 0x92c552a0 0x92c18fc8 0x92bfaea4 0x92bfa688 0x7bd8 0x92bfaea4 0x92bfa688 0x0001840c 0x000160e8 0x93ac6344 0x00012acc 0x939504a8 0x00012e20 0x93ac5634 0x9394f960 0x93acc1fc 0x93acc03c 0x93acbec0 0x938358b4 0x93890094 0x9388fe18 0x9388f8c0 0x9388f50c 0x93799058 0x93790960 0x93881458 0x4334 0x3258 0x2f5c 0x1000 2008-08-12 20:04:58.550 Blotto[24783] NSExceptionHandler will now suspend the current thread and wait for debugger attachment _NSExceptionHandlerExceptionRaiser (in ExceptionHandling) +[NSException raise:format:] (in Foundation) -[NSDictionary initWithObjects:forKeys:] (in Foundation) -[NSDictionary initWithCoder:] (in Foundation) __decodeObjectBinary (in Foundation) __decodeObject (in Foundation) -[BloWorld initWithCoder:] (in Blotto) __decodeObjectBinary (in Foundation) __decodeObject (in Foundation) -[BloDocument readPListFromData:error:] (in Blotto) -[BloDocument readFromData:ofType:error:] (in Blotto) -[NSDocument readFromFileWrapper:ofType:error:] (in AppKit) -[YetDocument readFromFileWrapper:ofType:error:] (in Blotto) (YetDocument.m:153) -[NSDocument readFromURL:ofType:error:] (in AppKit) -[YetDocument readFromURL:ofType:error:] (in Blotto) (YetDocument.m:172) -[NSDocument _initWithContentsOfURL:ofType:error:] (in AppKit) -[NSDocument initWithContentsOfURL:ofType:error:] (in AppKit) -[NSDocumentController makeDocumentWithContentsOfURL:ofType:error:] (in AppKit) -[NSDocumentController openDocumentWithContentsOfURL:display:error:] (in AppKit) -[NSDocumentController openDocument:] (in AppKit) -[NSApplication sendAction:to:from:] (in AppKit) -[NSMenu performActionForItemAtIndex:] (in AppKit) -[NSCarbonMenuImpl performActionWithHighlightingForItemAtIndex:] (in AppKit) -[NSMenu performKeyEquivalent:] (in AppKit) -[NSApplication _handleKeyEquivalent:] (in AppKit) -[NSApplication sendEvent:] (in AppKit) -[NSApplication run] (in AppKit) _NSApplicationMain (in AppKit) _main (in Blotto) (main.m:10) __start (in Blotto) start (in Blotto) 0x1000 (in Blotto) q.e.d. Greetings Klaus ___ Cocoa-dev mailing list (Cocoa-dev@lists.apple.com) Please do not post admin requests or moderator comments to the list. Contact the moderators at cocoa-dev-admins(at)lists.apple.com Help/Unsubscribe/Update your Subscription: http://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to [EMAIL PROTECTED]
Re: I don't understand why this is leaking...
On 13 Aug 2008, at 00:05, Jason Coco wrote: On Aug 12, 2008, at 12:50 , Klaus Backert wrote: About $Null: It it were a reserved word, it would be documented so. The Archives and Serializations Programming Guide for Cocoa says: Keyed Archives ... Naming Values ... You should avoid using “$” as a prefix for your keys. The keyed archiver and unarchiver use keys prefixed with “$” for internal values. Although they test for and mangle user-defined keys that have a “$” prefix, this overhead slows down archiving performance. ... In this case, however, it's the actual value being encoded... not the key name. Also, if you read it, it suggests that you shouldn't use it for performance reasons. It specifically states that it is supposed to properly mangle the $ in a key name (causing the performance loss)... Also: this testing for and mangling overhead, which might slow down archiving performance consists of: in: if user_key starts with '@' then prepend another '@' out:if key starts with '@@' remove one '@'. Would be interesting to know, how much this really slows down the performance. Kind regards, Gerriet. ___ Cocoa-dev mailing list (Cocoa-dev@lists.apple.com) Please do not post admin requests or moderator comments to the list. Contact the moderators at cocoa-dev-admins(at)lists.apple.com Help/Unsubscribe/Update your Subscription: http://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to [EMAIL PROTECTED]
Re: I don't understand why this is leaking...
Le 10 août 08 à 00:48, Cate Tony a écrit :
This code is leaking:
- (void)saveItemExtensions:(id)sender
{
NSMutableString* itemExtensionsFilePath = [NSMutableString
stringWithString:@~/Library/Preferences/MyApp/extensions.abc];
NSDictionary* extensions = [NSDictionary dictionaryWithDictionary:
[itemDataSource itemExtensions]];
[itemExtensionsFilePath setString:[itemExtensionsFilePath
stringByExpandingTildeInPath]];
[[NSArchiver archivedDataWithRootObject:extensions]
itemExtensionsFilePath atomically: YES];
}
- (void)encodeWithCoder:(NSCoder *)coder
{
[coder encodeObject: string1];
[coder encodeObject: string2];
[coder encodeObject: string3];
[coder encodeObject: string4];
[coder encodeObject: string5];
[coder encodeObject: string6];
[coder encodeObject: string7];
[coder encodeObject: string8];
}
According to MallocDebug, the leak is in the encodeWithCoder method.
MallocDebug is not the best tool to debug Obj-C memory eaks. You
should use ObjectAlloc instead (an Instrument probe).
___
Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)
Please do not post admin requests or moderator comments to the list.
Contact the moderators at cocoa-dev-admins(at)lists.apple.com
Help/Unsubscribe/Update your Subscription:
http://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com
This email sent to [EMAIL PROTECTED]
I don't understand why this is leaking...
This code is leaking:
- (void)saveItemExtensions:(id)sender
{
NSMutableString* itemExtensionsFilePath = [NSMutableString
stringWithString:@~/Library/Preferences/MyApp/extensions.abc];
NSDictionary* extensions = [NSDictionary dictionaryWithDictionary:
[itemDataSource itemExtensions]];
[itemExtensionsFilePath setString:[itemExtensionsFilePath
stringByExpandingTildeInPath]];
[[NSArchiver archivedDataWithRootObject:extensions]
itemExtensionsFilePath atomically: YES];
}
- (void)encodeWithCoder:(NSCoder *)coder
{
[coder encodeObject: string1];
[coder encodeObject: string2];
[coder encodeObject: string3];
[coder encodeObject: string4];
[coder encodeObject: string5];
[coder encodeObject: string6];
[coder encodeObject: string7];
[coder encodeObject: string8];
}
According to MallocDebug, the leak is in the encodeWithCoder method.
Things I've tried:
1 [coder encodeObject: [string1 autorelease]]; Which, of course,
caused a crash
2 [coder encodeObject: [string1 copy]]; no diff
3 [coder encodeObject: [[string1 copy] autorelease]]; no diff
4 Drinking beer...
Can anyone explain this to me?
Tony
___
Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)
Please do not post admin requests or moderator comments to the list.
Contact the moderators at cocoa-dev-admins(at)lists.apple.com
Help/Unsubscribe/Update your Subscription:
http://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com
This email sent to [EMAIL PROTECTED]
Re: I don't understand why this is leaking...
On Aug 9, 2008, at 4:48 PM, Cate Tony wrote:
This code is leaking:
- (void)saveItemExtensions:(id)sender
{
NSMutableString* itemExtensionsFilePath = [NSMutableString
stringWithString:@~/Library/Preferences/MyApp/extensions.abc];
NSDictionary* extensions = [NSDictionary dictionaryWithDictionary:
[itemDataSource itemExtensions]];
[itemExtensionsFilePath setString:[itemExtensionsFilePath
stringByExpandingTildeInPath]];
[[NSArchiver archivedDataWithRootObject:extensions]
itemExtensionsFilePath atomically: YES];
}
- (void)encodeWithCoder:(NSCoder *)coder
{
[coder encodeObject: string1];
[coder encodeObject: string2];
[coder encodeObject: string3];
[coder encodeObject: string4];
[coder encodeObject: string5];
[coder encodeObject: string6];
[coder encodeObject: string7];
[coder encodeObject: string8];
}
According to MallocDebug, the leak is in the encodeWithCoder method.
Things I've tried:
1 [coder encodeObject: [string1 autorelease]]; Which, of course,
caused a crash
2 [coder encodeObject: [string1 copy]]; no diff
3 [coder encodeObject: [[string1 copy] autorelease]]; no diff
4 Drinking beer...
Can anyone explain this to me?
Tony
What is coder? It could be that coder is deferring the encoding
(saving copies of string*), and then the coder itself is never getting
released. Have Instruments make sure that the coder is actually going
away after the encoding is done. Also check to make sure the encoded
data is going away when it is no longer needed. Sometimes the leak
isn't exactly where MallocDebug says the object was allocated: -retain
increments the retain count as surly as -alloc. What do the individual
string* histories look like in Instruments? Speaking of Instruments,
could you give us (not the mailing list, I don't think it allows
attachments, but you could email me separately) an instruments session
to look at? It would greatly facilitate proceedings :)
Also, why are you using non-keyed encoding? -encodeObject:forKey: is
the preferred way of doing things nowadays...
___
Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)
Please do not post admin requests or moderator comments to the list.
Contact the moderators at cocoa-dev-admins(at)lists.apple.com
Help/Unsubscribe/Update your Subscription:
http://lists.apple.com/mailman/options/cocoa-dev/jjoonathan
%40gmail.com
This email sent to [EMAIL PROTECTED]
smime.p7s
Description: S/MIME cryptographic signature
___
Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)
Please do not post admin requests or moderator comments to the list.
Contact the moderators at cocoa-dev-admins(at)lists.apple.com
Help/Unsubscribe/Update your Subscription:
http://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com
This email sent to [EMAIL PROTECTED]
