Execution failures in the interactive system can be due to problems with the bytecode interpreter, problems with the bytecode generator, or problems elsewhere. From the bugs seen so far, the bytecode generator is often the culprit, with the interpreter usually being correct.
Here are some tips for tracking down interactive nonsense:
-DDEBUG
(nb, that
means the RTS from the previous stage!), run with +RTS
-D2
to get a listing in great detail from the
interpreter. Note that the listing is so voluminous that
this is impractical unless you have been diligent in
the previous step.
+RTS -D2
tries hard to print useful
descriptions of what's on the stack, and often succeeds.
However, it has no way to map addresses to names in
code/data loaded by our runtime linker. So the C function
ghci_enquire
is provided. Given an address, it
searches the loaded symbol tables for symbols close to that
address. You can run it from inside GDB:
(gdb) p ghci_enquire ( 0x50a406f0 ) 0x50a406f0 + -48 == `PrelBase_Czh_con_info' 0x50a406f0 + -12 == `PrelBase_Izh_static_info' 0x50a406f0 + -48 == `PrelBase_Czh_con_entry' 0x50a406f0 + -24 == `PrelBase_Izh_con_info' 0x50a406f0 + 16 == `PrelBase_ZC_con_entry' 0x50a406f0 + 0 == `PrelBase_ZMZN_static_entry' 0x50a406f0 + -36 == `PrelBase_Czh_static_entry' 0x50a406f0 + -24 == `PrelBase_Izh_con_entry' 0x50a406f0 + 64 == `PrelBase_EQ_static_info' 0x50a406f0 + 0 == `PrelBase_ZMZN_static_info' 0x50a406f0 + 48 == `PrelBase_LT_static_entry' $1 = voidIn this case the enquired-about address is
PrelBase_ZMZN_static_entry
. If no symbols are
close to the given addr, nothing is printed. Not a great
mechanism, but better than nothing.
compiler/ghci/ByteCodeGen.lhs
) being
confused about the true set of free variables of an
expression. The compilation scheme for let
s
applies the BCO for the RHS of the let to its free
variables, so if the free-var annotation is wrong or
misleading, you end up with code which has wrong stack
offsets, which is usually fatal.
These optimisations complicate the interpreter.
If you think you have an interpreter problem, re-enable the
define REFERENCE_INTERPRETER
in
ghc/rts/Interpreter.c
. All optimisations are
thereby disabled, giving the baseline
I-only-know-how-to-enter-BCOs behaviour.
If this is biting you baaaad, it may be worth copying
sources for the compiled functions causing the problem, into
your interpreted module, in the hope that you stay in the
interpreter more of the time. Of course this doesn't work
very well if you've defined
REFERENCE_INTERPRETER
in
ghc/rts/Interpreter.c
.
Interpreter.c
which can be used to get the
stack sanity-checked after every entry, and even after after
every bytecode instruction executed. Note that some
bytecodes (PUSH_UBX
) leave the stack in
an unwalkable state, so the do_print_stack
local variable is used to suppress the stack walk after
them.
Last modified: Fri Feb 1 16:14:11 GMT 2002