Re: Mystery Thread - how to debug
Re: Mystery Thread - how to debug
- Subject: Re: Mystery Thread - how to debug
- From: Ken Thomases <email@hidden>
- Date: Wed, 16 Jul 2008 14:32:17 -0500
On Jul 15, 2008, at 3:28 PM, James Bucanek wrote:
I've got another thread -- which I'll refer to as the "mystery
thread" -- that is stuck in a spinlock. The sample looks like this:
7464 Thread_2a03
7464 thread_start
7464 _pthread_start
7464 __NSThread__main__
7464 -[NSThread main]
7464 __spin_lock
7464 __spin_lock
I'm *assuming* that this is the worker thread exiting. But since
there's no symbolic information associated with my application I
can't figure out what thread this belongs to, what selector it will/
did execute, or why the heck it's stuck on a spinlock.
Any ideas?
In Leopard, you can assign names to threads using -[NSThread
setName:]. If you name all of your threads, then when you get a hang
like this you can inspect the name to get a hint. Once your
application has gotten stuck, attach to it with the debugger. Select
that thread, select the frame in -[NSThread main], and examine
"self". If this isn't a debug build of your app, and you're on x86,
you can use a command like this to obtain self from the stack frame:
p *(id*)($ebp + 8)
po $1 <---- where $1 is the result from the previous command
po [$1 name]
Another approach to try is the Object Allocations instrument. In
theory, the NSThread instance must have been allocated at the point
in your code where the thread was spun off. Object Allocations can
show you what NSThread objects are still "live" (allocated but not
yet deallocated) and can show you the backtrace of the allocation.
Good luck,
Ken
_______________________________________________
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