Application Hang issue

Developer Tools & Services General
MacDelta OP
Created Jan ’21
Replies 10
Boosts 0
Views 2.5k
Participants 3
The application is getting hung on startup, I could manage to get the system spindump. I see two threads of the application in waiting state, please refer the following call stack extract from the spin dump,

thread 0x1f44ee(main thread)
2  CFRunLoopObserverInvalidate + 277 (CoreFoundation + 528065) [0x7fff2041dec1]
                   1  -[_NSArrayM dealloc] + 309 (CoreFoundation + 140978) [0x7fff203bf6b2]
                    1  freetiny + 134 (libsystemmalloc.dylib + 24773) [0x7fff201510c5]
                     1  ulockwait + 10 (libsystemkernel.dylib + 9678) [0x7fff202f35ce]
                      *1  ??? (kernel + 6750000) [0xffffff800087ff30] (blocked by turnstile waiting for CUI [28858] [unique pid 128518] thread 0x1f456b)
                  

thread 0x1f456b
 1  -[SBPropertyThunk initWithElement:inDocument:] + 314 (ScriptingBridge + 62301) [0x7fff5379d35d]
              1  squish3 + 588 (ScriptingBridge + 68213) [0x7fff5379ea75]
               1  +[NSString stringWithUTF8String:] + 68 (Foundation + 150974) [0x7fff2116bdbe]
                1  CFStringCreateWithBytes + 27 (CoreFoundation + 64294) [0x7fff203acb26]
                 1  CFStringCreateImmutableFunnel3 + 2126 (CoreFoundation + 14583) [0x7fff203a08f7]
                  1  CFRuntimeCreateInstance + 293 (CoreFoundation + 16753) [0x7fff203a1171]
                   1  malloczonecalloc + 59 (libsystemmalloc.dylib + 114359) [0x7fff20166eb7]
                    1  szonemallocshouldclear + 66 (libsystemmalloc.dylib + 10131) [0x7fff2014d793]
                     1  tinymallocshouldclear + 142 (libsystemmalloc.dylib + 14363) [0x7fff2014e81b]
                      1  _ulockwait + 10 (libsystem_kernel.dylib + 9678) [0x7fff202f35ce]
                       *1  ??? (kernel + 6750000) [0xffffff800087ff30] (blocked by turnstile waiting for CUI [28858] [unique pid 128518] thread 0x1f44ee)

I am not sure but suspecting that it might be causing that hang issue
Replies  10
Boosts  0
Views  2.5k
Participants  3
DTS Engineer OP
Apple
Jan ’21
This is an app that you’re developing, right?

If so, please post the full spindump. Use the text attachment feature (the paperclip icon) to avoid clogging up the timeline.

Share and Enjoy
—
Quinn “The Eskimo!” @ Developer Technical Support @ Apple
let myEmail = "eskimo" + "1" + "@apple.com"
0
MacDelta OP
Jan ’21
Yes, this is an app.
The spindump is large in size, not able to attach here as a text.
Any other option that you think would be feasible for sharing that spindump file.
0
DTS Engineer OP
Apple
Jan ’21

Any other option that you think would be feasible for sharing that
spindump file.

You can put it on a file sharing service and post the URL (DevForums will block the URL as written but you can get around that by removing the leading https://).

Share and Enjoy
—
Quinn “The Eskimo!” @ Developer Technical Support @ Apple
let myEmail = "eskimo" + "1" + "@apple.com"
0
MacDelta OP
Jan ’21
Here the link, ent.box.com/s/9xsh1ij91p1ogx6tjw1topozoq7wul0t
Please let me know if you face any problem accessing this.
0
DTS Engineer OP
Apple
Jan ’21

Here the link

Thanks.

The backtraces you referenced in your original post — those leading to __ulock_wait — are not relevant here. When you look at a spin dump you need to pay attention to the numbers at the side. In the backtraces you referenced, those numbers are all 1, indicating that, of the 929 samples taken by the spin dump, only 1 was found in that location.

To read a spin dump you need to start at the top and see where those numbers start to diverge. Consider this snippet from your main thread:

Code Block  
 929 start + 1 …
  929 ??? …
   929 ??? …
    929 wxApp::OnRun() + 26 …
     929 wxAppConsoleBase::MainLoop() + 99 …
      929 wxEventLoopBase::Run() + 158 …
       929 wxCFEventLoop::DoRun() + 44 …
        929 wxGUIEventLoop::OSXDoRun() + 174 …
         929 -[NSApplication run] + 586 …
          929 -[NSApplication(NSEvent) _nextEventMatchingEventMask: …
           929 _DPSNextEvent + 883 …
            929 _BlockUntilNextEventMatchingListInModeWithFilter + 64 …
             929 ReceiveNextEventCommon + 709 …
              929 RunCurrentEventLoopInMode + 292 …
               929 CFRunLoopRunSpecific + 563 …
                727 CFRunLoopRun + 1315 …
                 727 CFRunLoopServiceMachPort + 316 …
                  727 mach_msg_trap + 10 …
                   *727 ipc_mqueue_receive_continue + 0 …


As you can see, all of the samples have a backtrace starting:

Code Block  
start + 1 …
??? …
??? …
wxApp::OnRun() + 26 …
wxAppConsoleBase::MainLoop() + 99 …
wxEventLoopBase::Run() + 158 …
wxCFEventLoop::DoRun() + 44 …
wxGUIEventLoop::OSXDoRun() + 174 …
-[NSApplication run] + 586 …
-[NSApplication(NSEvent) _nextEventMatchingEventMask: …
_DPSNextEvent + 883 …
_BlockUntilNextEventMatchingListInModeWithFilter + 64 …
ReceiveNextEventCommon + 709 …
RunCurrentEventLoopInMode + 292 …
CFRunLoopRunSpecific + 563 …


which simply indicates that your app is running its main event loop. The backtrace from there yields more useful info. Of the 929 samples, 727 continue the backtrace like so:

Code Block  
CFRunLoopRun + 1315 …
CFRunLoopServiceMachPort + 316 …
mach_msg_trap + 10 …
ipc_mqueue_receive_continue + 0 …
_


This backtrace indicates that the app is blocked waiting for events. So, for the vast bulk of the time covered by this spin dump (727 of 929 samples) the main thread was idle waiting for events. This suggests that the problem isn’t a normal hang — where the main thread is getting stuck on, for example, a blocking network call — but something else entirely. It’s possible that your UI framework is getting confused about what event sources it’s supposed to be monitoring.


How reproducible is this?

Share and Enjoy
—
Quinn “The Eskimo!” @ Developer Technical Support @ Apple
let myEmail = "eskimo" + "1" + "@apple.com"
0
MacDelta OP
Jan ’21
Thanks for helping out here
I see some memory leaks in the app causing continuous memory growth, and at some point app's private memory allocations are in GBs .
0
DTS Engineer OP
Apple
Jan ’21

at some point app's private memory allocations are in GBs.

Well, that’s worth fixing regardless of whether it’s involved in this issue or not.

Share and Enjoy
—
Quinn “The Eskimo!” @ Developer Technical Support @ Apple
let myEmail = "eskimo" + "1" + "@apple.com"
0
MacDelta OP
Jan ’21
Do you have any documentation for analysing spindump? That would really be helpful if run into any hang issue.
0
DTS Engineer OP
Apple
Jan ’21

Do you have any documentation for analysing spindump?

No. Such documentation isn’t easy to write because:

  • On the surface, spin dumps are very simple: There are N samples and you get a tree showing the backtraces of those samples with frequency counts.

  • At a deeper level, you generally get stuck somewhere in OS code and you need to have a good understanding of how the various OS bits fit together in order to come back with anything useful.

In your specific case the spin dump makes it clear that your app isn’t blocked in the traditional sense but rather suffering from some sort of livelock with its UI.

Share and Enjoy
—
Quinn “The Eskimo!” @ Developer Technical Support @ Apple
let myEmail = "eskimo" + "1" + "@apple.com"
0
Boaz F. OP
May ’23

For me, this was happening when I run tests. Eventually after looking at the spin dump I discovered some issue with one of the pods I was using (With Cocoapods) removing that pod solved the issue

1
Application Hang issue
First post date Last post date
 
 
Q