Re: GC crash due to being naughty
Re: GC crash due to being naughty
- Subject: Re: GC crash due to being naughty
- From: Ben Haller <email@hidden>
- Date: Thu, 15 Oct 2009 20:43:42 -0400
On 15-Oct-09, at 8:26 PM, Greg Parker wrote:
I don't see any global pointer variables involved. My guess is that
`individuals` is uninitialized or NULL or
`individuals[individualCount]` is out of bounds. The write barrier
objc_assign_strongCast() does range checks on the destination
address, and will fall back to auto_zone_root_write_barrier() for
addresses it doesn't recognize. Those include malloc blocks, global
variables, and bogus addresses.
Perhaps another way to ask the question is: suppose you wanted to
implement a new collection class, akin to NSMutableArray but
somehow different. How would you safely do it under GC, without
using any of the pre-made Cocoa collections internally? That's all
my AKPopulation really is: a poor man's (but a speedy man's!) re-
implementation of something like NSMutableArray. Ought to be
possible, right? So how do I manage this write barrier business to
make it work properly?
You need to ensure two things when implementing storage for GC
pointers. First, the storage must be scanned by the garbage
collector. Second, writes to the storage must use an appropriate
write barrier function...
This all makes sense to me, to the extent that I understand write
barriers at all. :->
I switched my code over to NSAllocateCollectable with
NSScannedOption, and it still crashed.
This led me to generate a new hypothesis: that I am an idiot. I
have now proven that hypothesis to my full satisfaction. I will not
be telling the list what the error was that caused my code to crash.
Let's just say I'm very out of practice at this whole coding thing,
and leave it at that. :->
Still, this thread was quite useful in that it did solidify my
understanding of weak/strong/dangling, and led me to switch my
collection class over to strong references. That's progress. Thanks
to everybody for their help!
Ben Haller
Stick Software
_______________________________________________
Cocoa-dev mailing list (email@hidden)
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:
This email sent to email@hidden