Re: newbie EXC_BAD_ACCESS
Re: newbie EXC_BAD_ACCESS
- Subject: Re: newbie EXC_BAD_ACCESS
- From: Daniel Child <email@hidden>
- Date: Sun, 20 Mar 2005 10:50:26 -1000
Unfortunately, the suggestions below do not work. I still get the
crash. I had also printed out retain counts on knownStrokes.
One thing I don't understand. If I create an instance of StrokesArray
"sa" having an instance variable knownStrokes, why should I have to
specially retain knownStrokes. Shouldn't it come with sa itself.
Also, why do I have to specify the initial capacity of knownStrokes in
the first place. Is there an advantage to the capacity methods below
compared to plain old alloc/init?
On Sunday, March 20, 2005, at 02:53 AM, Jyrki Wahlstedt wrote:
On 20.3.2005, at 13:19, Larry Fransson wrote:
On Mar 20, 2005, at 2:11 AM, Daniel Child wrote:
// INITIATION AND DEALLOCATION
- (id)init
{
if (self = [super init])
{
knownStrokes = [NSMutableArray arrayWithCapacity: 100];
[self fillKnownStrokes]; // puts a bunch of stroke descriptons
in the array
}
return self;
}
Why would something like this be autoreleased or otherwise "bad
access"?
It's probably because you're using a class method
(+arrayWithCapacity:) to initialize knownStrokes and it doesn't
appear you're doing anything to retain knownStrokes. Class methods
like +arrayWithCapacity:, etc. (generally any method that doesn't
involve an alloc and init) return an autoreleased object. It's up to
you to retain it if you want it to stick around. You need to make a
change. Either this
knownStrokes = [[NSMutableArray arrayWithCapacity:100] retain];
or this
knownStrokes = [[NSMutableArray alloc] initWithCapacity: 100];
My method for debugging signal 10 and 11 crashes is to look for
objects I haven't retained and retain them, or to eliminate release
messages sent to other objects until the crash goes away. Then I
figure out why there was a problem.
Hi,
I can confirm this (probably => surely). I should know, I have done
the same mistake in the beginning…
_______________________________________________
Do not post admin requests to the list. They will be ignored.
Cocoa-dev mailing list (email@hidden)
Help/Unsubscribe/Update your Subscription:
This email sent to email@hidden