"Kazu Yamamoto \(山本和彦\) via ghc-devs" writes:

Hello,

I'm seeking of the source of the bug that my server based on Warp gets not-responding. "listThreads" shows that IOManager is blocked on a MVar permanently:

2 IOManager on cap 0: ThreadBlocked BlockedOnForeignCall 3 IOManager on cap 1: ThreadBlocked BlockedOnMVar 4 TimerManager: ThreadBlocked BlockedOnForeignCall

IOManager should have the BlockedOnForeignCall reason since it's calling epoll_wait().

It's quit hard to debug this bug since I don't understand which MVar blocks IOManager of 3. Users can register MVar operations to IOManager while IOManager itself is using MVars internally.

To make this kind of debugging easier, I would like ask GHC developers to extend MVar to hold its label and provide "labelMVar" like "labelThread". The same mechanism should be provided for STM as well. "BlockReason" should contain the target label.

What do you think?

This is generally in the direction I proposed in #21877; I agree that it would be quite useful. I don't think that we necessarily want to extend all MVars with labels as this would impose a fixed memory cost on all users. However, I think the approach that I describe in the ticket, introducing an out-of-band map for labelling heap objects, would be a reasonable way forward. As Matt suggests, ghc-debug is also a great tool for investigating issues like this. However, I still think there is value in having better support in the core libraries for understanding issues such as this. Thoughts? Cheers, - Ben