#3693: Show stack traces -------------------------------------+------------------------------------ Reporter: jpet | Owner: Tarrasch Type: feature request | Status: new Priority: normal | Milestone: 7.10.1 Component: Runtime System | Version: 6.10.4 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Unknown/Multiple Type of failure: None/Unknown | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: -------------------------------------+------------------------------------ Comment (by blitzcode): This is all quite tricky since there seem to be so many different approaches to consider! ;-) For profiling, I am mostly coming at this problem from the perspective of already having an external tool that works for C/C++ and wanting to add Haskell support to it (it's a sampling profiler, pausing threads and capturing their stack, as you already said). I think you make a very valid point about already having all the functionality in the RTS (eventually). I don't have any technical / ideological reason to prefer an external profiler, what I'm after is seeing profiling data in realtime, while the program is running. If the RTS is collecting profiling data it could either provide some kind of IPC API to have an external tool collect it, or maybe just have a Haskell API so one could use a library like EKG to show it to the user. I couldn't really figure out how the Haskell to C stack transition works, but I think that's a less common case than the Haskell to C one anyway. Glad to hear that the latter seems to be working! I don't agree that having an external program do a stack walk is necessarily complicated or awkward. With your DWARF3 work, one should be able to use something like libunwind-ptrace (http://www.nongnu.org/libunwind/man/libunwind-ptrace%283%29.html) and have that functionality available without any custom work. For debugging, I think there's merit for an external tool. For RTS exceptions we're ok, but as soon as we have an actual segfault, some memory corruption has often already taken place. Any kind of stack traversal, symbol lookup and error reporting code will have a decent chance of failing itself due to a corrupted heap or such. The only library that I can think of would be libunwind. It's supported on Linux/BSD, Apple ships some kind of version of it on OS X (there are some limitations / issues with their port, IIRC), does DWARF2/3. It's not on Windows, but there's build-in support for stack walking through the DbgHelp library (StackWalk64, no idea if Windows PDB debug information supports the kind of wizardry your using to explain the STG stack to a DWARF3 debugger, though). It seems generating the right kind of debug symbols, and supporting and doing stack walking for Haskell & C/C++ on all three platforms is a major challenge... -- Ticket URL: http://ghc.haskell.org/trac/ghc/ticket/3693#comment:57 GHC http://www.haskell.org/ghc/ The Glasgow Haskell Compiler