Under what situations can a thread using `runBlocking` remai

Question

Under what situations can a thread using `runBlocking` remain parked even though the underlying coroutines are no longer running

Zach Klippenstein (he/him) [MOD] · Answer

It shouldn t block if all the coroutines are finished Are you sure they all are You can attach a debugger wait for it to hang and then pause the threads and you should be able to peek into the runBlocking s context to see if any child jobs are hanging around

rocketraman · Answer

Unfortunately this happened in prod and so far I can t reproduce it locally with a debugger running

rocketraman · Answer

I see no threads doing the coroutine processing I would expect despite multiple thread dumps over several minutes

Zach Klippenstein (he/him) [MOD] · Answer

Maybe a bug then Might be nice to have some more ways to introspect the coroutine event loops and job hierarchies stuff for troubleshooting these cases e g like JMX integration Anyway I m out of ideas disappointed

rocketraman · Answer

Indeed I wonder if someone has written any btrace scripts or something that might be useful to provide some runtime introspection

rocketraman · Answer

The problem seems to happen consistently in production so I was able to attach a debugger I m not quite certain what I m looking for though

rocketraman · Answer

I see ` state` of the context has a `child` with `isCompleted=false` but now what

Zach Klippenstein (he/him) [MOD] · Answer

This requires a code change but you could give all your coroutines explicit `CoroutineName`s which would help you identify them in the debugger

rocketraman · Answer

Turns out the problem was a suspended call to an unresponsive remote service As everything was suspended ~it looked like~ nothing was happening in the thread dumps

gildor · Answer

Yeah it s expected you should see no threads that do coroutines dispatching if coroutine is just suspended You can use debug agents to get all running coroutines <https github com Kotlin kotlinx coroutines blob master kotlinx coroutines debug README md>

rocketraman · Answer

Unfortunately the debug agents still come with the do not use this module in production warning

rocketraman · Answer

What I d really love is some type of interrupt based printing of all active coroutines exactly analogous to `kill 3` for thread dumps Heck even something I can trigger via a JMX operation would be great

gildor · Answer

I would create an issue with your use case on kotlinx coriutines issue tracker

Vsevolod Tolstopyatov [JB] · Answer

Please file an issue with your use case for JMX and maybe for production use as well Btw we have `kill 5` if agent is attached using ` javaagent` <https github com Kotlin kotlinx coroutines blob master kotlinx coroutines debug src AgentPremain kt L12> Probably we can expose it in public explicitly as well

rocketraman · Answer

Nice about `kill 5` Created <https youtrack jetbrains com issue KT 32953>

gildor · Answer

I think you should create this issue on kotlinx coroutines GitHub instead