Go to the first, previous, next, last section, table of contents.
(For advice about overly slow or memory-hungry Haskell programs,
please see section See section Advice on: sooner, faster, smaller, stingier).
- "Help! My program crashed!"
- (e.g., a `segmentation fault' or `core dumped')
If your program has no `_ccall_'s/`_casm_'s in it, then a crash is always
a BUG in the GHC system, except in one case: If your program is made
of several modules, each module must have been compiled with a stable
group of interface (`.hi') files.
For example, if an interface is lying about the type of an imported
value then GHC may well generate duff code for the importing module.
This applies to pragmas inside interfaces too! If the pragma is
lying (e.g., about the "arity" of a value), then duff code may result.
Furthermore, arities may change even if types do not.
In short, if you compile a module and its interface changes, then all
the modules that import that interface must be re-compiled.
A useful option to alert you when interfaces change is
`-hi-diffs'. It will run `diff' on the
changed interface file, before and after, when applicable.
If you are using `make', a useful tool to make sure that every
module is up-to-date with respect to its imported interfaces is
`mkdependHS' (which comes with GHC). Please see
section See section Makefile dependencies in Haskell: using `mkdependHS'.
If you are down to your last-compile-before-a-bug-report, we
would recommend that you add a `-dcore-lint' option (for
extra checking) to your compilation options.
So, before you report a bug because of a core dump, you should probably:
% rm *.o # scrub your object files
% make my_prog # re-make your program; use -hi-diffs to highlight changes
% ./my_prog ... # retry...
Of course, if you have `_ccall_'s/`_casm_'s in your program then all bets
are off, because you can trash the heap, the stack, or whatever.
If you are interested in hard-core debugging of a crashing
GHC-compiled program, please see section See section Hard-core debugging of GHC-compiled programs.
- "My program entered an `absent' argument."
- This is definitely caused by a bug in GHC. Please report it.
- "What's with this `arithmetic (or `floating') exception' "?
- `Int', `Float', and `Double' arithmetic is unchecked. Overflows
and underflows are silent. Divide-by-zero may cause an
untrapped exception (please report it if it does). I suppose other
arithmetic uncheckiness might cause an exception, too...
Go to the first, previous, next, last section, table of contents.