-
Bug
-
Resolution: Unresolved
-
High
-
None
-
1.7.4.1
-
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
Workflow | Original: JAC Bug Workflow v3 [ 3368877 ] | New: SRCTREE JAC Bug Workflow [ 3735277 ] |
Workflow | Original: SourceTree Bug Workflow [ 588949 ] | New: JAC Bug Workflow v3 [ 3368877 ] |
Status | Original: Open [ 1 ] | New: Needs Triage [ 10030 ] |
Fix Version/s | Original: 2.0.0 [ 30990 ] | |
Symptom Severity | Original: Major [ 14431 ] | New: Critical [ 14430 ] |
Assignee | Original: KieranA [ ksenior ] | |
Priority | Original: Medium [ 3 ] | New: High [ 2 ] |
Symptom Severity | New: Major [ 14431 ] |
Fix Version/s | New: 2.0.0 [ 30990 ] | |
Fix Version/s | Original: 1.8.2 [ 38511 ] |
Rank | New: Ranked higher |
Fix Version/s | New: 1.8.2 [ 38511 ] | |
Fix Version/s | Original: 1.8.1 [ 37909 ] |
Description |
Original:
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,...] |
New:
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. {noformat} 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,...] {noformat} |
Rank | New: Ranked higher |
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