• 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
Re: Threads + Garbage Collection = Crash?
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Threads + Garbage Collection = Crash?


  • Subject: Re: Threads + Garbage Collection = Crash?
  • From: Ashley Clark <email@hidden>
  • Date: Thu, 2 Oct 2008 13:46:31 -0500

On Oct 2, 2008, at 12:28 PM, Bill Bumgarner wrote:

On Oct 1, 2008, at 9:17 AM, Ashley Clark wrote:
As for your crashes I think I can offer some advice. If you're not doing
any mallocs then most likely you're passing objects back to your main
thread through some shared space, possibly via contextInfo:

Yes -- this can be a problem. If the contextInfo of an object is a stored in a (void *) instance variable, then the collector will not scan that iVar and will not that field as a reference to the object.


You can use CFRetain/CFRelease to prevent collection when a reference to the object is stored into an unscanned location.

I've seen in my own GC programs using threads that occasionally the
collector (usually during high object usage) will collect objects that are
in transit unless you CFRetain them in your thread before sending and then
CFRelease them in the other thread once you've assigned them to a gc-ed
storage variable.

This should only happen if the object is only referenced by unscanned memory. If there are references on any thread's stack, then the collector shouldn't touch the object (assuming the thread is registered with the collector). If you have a reproducible case where you think the object should not be collected, but is, please file a bug and send me the #.

Looking at your other email to the list about this I think my issue was that I was passing the objects to a delegate method using an NSInvocation object and then in that delegate method sending them on to the main thread through a contextInfo memory reference.


Like Oleg, I only saw the crash during periods of high activity on my second thread where a lot of objects were being created and destroyed. I was able to work around the problem by issuing a CFRetain in my delegate and then sending a CFRelease to it once I had it stored in scanned memory in the main thread.

If I read your message correctly though I should also be CFRetain'ing and CFRelease'ing the objects I'm sending with my NSInvocation object as well? Does this only apply when invoking the invocation on the main thread from a secondary thread, or is it general practice?

Ashley
_______________________________________________

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: Threads + Garbage Collection = Crash?
      • From: Bill Bumgarner <email@hidden>
References: 
 >Threads + Garbage Collection = Crash? (From: "Oleg Krupnov" <email@hidden>)
 >Re: Threads + Garbage Collection = Crash? (From: "Ashley Clark" <email@hidden>)
 >Re: Threads + Garbage Collection = Crash? (From: Bill Bumgarner <email@hidden>)

  • Prev by Date: Conditional mouseDownCanMoveWindow for NSView?
  • Next by Date: Re: Moving file to trash on afp volume
  • Previous by thread: Re: Threads + Garbage Collection = Crash?
  • Next by thread: Re: Threads + Garbage Collection = Crash?
  • Index(es):
    • Date
    • Thread