Under what situations can a thread using `runBlock...
# coroutines
r
Under what situations can a thread using
runBlocking
remain parked, even though the underlying coroutines are no longer running?
z
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.
r
Unfortunately this happened in prod, and so far I can't reproduce it locally with a debugger running.
I see no threads doing the coroutine processing I would expect, despite multiple thread dumps over several minutes.
z
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 😞
r
Indeed. I wonder if someone has written any btrace scripts or something that might be useful to provide some runtime introspection.
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.
I see
_state
of the context has a
child
with
isCompleted=false
, but now what?
z
This requires a code change, but you could give all your coroutines explicit `CoroutineName`s, which would help you identify them in the debugger.
r
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...
👍 1
g
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
r
Unfortunately the debug agents still come with the "do not use this module in production" warning...
g
I would create an issue with your use case on kotlinx.coriutines issue tracker
v
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
r
g
I think you should create this issue on kotlinx.coroutines GitHub instead