#3693: Show stack traces
---------------------------------+------------------------------------------
Reporter: jpet | Owner:
Type: feature request | Status: new
Priority: normal | Milestone: 6.14.1
Component: Runtime System | Version: 6.10.4
Keywords: | Difficulty:
Os: Unknown/Multiple | Testcase:
Architecture: Unknown/Multiple | Failure: None/Unknown
Patch: 1 |
---------------------------------+------------------------------------------
Comment(by batterseapower):
Thomas Schilling talked to me about the API I have at the moment. It's
quite specialised in that you can only get a list of return frame
descriptions, and makes the RTS do a comparatively large amount of work.
I've based this possible new API on his ideas. The idea is to move much
more responsibility into the Haskell side of things, and hence allow for
more interesting stack trace processors to be written. For example, you
could write one which let the user interactively poke at the closures
within the stack from using Vacuum or something.
{{{
catchWeird :: a -> (forall b. SomeException -> Addr# -> IO b -> (a -> IO
b) -> IO b) -> a
retInfoTableDescription# :: Addr# -> Ptr CString
walkStack# :: Addr# -> Addr#
}}}
The idea is that the exception handler gets, along with the exception and
a pointer to `esp`, two continuations:
1. A continuation to use if you are able to recover from the exception
and want to return a value. Entering this continuation strips the stack
down to the current catch frame and returns that value to the thing above.
2. A continuation to use if you are not able to recover. Entering this
continuation passes control to the next exception handler on the stack.
The `Addr#` pointer to the stack top points to undefined memory after you
enter either continuation, so you need to ensure that you have forced any
thunks that close over it before you enter a continuation.
You can use `walkStack#` to move your stack pointer down the stack, and
then `unpackClosure#` combined with `retInfoTableDescription#` to obtain a
description of the frame.
I think the major obstacle to this API is deciding how to handle stack
overflow exceptions. In that case, we cannot assume that there will be
enough stack to let the exception handler reify the stack frame before
continuing. Presumably, to deal with this we would have to either:
1. Start a new stack somewhere to run the handler on if we get an
asynchronous stack overflow exception
2. Bump up the stack size temporarily while we run the handler on the
original stack
Either way it sounds fiddly. I'm probably not going to implement this API
yet, and just stick to the basic story for now.
--
Ticket URL: <http://hackage.haskell.org/trac/ghc/ticket/3693#comment:16>
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
