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
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
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
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
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
participants (3)
-
Edward Z. Yang -
Simon Marlow -
Tyson Whitehead