• 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: Crash in CFRunLoopWakeUp
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Crash in CFRunLoopWakeUp


  • Subject: Re: Crash in CFRunLoopWakeUp
  • From: Mark Allan <email@hidden>
  • Date: Sat, 5 Sep 2009 15:44:10 +0100

On 4 Sep 2009, at 12:04 am, Greg Parker wrote:
On Sep 3, 2009, at 3:41 PM, Mark Allan wrote:
I've been battling with this intermittent crash for about two weeks now and can't figure it out for the life of me. I've got try/catch blocks around nearly all my code, and definitely around any code which runs in a separate thread, but it's not catching whatever causes this crash. Also, I'm not even convinced it's my threads causing the crash as this one happened while a modal sheet was being displayed, before any of my external threads got started.

Exception Type:  EXC_BREAKPOINT (SIGTRAP)
Exception Codes: 0x0000000000000001, 0x0000000090d5c02c
Crashed Thread:  6

Thread 6 Crashed:
0 com.apple.CoreFoundation 0x90d5c02c CFRunLoopWakeUp + 156
1 com.apple.Foundation 0x903ad0e4 _backgroundActivity + 440

EXC_BREAKPOINT means the process deliberately killed itself (including `int3` on i386, `trap` on ppc, `__builtin_trap()` in gcc). In the case of CFRunLoopWakeUp(), it's halting because it tried and failed to send a Mach message to that run loop. Most likely this means the target run loop has already been deleted, but other Mach messaging problems are possible.


_backgroundActivity is part of NSFileHandle, to perform things like - readInBackgroundAndNotify. Perhaps there's bad memory management of an NSFileHandle somewhere.

Thank you so much for your answer.

It turns out one of my threads was running after all and I think what was happening was that the NSTask started by my second thread was completing so quickly that the thread (and hence the run loop) was disappearing before some notification was being sent/received. I was under the impression that the waitUntilExit method was supposed to prevent this from happening, but it doesn't appear to be doing so reliably. Anyway, I've now moved all my -release calls into the object's dealloc method, removed the -waitUntilExit call and the NSTask is now being started from the main run loop. Hopefully that covers all the bases.

Because it's an intermittent bug, it'll be a while before I can be sure I've managed to squash it once and for all, but initial reports look good :)
Thanks again
Mark


_______________________________________________

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


References: 
 >Crash in CFRunLoopWakeUp (From: Mark Allan <email@hidden>)
 >Re: Crash in CFRunLoopWakeUp (From: Greg Parker <email@hidden>)

  • Prev by Date: Re: NSString width
  • Next by Date: crash question NSString
  • Previous by thread: Re: Crash in CFRunLoopWakeUp
  • Next by thread: Binding table columns that change at runtime
  • Index(es):
    • Date
    • Thread