Re: Tracing idea
Thinking about this in more detail, I think this facility would be most useful if it also contained information about what module/file the code came from. I'm currently attempting to track down a bug in the code generator which I know is due to a miscompiled library, and it would make my life substantially easier if there was an easy way to narrow down possible crash sites. I suppose one method already available to me is to get a list of suspicious identifiers and then cross reference these against the generated object files. Edward Excerpts from Simon Marlow's message of Tue Mar 01 05:46:01 -0500 2011: > On 21/02/2011 01:08, Edward Z. Yang wrote: > > Excerpts from Tyson Whitehead's message of Sun Feb 20 07:14:56 -0500 2011: > >> I believe a back trace on the actual call stack is generally considered not > >> that useful in a lazy language as it corresponds to the evaluation > >> sequence, > >> That is, it is demand centric while written code is production centric > > > > Yeah, such a buffer wouldn't be very useful for end-users; I'm thinking more > > in terms of going "backwards in time" for the STG execution. > > Yes, that might be useful. However it would require compiling all the > libraries with that option too - so it would be an internal debug option > for use with a live GHC build, not something you could use with a > pre-built GHC (well, you could use it, but you wouldn't get traces for > library code). > > Cheers, > Simon ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: Tracing idea
On 21/02/2011 01:08, Edward Z. Yang wrote: Excerpts from Tyson Whitehead's message of Sun Feb 20 07:14:56 -0500 2011: I believe a back trace on the actual call stack is generally considered not that useful in a lazy language as it corresponds to the evaluation sequence, That is, it is demand centric while written code is production centric Yeah, such a buffer wouldn't be very useful for end-users; I'm thinking more in terms of going "backwards in time" for the STG execution. Yes, that might be useful. However it would require compiling all the libraries with that option too - so it would be an internal debug option for use with a live GHC build, not something you could use with a pre-built GHC (well, you could use it, but you wouldn't get traces for library code). Cheers, Simon ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: Tracing idea
Excerpts from Tyson Whitehead's message of Sun Feb 20 07:14:56 -0500 2011: > I believe a back trace on the actual call stack is generally considered not > that useful in a lazy language as it corresponds to the evaluation sequence, > That is, it is demand centric while written code is production centric Yeah, such a buffer wouldn't be very useful for end-users; I'm thinking more in terms of going "backwards in time" for the STG execution. Cheers, Edward ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: Tracing idea
On February 19, 2011 12:11:13 Edward Z. Yang wrote: > I was thinking it might be useful if we had a per-thread circular buffer in > memory for which we pushed a pointer to the info table we had just entered. > In the event of a crash, you could dump the contents of the buffer to see > what code had been recently executed. To reduce overhead, one might only > need to record this information when we do a tail call, and not when the > path can be reconstructed from the stack. (Obviously, you'd need to > compile in debug mode, and you'd probably want to also add an RTS flag). > > What do people think? I believe a back trace on the actual call stack is generally considered not that useful in a lazy language as it corresponds to the evaluation sequence, That is, it is demand centric while written code is production centric http://hackage.haskell.org/trac/ghc/wiki/Debugging/CompiledCode Here's a link that summarizes some thoughts on production centric back traces http://hackage.haskell.org/trac/ghc/wiki/ExplicitCallStack Cheers! -Tyson signature.asc Description: This is a digitally signed message part. ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Tracing idea
I was thinking it might be useful if we had a per-thread circular buffer in memory for which we pushed a pointer to the info table we had just entered. In the event of a crash, you could dump the contents of the buffer to see what code had been recently executed. To reduce overhead, one might only need to record this information when we do a tail call, and not when the path can be reconstructed from the stack. (Obviously, you'd need to compile in debug mode, and you'd probably want to also add an RTS flag). What do people think? Cheers, Edward ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
