10

When debugging on iOS, if I pause execution I often see multiple references to "__workq_kernreturn".

If my app happens to crash, I often see multiple threads identified as below: 

Thread 19:
0   libsystem_kernel.dylib              0x332d0cd4 __workq_kernreturn + 8

Thread 20:
0   libsystem_kernel.dylib              0x332d0cd4 __workq_kernreturn + 8

Thread 21:
0   libsystem_kernel.dylib              0x332d0cd4 __workq_kernreturn + 8

Does "__workq_kernreturn" indicate a thread that is waiting to exit, or a thread that is deadlocked? Is this something to be worried about?

Vik
  • 1,301
  • 4
  • 16
  • 29

1 Answers1

9

It's nothing to worry about unless there are lots of them. If there are lots, that suggests you may be spawning more threads than you probably should, but the workq_kernreturn is still not a problem itself. It usually means that the thread is finishing. The source for it is available at opensource.apple.com if you want to take a look at what it does.

The most common stack you're probably looking at is this one:

_workq_kernreturn
_pthread_wqthread
start_wqthread

Because of optimizations, you don't see the call to _pthread_workq_return() in there, but that's what's actually happening. _workq_kernreturn is just waiting for for the spinlock to finish so it can run the next thing on its queue (or exit).

Rob Napier
  • 286,113
  • 34
  • 456
  • 610
  • 15
    The response I received from an Apple engineer on the devforums was "Ignore them. Those are GCD dispatch worker threads that are waiting for work. They may be assigned work to do later, or they may exit if they stay idle long enough." – Vik Feb 06 '12 at 14:49
  • I see this same stack trace, but it's the crashing thread. That's why I'm concerned. It seems out of my code that is actually crashing. – Joey Carson Sep 22 '15 at 20:44