Evan Klitzke writes:

[...] Unfortunately, this doesn't seem to work; whenever the program terminates due to running out of heap space, the generated .prof file is empty.

Unless there's some specific problem with profiling in combination with threading, you can get heap profiling from a crashing program. Not what you wanted, but you might at least be able to see what is allocated. Previously, you'd have to edit the profiling output (.hp file) by hand to chop off the last and partial profiling record, but I think this might have been fixed in later GHC's. -k -- If I haven't seen further, it is by standing in the footprints of giants

I've written a multi-threaded Haskell program that I'm trying to debug. Basically what's happening is the program runs for a while, and then at some point one of the threads goes crazy and spins the CPU while allocating memory; this proceeds until the system runs out of available memory. I can't fix this without figuring out what code is being executed in the loop (or at least which thread is misbehaving, which would narrow things down a lot). .. Does anyone have any tips for dealing this? Have other people run into similar problems? I'm out of ideas, so I'm open to any suggestions.

Don't know whether this still works, but there was a Concurrent Haskell Debugger here: http://www.informatik.uni-kiel.de/~fhu/chd/ The idea being that you put an indirection module between your code and the Concurrent Haskell imports, and then instrument the indirections to give you more information (they had built more tools on top of that idea). In a similar direction, I once suggested a shell-jobs-like thread interface for GHCi, in the context of this _|_-ed ticket: http://hackage.haskell.org/trac/ghc/ticket/1399#comment:3 Claus