If you still have a problem after consulting this section, then you may have found a bug---please report it! See Section How to report a bug in the GHC system for a list of things we'd like to know about your bug. If in doubt, send a report---we love mail from irate users :-!
(Section Haskell 1.4 vs. Glasgow Haskell 4.00: language non-compliance, which describes Glasgow Haskell's shortcomings vs. the Haskell language definition, may also be of interest.)
These events are always bugs in the GHC system---please report them.
It happens. We try to supply reasonable -H<n> flags for
ghc/compiler/ and ghc/lib/, but GHC's memory consumption
can vary by platform (e.g., on a 64-bit machine).
Just say make all EXTRA_HC_OPTS=-H<a reasonable number> and see
how you get along.
Note that this is less likely to happen if you are compiling with GHC 4.00 or later, since the introduction of the dynamically expanding heap.
This is a bug just as surely as a ``panic.'' Please report it.
If you think that GHC could have produced a better error message, please report it as a bug.
Almost surely not a problem. About some specific cases...
Sad, but harmless. You can change the number with a
-fmax-simplifier-iterations<N>
option (no space);
and you can see what actions took place in each iteration by
turning on the -fshow-simplifier-progress
option.
If the simplifier definitely seems to be ``looping,'' please report it.
For example: ``...warning: `Foo' declared `static' but never defined.'' Unsightly, but shouldn't be a problem.
.hi interface files:GHC is very sensitive about interface files. For example, if it picks
up a non-standard Prelude.hi file, pretty terrible things will
happen. If you turn on
-fno-implicit-prelude
, the
compiler will almost surely die, unless you know what you are doing.
Furthermore, as sketched below, you may have big problems running programs compiled using unstable interfaces.
Unlikely :-) A useful be-more-paranoid option to give to GHC is
-dcore-lint
; this causes a ``lint''
pass to check for errors (notably type errors) after each Core-to-Core
transformation pass. We run with -dcore-lint on all the time; it
costs about 5% in compile time.
If the linker complains about not finding _<something>_fast, then
something is inconsistent: you probably didn't compile modules in the
proper dependency order.
(These are reported just after linking your program.)
You tried to link incompatible object files, e.g., normal ones (registerised, Appel garbage-collector) with profiling ones (two-space collector). Or those compiled by a previous version of GHC with an incompatible newer version.
If you run nm -o *.o | egrep 't (cc|hsc)\.' (or, on
unregisterised files: what *.o), you'll see all the consistency
tags/strings in your object files. They must all be the same!
(ToDo: tell you what they mean...)
On this score, GHC usually does pretty well, especially if you ``allow'' it to be off by one or two. In the case of an instance or class declaration, the line number may only point you to the declaration, not to a specific method.
Please report line-number errors that you find particularly unhelpful.
(For advice about overly slow or memory-hungry Haskell programs, please see Section Advice on: sooner, faster, smaller, stingier).
(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 after any
modules on which it depends (unless you use .hi-boot files, in which
case these must be correct with respect to the module source).
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
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;
# as mentioned above, use -dcore-lint to be more paranoid
% ./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 Hard-core debugging of GHC-compiled programs.
This is definitely caused by a bug in GHC. Please report it.
Int, Float, and Double arithmetic is unchecked.
Overflows, underflows and loss of precision are either silent or
reported as an exception by the operating system (depending on the
architecture). Divide-by-zero may cause an untrapped
exception (please report it if it does).
Glasgow Haskell is a changing system so there are sure to be bugs in it. Please report them to glasgow-haskell-bugs@dcs.gla.ac.uk! (However, please check the earlier part of this section to be sure it's not a known not-really-a problem.)
The name of the bug-reporting game is: facts, facts, facts. Don't omit them because ``Oh, they won't be interested...''
uname -a or cat
/etc/motd will show the desired information.)
gcc -v will tell you.
-v (verbose)
flag, so we can see exactly what was run, what versions of things you
have, etc.
If your program is crashing, you should almost surely file a bug report, as outlined in previous sections.
This section suggests ways to Make Further Progress Anyway.
The first thing to establish is: Is it a garbage-collection (GC) bug?
Try your program with a very large heap and a -Sstderr RTS
flag.
-F2s
runtime flag), then it probably is a GC bug.If it is a GC bug, you may be able to avoid it by using a
particular heap size or by using a -F2s runtime flag. (But don't
forget to report the bug!!!)
ToDo: more here?