[Haskell-cafe] RE: Examining the Haskell stack (read at your own risk ; -))

[Simon Marlow]

On 02 December 2005 14:17, Joel Reymont wrote:

> On Dec 2, 2005, at 2:08 PM, Simon Marlow wrote:
> 
>> It looks like your crash happened in the SSL library, and you have a
>> useful stack trace there.
> 
> This is contrived in that I already know where the error is and it
> clearly points to SSL_free. I'm trying to figure out how I would have
> gotten to that call to getHostByName.
> 
>> r22 is a pointer to the stack, not a pointer to code, so you can't
>> disassemble it, you need to display memory (as I described in
>> separate mail).
> 
> Quoting you:
> 
> ---
>    gdb> p16 $r22
> 
> which prints 16 words of memory backwards (the way I like it) starting
> at the addresss in $r22.  when displaying memory this way, gdb very
> handily prints the symbol name for words that point into the program.
> You can then pick things off the stack that look like return addresses
> and disassemble them, if you want.
> ---
> 
> And p16 is defined in .gdbinit as:
> 
> define p16
> pmem $arg0 16
> end
> 
> Printing the 16 words gives me the printout below but where do I find
> my Haskell function? The code tha causes the crash looks like this:
> 
> maybeFreeSSL :: MaybeSSL -> IO ()
> maybeFreeSSL tmv =
>      do putStrLn $ "maybeFreeSSL invoked"
>         mssl <- atomically $ swapTMVar tmv Nothing
>         case mssl of
>           Nothing -> return ()
>           Just (ssl, _, _) -> do sslFree ssl
>                                  sslFree ssl
> 
> Is there a way to have maybeFreeSSL in the trace? I compiled the app
> with -debug but the libraries and the above maybeFreeSSL code was
> compiled without it.
> 
> 	Thanks, Joel
> 
> P.S.
> 
> Program received signal EXC_BAD_ACCESS, Could not access memory.
> Reason: KERN_PROTECTION_FAILURE at address: 0x00000019
> 0x00568fe0 in sk_pop_free ()
> (gdb) p16 $r22
> 0x137a40c:      0x1ce63c <stg_NO_TREC_closure>
> 0x137a408:      0x0
> 0x137a404:      0x0
> 0x137a400:      0x18fd0 <stg_TREC_HEADER_info>
> 0x137a3fc:      0xd6dbc <stg_stop_thread_info>
> 0x137a3f8:      0xd6f38 <stg_noforceIO_info>
> 0x137a3f4:      0x13ef148
> 0x137a3f0:      0x0
> 0x137a3ec:      0x2605c <stg_catch_frame_info>
> 0x137a3e8:      0x25c80 <stg_unblockAsyncExceptionszh_ret_info>
> 0x137a3e4:      0x13ef150
> 0x137a3e0:      0x27030 <s3BN_info>
> 0x137a3dc:      0x1d22cc <GHCziConc_lvl7_closure>
> 0x137a3d8:      0x26f6c <s3BK_info>
> 0x137a3d4:      0x13f38f4
> 0x137a3d0:      0x243f4 <s7Fy_info>
> 0x137a3cc:      0xc3270 <s7FI_info>

Ok, you want a crash course in reading the Haskell stack.

Each xxx_info symbol is a return address.  The other values are the
contents of stack frames: values saved for use at the return address.

A return address also has an associated info table (use pinfo in the
.gdbinit I sent you for disaplying the info table, eg. pinfo s7FI_info).
Understanding info tables is beyond the scope of this message; please
see InfoTables.h in the GHC sources.

You probably want to know what each return address corresponds to:

  - the ones beginning "stg_" are in the runtime, you can see the code
for
    these in the GHC sources (grep in ghc/rts).

  - the ones that look like "s7FI_info" are local symbols.  You might be
    able to find which module it comes from by grepping the .o files in
    your program and the .a library files.  If you find it in a library,
    you can use 'nm' on the library to get a better idea of what
function
    the symbol is associated with.

    One problem is that because these are local symbols, you might find
    the same symbol in multiple places, and you have to make an educated
    guess as to which is the appropriate one (or use the disassembly to
    distinguish).

    To map this back to Haskell code, you need to recompile the original
    module and dump the intermediate code with -ddump-stg.
Understanding
    the output of -ddump-stg is beyond the scope of this message :-)

Cheers,
	Simon