[GHC] #3693: Show stack traces

[GHC]

#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