#3693: Show stack traces
---------------------------------+------------------------------------------
Reporter: jpet | Owner:
Type: feature request | Status: patch
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
---------------------------------+------------------------------------------
Comment(by batterseapower):
I've attached some fairly complete patches for stack trace support.
The outstanding issues are:
1. These three tests fail for me on both Windows and Linux after applying
the patch, but I'm not sure why some of them do. One is a GHC performance
test, so it looks like there is a small perf regression caused by the
patches:
{{{
3429(threaded2)
T1969(normal)
T3294(normal)
}}}
2. These two tests fail on Windows only:
{{{
stacktrace1-ghci(ghci)
stacktrace1-stripped(normal,optc,hpc,optasm,threaded1,threaded2)
}}}
The first failure is harmless. The error is "Failed to load interface for
`HC.TopHandler'", and is solved if you run dos2unix on the .genscript
file. I'm not really sure why this is a problem for that particular ghci
test and no other one, though!
The second failure is more serious: my guess is that Windows barfs when
loading an executable where some symbols point into a stripped section.
The exact error I get is "stacktrace1-stripped.exe is not a valid Win32
application", which is not very informative. It would however be
straightforward to show a warning when the -strip-stack-info flag is given
on Windows, just like we already do if it is used on OS X.
3. Currently I show the stg_ stack frames originating from the RTS, but
it's up for debate as to whether we should bother. I think we probably
should show them, because it's quite interesting to see where the update
frames, catch frames etc are. It's very easy to change this behaviour to
turn them off (a 2-line edit in CmmParse.y).
Other than that I think the patch is pretty much done. I've tested it on
32 bit Intel on all three of Windows, Linux and OS X. Solaris / 64 bit
support may possibly have minor bugs in them, but I can't test that. e.g.
i'm not sure if I got the solaris assembler syntax correct.
This patch will make throwing an exception slightly slower because it
reifies the stack to a depth of 100 when you call stg_raisezh. Other flaws
with the design that has been implemented mean that:
1. It is impossible to re-raise a Haskell-side "StackTrace" value once
you have caught it. This is fixable at the cost of extra allocation
(reified stacks should be of type Arr# String rather than a ByteArray#
array of Addr# to CStrings), but that allocation can be done statically by
generating a closure in .ghc_debug section.
2. There is no support for "inner exceptions". I.e. if an exception
handler throws an exception, we should pair the original stack trace with
the stack trace from the new place it is throwing from. This can be
implemented with a bit more effort than 1, but if we did it then it would
subsume 1 (we could keep stack traces as ByteArray#) and would require
less effort on the part of the programmer to get informative stack traces.
Make of it what you will :-). I don't want to spend too many more cycles
on this problem right now, so if you want to change the design radically
it may take me a while to get around to it.
--
Ticket URL: <http://hackage.haskell.org/trac/ghc/ticket/3693#comment:20>
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
