• Open Menu Close Menu
  • Apple
  • Shopping Bag
  • Apple
  • Mac
  • iPad
  • iPhone
  • Watch
  • TV
  • Music
  • Support
  • Search apple.com
  • Shopping Bag

Lists

Open Menu Close Menu
  • Terms and Conditions
  • Lists hosted on this site
  • Email the Postmaster
  • Tips for posting to public mailing lists
Garbage collector vs variable lifetime
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Garbage collector vs variable lifetime


  • Subject: Garbage collector vs variable lifetime
  • From: Quincey Morris <email@hidden>
  • Date: Fri, 6 Jun 2008 15:23:42 -0700

In a GC-only app, I frequently use a pattern along these lines:

	NSData* data = <get it from somewhere>;
	const unsigned char* bytes = [data bytes];
	NSUInteger count = [data length];
	for (NSUInteger i = 0; i < count; i++)
		something = bytes [i];

The "release" (but not the "debug") build of the app crashes (EXC_INVALID_ACCESS) at the 'bytes [i]' reference in one such piece of code. AFAICT, the crash happens because 'data' has been garbage collected out of existence during the loop. [The "somewhere" that 'data' came from in this case was a __weak instance variable that is 0 at the time of the crash but wasn't earlier; thread 2's stack trace shows the garbage collector finalizing a NSMutableData (which is what 'data' actually is) at the time of the crash.]

Apparently, compiler optimization has decided to shorten the lifetime of 'data' to *not* encompass the loop, and I was unlucky enough to have the garbage collector run in a separate thread during the loop execution.

Surely it ought to be regarded as a horrible compilation bug for the lifetime of a variable to be shortened like this, since the lifetime clearly has side effects (i.e. maintenance of a GC pointer)?

I tried adding "volatile" to the 'data' declaration, but that didn't change anything. I tried adding a simple 'data;' statement after the loop, but that got optimized away and the variable lifetime got shortened as in the original code. Adding another 'count = [data length];' after the loop did prevent the crash, because it apparently wasn't optimized away.

It seems to me that the consequence of this compiler defect is that it's not safe in general to use NSData in GC apps. At least, it's not safe to assume that a stack reference is sufficient to keep a NSData object alive.

Anyone got a less drastic perspective on this situation?

_______________________________________________

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


  • Follow-Ups:
    • Re: Garbage collector vs variable lifetime
      • From: Bill Bumgarner <email@hidden>
  • Prev by Date: Re: Using NSSortDescriptor to reverse sort an NSArray containing NSString objects
  • Next by Date: Re: Garbage collector vs variable lifetime
  • Previous by thread: [OT] DAQ Plot and Vvidget Workshop At University Of Pittsburgh
  • Next by thread: Re: Garbage collector vs variable lifetime
  • Index(es):
    • Date
    • Thread