Hi Kazu, This sounds like something you could investigate with ghc-debug. Once the mvar blocks you can look at the stack using ghc-debug-brick which should be enlightening. Matt On Wed, 20 Nov 2024, 01:17 Kazu Yamamoto (山本和彦) via ghc-devs, < ghc-devs@haskell.org> wrote:
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?
Background: https://github.com/haskell/network/issues/590
--Kazu
_______________________________________________ ghc-devs mailing list ghc-devs@haskell.org http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs