Uploaded image for project: 'Sourcetree For Mac'
  1. Sourcetree For Mac
  2. SRCTREE-1983

SourceTree locks up ("spinning rainbow cursor") when VoiceOver is on

    • Icon: Bug Bug
    • Resolution: Unresolved
    • Icon: High High
    • None
    • 1.7.4.1
    • General
    • None
    • MacOS X 10.9.0
      Mac Pro (mid-2010), and MacBook Pro 15" Retina

    • Severity 1 - Critical

      Whenever I turn on VoiceOver while SourceTree is running, SourceTree goes into an endless loop. The spinning rainbow cursor appears and my only option is to force-quit the app.

      I've been working on accessibility support in my application, so I've been using VO a lot. I've been noticing that SourceTree has been locking up like this for a while and it has been driving me absolutely nuts.

      But I didn't put my finger on VO as the culprit until I happened to look at a stack trace showing where it was hung.

      Once I saw that accessibility related stuff on the stack, I tried reproducing the problem by turning on VO and it instantly spinning-rainbow-cursor-locks SourceTree every time.

      Call graph:
          1970 Thread_1858437   DispatchQueue_1: com.apple.main-thread  (serial)
          + 1970 ???  (in SourceTree)  load address 0x100000000 + 0x1f34  [0x100001f34]
          +   1970 NSApplicationMain  (in AppKit) + 940  [0x7fff89a96803]
          +     1970 -[NSApplication run]  (in AppKit) + 553  [0x7fff89aab9cc]
          +       1970 -[NSApplication nextEventMatchingMask:untilDate:inMode:dequeue:]  (in AppKit) + 122  [0x7fff89ab78db]
          +         1970 _DPSNextEvent  (in AppKit) + 1434  [0x7fff89ab828e]
          +           1970 _BlockUntilNextEventMatchingListInModeWithFilter  (in HIToolbox) + 65  [0x7fff8fd6eabc]
          +             1970 ReceiveNextEventCommon  (in HIToolbox) + 479  [0x7fff8fd6ecb7]
          +               1970 RunCurrentEventLoopInMode  (in HIToolbox) + 226  [0x7fff8fd6ef0d]
          +                 1970 CFRunLoopRunSpecific  (in CoreFoundation) + 309  [0x7fff84f16275]
          +                   1970 __CFRunLoopRun  (in CoreFoundation) + 1830  [0x7fff84f16bd6]
          +                     1970 __CFRunLoopDoSource1  (in CoreFoundation) + 478  [0x7fff84f25ade]
          +                       1970 __CFRUNLOOP_IS_CALLING_OUT_TO_A_SOURCE1_PERFORM_FUNCTION__  (in CoreFoundation) + 41  [0x7fff84f25b69]
          +                         1970 mshMIGPerform  (in HIServices) + 211  [0x7fff8d9af168]
          +                           1970 _XSetAttributeValue  (in HIServices) + 573  [0x7fff8d9cfdfe]
          +                             1970 _AXXMIGSetAttributeValue  (in HIServices) + 306  [0x7fff8d9c6d4d]
          +                               1970 -[AXBBundleManager loadAXBundles]  (in AccessibilityBundles) + 50  [0x10b7ea2c7]
          +                                 1970 -[AXBBundleManager loadAXBundleForBundle:]  (in AccessibilityBundles) + 82  [0x10b7ea273]
          +                                   1970 -[AXBBundleManager _processesBundlesToLoad:]  (in AccessibilityBundles) + 276  [0x10b7ea184]
          +                                     1970 -[AXBBundleManager _subBundlesForBundle:]  (in AccessibilityBundles) + 103  [0x10b7e9b53]
          +                                       1970 +[NSBundle allFrameworks]  (in Foundation) + 1024  [0x7fff8d71afc5]
          +                                         1970 objc_collect  (in libobjc.A.dylib) + 482  [0x7fff8c96ddbe]
          +                                           1970 auto_zone_collect  (in libauto.dylib) + 393  [0x7fff89454f29]
          +                                             1970 Auto::ThreadLocalCollector::collect(bool)  (in libauto.dylib) + 289  [0x7fff8947df51]
          +                                               1970 Auto::ThreadLocalCollector::process_local_garbage(void (*)(Auto::ThreadLocalCollector*))  (in libauto.dylib) + 427  [0x7fff8947d76b]
          +                                                 1970 Auto::ThreadLocalCollector::finalize_local_garbage_now(Auto::ThreadLocalCollector*)  (in libauto.dylib) + 132  [0x7fff8947d8e4]
          +                                                   1970 Auto::Zone::invalidate_garbage(unsigned long, void**)  (in libauto.dylib) + 73  [0x7fff8946c179]
          +                                                     1970 batchFinalize(_malloc_zone_t*, void (*)(auto_zone_cursor*, void (*)(void*, void*), void*), auto_zone_cursor*, unsigned long, void (*)(void*, void*))  (in libobjc.A.dylib) + 51  [0x7fff8c96eeca]
          +                                                       1970 Auto::foreach_block_do(auto_zone_cursor*, void (*)(void*, void*), void*)  (in libauto.dylib) + 41  [0x7fff8946c1a9]
          +                                                         1970 finalizeOneObject(void*, void*)  (in libobjc.A.dylib) + 50  [0x7fff8c96ef8a]
          +                                                           1970 -[NSBundle finalize]  (in Foundation) + 285  [0x7fff8d71a1fc]
          +                                                             1952 _OSSpinLockLockSlow  (in libsystem_platform.dylib) + 63  [0x7fff8851edf6]
          +                                                             ! 1952 syscall_thread_switch  (in libsystem_kernel.dylib) + 10  [0x7fff838c7b16]
          +                                                             18 _OSSpinLockLockSlow  (in libsystem_platform.dylib) + 77,81,...  [0x7fff8851ee04,0x7fff8851ee08,...]
      

            [SRCTREE-1983] SourceTree locks up ("spinning rainbow cursor") when VoiceOver is on

            KieranA added a comment -

            Hey Bobby,

            Yes I've just been testing this and it locks up the moment an NSTask instance is executed which is very strange. I'd also suggest this is an Apple bug as I can't dig inside of that, and there's no environmental reason otherwise that this shouldn't work.

            We've got a link to that rdar anyway, so once there's some change in that we can address the issue in SourceTree.

            Cheers

            KieranA added a comment - Hey Bobby, Yes I've just been testing this and it locks up the moment an NSTask instance is executed which is very strange. I'd also suggest this is an Apple bug as I can't dig inside of that, and there's no environmental reason otherwise that this shouldn't work. We've got a link to that rdar anyway, so once there's some change in that we can address the issue in SourceTree. Cheers

            KieranA added a comment -

            Thanks for the information, I've confirmed this too so we should definitely get on it.

            Cheers

            KieranA added a comment - Thanks for the information, I've confirmed this too so we should definitely get on it. Cheers

            I think this might actually be an Apple bug. I'm seeing similar behavior from TaskPaper (another app I use a lot). Maybe it happens to every app that uses garbage collection? (I noticed from the stack trace that's what its doing when its locked up there - processing garbage.)

            I reported this to Apple as well in Radar - its reported as rdar://15630500

            Bobby Thomale added a comment - I think this might actually be an Apple bug. I'm seeing similar behavior from TaskPaper (another app I use a lot). Maybe it happens to every app that uses garbage collection? (I noticed from the stack trace that's what its doing when its locked up there - processing garbage.) I reported this to Apple as well in Radar - its reported as rdar://15630500

              Unassigned Unassigned
              b6dea53240c1 Bobby Thomale
              Affected customers:
              0 This affects my team
              Watchers:
              3 Start watching this issue

                Created:
                Updated: