Skip to content

The main thread Hang #812

New issue
New issue
Closed
Closed
The main thread Hang#812
Labels
Awaiting responseBlockerImportant
Milestone
 
Future
@rooboios

Description

@rooboios
rooboios
opened on Dec 1, 2016

Issue Info

Info Value
Platform Name iOS
Platform Version 10.1.1
CocoaLumberjack Version 3.0.0
Integration Method cocoapods
Xcode Version Xcode 8.1

The main thread Hang

2016-12-01 5 33 45
2016-12-01 5 33 56

Activity

mitchell-dream

mitchell-dream commented on Dec 3, 2016

@mitchell-dream
mitchell-dream
on Dec 3, 2016

I have the save problem.

guidedways

guidedways commented on Apr 16, 2017

@guidedways
guidedways
on Apr 16, 2017

Same here! I kept pulling my hair out till I realised it's Cocoalumberjack causing this. Any fix?

bpoplauschi
added
Blocker
Important
on May 2, 2017
bpoplauschi

bpoplauschi commented on May 2, 2017

@bpoplauschi
bpoplauschi
on May 2, 2017
Member

We should investigate and fix, this sounds like a real problem.

@rooboios @mcmengchen @guidedways are you logging errors in that case? Because for errors, we are logging synchronously and that might somehow cause a deadlock.

CC @rivera-ernesto

guidedways

guidedways commented on May 2, 2017

@guidedways
guidedways
on May 2, 2017

Yup, was logging errors. I had to change it in a fork to not use the main thread (although the problem was elsewhere in our code that kept hammering the main thread, it was however cocoalumberjack that caused a deadlock).

bpoplauschi

bpoplauschi commented on May 3, 2017

@bpoplauschi
bpoplauschi
on May 3, 2017
Member

@guidedways Any suggestions on how we can fix this in CocoaLumberjack?

guidedways

guidedways commented on May 3, 2017

@guidedways
guidedways
on May 3, 2017

@bpoplauschi I'm not a 100% sure but clearly the deadlock is there on the locks used by the dispatch queue, and so if we were simply to by pass using dispatch_sync, we would solve the problem. dispatch_sync is known to cause dead-locks (for instance calling it on the main queue from code executing on the main queue would cause it to hold the lock indefinitely).

The issue is here in DDLog.m:

    if (asyncFlag) {
        dispatch_async(_loggingQueue, logBlock);
    } else {
        dispatch_sync(_loggingQueue, logBlock); <--- causing the deadlock
    }

Clearly, two background threads throwing an error at the same time is causing it to dead-lock (since they're both calling dispatch_sync on the same queue at the same time). And this is possibly what's happening in our case since we have several background worker threads, and two or three may at a given time try and DDLogError(...) at the same time.

I should suggest we add the following method:

- (BOOL) isOnLoggingQueue {
  static const void* loggingQueueKey = @"loggingQueue";
  static void* loggingQueueContext = @"loggingQueue";
  
  static dispatch_once_t onceToken;
  dispatch_once(&onceToken, ^{   
    dispatch_queue_set_specific(_loggingQueue, loggingQueueKey, loggingQueueContext, nil);    
  });
  return dispatch_get_specific(loggingQueueKey) == loggingQueueContext;
}

And change the code to:

    if (asyncFlag) {
        dispatch_async(_loggingQueue, logBlock);
    } else {
       if ([self isOnLoggingQueue]) {
            logBlock();
       } else {
            dispatch_sync(_loggingQueue, logBlock);
       }
    }

That should hopefully fix it.

tar500

tar500 commented on Jul 5, 2017

@tar500
tar500
on Jul 5, 2017

looks like it's related to #689
any update on this?

0xced
mentioned this on Jan 23, 2018
hhanesand

hhanesand commented on Dec 27, 2018

@hhanesand
hhanesand
on Dec 27, 2018 · edited by hhanesand
Contributor

@guidedways Adding the code you've presented would definitely improve threading situation, but I don't see it present in the stack trace you posted. Do you know if the fix you provided would also fix the stack trace in the first comment?

My hunch is that you're hitting a different issue... Anyways, I've implemented the fix you suggested in #1003

hhanesand
added a commit that references this issue on Dec 28, 2018

Implement bypass suggested in #812 (comment)

57b9748
hhanesand

hhanesand commented on Jan 11, 2019

@hhanesand
hhanesand
on Jan 11, 2019
Contributor

@rooboios @guidedways @mcmengchen @tar500 Can any of you reproduce this issue on the master branch? If you're able to, we'd love to see a backtrace from all threads, (via bt all).

hhanesand
added this to the Future milestone on Jan 11, 2019
hhanesand
added
Awaiting response
on Jan 11, 2019
hhanesand

hhanesand commented on Feb 3, 2019

@hhanesand
hhanesand
on Feb 3, 2019
Contributor

Closing due to no response. Please open a new issue with a full backtrace if you can reproduce this on version 3.5.0 or later.

hhanesand
closed this as completedon Feb 3, 2019
CocoaLumberjack
locked and limited conversation to collaborators on Feb 3, 2019
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

No one assigned

    Labels

    Awaiting responseBlockerImportant

    Type

    No type

    Projects

    No projects

    Milestone

    Relationships

    None yet

      Development

      No branches or pull requests

        Participants

        @bpoplauschi@guidedways@tar500@hhanesand@mitchell-dream

        Issue actions
          The main thread Hang · Issue #812 · CocoaLumberjack/CocoaLumberjack