syscall_thread_switch iOS 8.3 race - CocoaLumberjack bug? how to debug this?

Question

I'm hitting a race-condition in my app, where all or all but 1 threads get stuck on syscall_thread_switch whenever I pause debugging. It reproduces much more often on the simulator, but also on the iPad Air. There is ALWAYS at least 2 threads stuck in CocoaLumberjack's queueLogMessage: -- see screenshots.

I've never seen this before on 8.1 and 8.2, but i'm hitting it often on 8.3. I'm not claiming this is an 8.3 bug :)

This is a level of complexity i've never had to debug before, so i'm not sure what to do. I hope I'm providing enough information, please let me know if you need more (please be specific about how to get the information if it isn't dead clear). Can you please help me debug this?! Millions of thanks.

Staphylo

CocoaLumberjack looks a bit over engineered to me. I would use an alternative (i.e. write your own). – Fayefayette

Sorry, switching away from cocoalumberjack would be too big of a change right now. Besides, it is so widely used in such big projects, chances are the problem is in my code (not in cocoalumberjack). But i don't know how to debug this. – Staphylo

UPDATE: it does appear to be a bug in CocoaLumberjack. Tracking here: github.com/CocoaLumberjack/CocoaLumberjack/issues/494 – Staphylo

I am experiencing something very similar. Not seen before 8.3. I have CocoaLumberjack installed in the effected project but I am not convinced it is the cause as - in my case - no cocoaLumberjack calls are showing up in any of the threads during the hang. I have only seen the issue in the simulator (so far). – Gildus

Similar issue here after upgrading to XCode 6.3. Our app uses CocoaLumberjack as well. No cocoalumberjack calls showing in the stack trace. – Woodsia

I started seeing this issue after moving to iOS 8.3 and I'm not using CocoaLumberjack. It happens randomly, not always at the same place and not always. I have no idea why it's doing this. – Miaow

See also Application sticks on OSSpinLockLockSlow - I don't think this is a CocoaLumberjack issue. – Gildus

Answer 1

I hit a similar issue with NSOperations in a NSOperationQueue in iOS 8.3 (not related to CocoaLumberjack). I had concurrent operations creating their own threads, which is no-longer needed. It behaved perfectly well in 8.2, but not 8.3.

In the start method I simply replaced:

[NSThread detachNewThreadSelector:@selector(main) toTarget:self withObject:nil];

With:

[self main];

Rhearheba