#3693: Show stack traces
------------------------------+---------------------------------------------
Reporter: jpet | Owner:
Type: feature request | Status: new
Priority: normal | Milestone: _|_
Component: Runtime System | Version: 6.10.4
Resolution: | Keywords:
Difficulty: | Os: Unknown/Multiple
Testcase: | Architecture: Unknown/Multiple
Failure: None/Unknown |
------------------------------+---------------------------------------------
Comment (by simonmar):
Ok, let's explore what could be done. In gdb you can see the stack like
this:
{{{
(gdb) p16 $rbp
0x2b265a880368: 0x2b265a87f2c0
0x2b265a880360: 0x748d08 <stg_marked_upd_frame_info>
0x2b265a880358: 0x459090 <smN_info>
0x2b265a880350: 0x6aafd0 <s1VW_info>
0x2b265a880348: 0x2b265a87f2d1
0x2b265a880340: 0x58afc0 <s1Ed_info>
0x2b265a880338: 0x2b265a87f2d1
0x2b265a880330: 0xb6757b <base_GHCziStorable_readInt8OffPtr1_closure+3>
0x2b265a880328: 0xaf04d8 <base_GHCziInt_zdfEqInt8_closure>
0x2b265a880320: 0xb22c39 <r1wc_closure+1>
0x2b265a880318: 0x2b265a87f328
0x2b265a880310: 0x59dc60 <s11L_info>
0x2b265a880308: 0x2b2655c4dc18
0x2b265a880300: 0x6abf38 <sOz_info>
0x2b265a8802f8: 0x2b265a87f328
0x2b265a8802f0: 0x748b88 <stg_upd_frame_info>
}}}
In the RTS there's also a way to print out stacks, though I don't use it
very much. Note this is upside-down compared to the above dump:
{{{
(gdb) p printStackChunk( 0x2b265a8802f0,0x2b265a880368)
Object 0x2b265a8802f0 = UPDATE_FRAME(0x748b88,0x2b265a87f328)
RET_SMALL (0x6abf28)
stk[12] (0x2b265a880308) = Word# 47443647716376
RET_SMALL (0x59dc50)
stk[10] (0x2b265a880318) = 0x2b265a87f328
stk[9] (0x2b265a880320) = 0xb22c39
stk[8] (0x2b265a880328) = 0xaf04d8
stk[7] (0x2b265a880330) = 0xb6757b
stk[6] (0x2b265a880338) = 0x2b265a87f2d1
RET_SMALL (0x58afb0)
stk[4] (0x2b265a880348) = 0x2b265a87f2d1
RET_SMALL (0x6aafc0)
RET_SMALL (0x459080)
Object 0x2b265a880360 = UPDATE_FRAME(0x748d08,0x2b265a87f2c0)
}}}
You get less information in that there are no symbol names: the RTS
doesn't have access to the binary's symbol table. That information is
available in the binary, and it might be possible to extract it using the
RTS linker (speculation - I don't know how hard this would be in
practice). On the other hand, the RTS knows where the boundaries between
stack frames are, and it can recognise an UPDATE_FRAME etc.
But even with symbol names, you couldn't glean a lot from the trace here.
What might help is if we knew which module each of those symbols comes
from, but that info isn't available, even in the symbol table. We could
add the module name to every symbol, but that would make local symbols
much bigger. Perhaps that doesn't matter as these are only local symbols
and so symbol lookup isn't actually performed at link time, it just makes
the strings bigger in the object files. Someone could do that experiment.
Maybe the right thing would be to add some debugging info to the compiled
code that doesn't take up any space at runtime, but which the RTS could
slurp in if necessary.
--
Ticket URL: <http://hackage.haskell.org/trac/ghc/ticket/3693#comment:7>
GHC <http://www.haskell.org/ghc/>
The Glasgow Haskell Compiler_______________________________________________
Glasgow-haskell-bugs mailing list
[email protected]
http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs
