Re: Initializing an Array
Re: Initializing an Array
- Subject: Re: Initializing an Array
- From: Jeff Galyan <email@hidden>
- Date: Tue, 22 Jan 2002 14:19:29 -0700
On 1/22/02 1:51 PM, "Marcel Weiher" <email@hidden> wrote:
>
On Tuesday, January 22, 2002, at 07:57 , Jeff Galyan wrote:
>
>
Missing [super init];
Sorry, omitted from post. Real code has it.
>
>
>
Missing [super dealloc];
Another one omitted from post.
>
Redundant retain.
>
Should probably assert that aString is non-nil because you're relying on
>
that later on.
>
>
>
Since c-string manipulation can crash (instead of raising exceptions),
>
you should probably assert that myString is not nil.
NSParameterAssert was causing a segfault every time I called it, regardless
of where I called it from.
>
>
This is leaking an AppCrasher object.
>
That's okay for now. I'll be cleaning that up later.
>
>
Once again, deallocating an object does not set instance variables
>
pointing to that object to nil. The fact that you're seeing
>
instance-vars getting zeroed means that something else is going on.
>
From your description so far, it sounds like you're stomping over memory.
Well, here's the rub: when I malloc or calloc something and then free it
after use (in Cocoa, and after ensuring it's non-NULL), I get a segfault
when the ObjC runtime tries to free it again. If I don't free it myself,
everything is okay (though I expect I'm leaking a few kb here and there).
>
>
Another option is that the object *containing* the instance vars is
>
getting deallocated and the memory belonging to it reused.
If this is happening, something is definitely wrong with the runtime, as it
should not be getting deallocated until the owner has released it.
Doing the same stuff in Carbon with CFString objects works. I'm only seeing
this behavior in Cocoa (same with the problem of UI components suddenly
becoming nil). Only problem is, my client doesn't want a Carbon app, they
want a Cocoa app.
--Jeff