Understanding System Trace's Main Thread 'Blocked'

We've lots and lots going on at startup, but in particular we've some items which can for a very short period of time block the main thread, causing a UITableView stutter on scroll.


https://imgur.com/a/RWDvFJz


Using the 'System Trace' tool, we can clearly see on the Main Thread some 'blocked' states. However, I'm finding it difficult to pinpoint down in code where this happens.


If I find the 'mach_msg_trap' associated with a particular blocking item, the Stack on the right has a basic stack (see: https://imgur.com/a/tNnXQvh), but double clicking on main brings a function which couldn't possibly be the cause of a blocker (as it's a ViewModel which in this case doesn't get initialized in this flow).


Is it possible to fixture out, even what thread is blocking, so I can find that thread at the time, and look at it's call stack?

Up vote post of cillianok Down vote post of cillianok
6.5k views
Posted by
cillianok
Reply
Add a Comment

Replies

The backtrace says the main thread is waiting in the run loop. In other words, it's waiting for user input, a timer, a socket, or some other run loop source to fire. There is currently no way to know which run loops sources are active, like a list of timers or sockets.

Posted by
cwoolf
Up vote reply of cwoolf Down vote reply of cwoolf
Add a Comment

Waiting for user input? So, it's normal then? I found out about this same issue. Couldn't understand what it means by saying the main thread is "blocked", because my application runs fine. And "blocked" will show when I am actually not scrolling or tapping anything in my application. https://stackoverflow.com/questions/73616263/main-thread-showing-blocked-from-instrument-by-mach-msg-trap

Posted by
jiangwang
Up vote reply of jiangwang Down vote reply of jiangwang
Add a Comment