Make it easier to debug why threads are blocked on blackholes
Recently we have been debugging a hanging program where we could observe using ghc-debug that the thread in question was blocked on a blackhole but after that we were stuck because there was no way to work out which thunk this blackhole came from was.
The proposal is to introduce a new debugging flag which when a update frame is added to the stack, also adds a frame (of a new type) which has one data argument, and records the info table of the thunk which the blackhole update closure above it.
This scheme allows us to optionally emit this frames without having to compile a different RTS way.
This information is very useful for debugging tools like ghc-debug as then it becomes quite trivial to look up the source location of the THUNK
closure from its info table if you have IPE information enabled.
Ben has prepared an mr !10271 (closed) to implement this idea, and I have used it to diagnose the hanging thread for our client.