Q: During compilation, GCC prints "Fatal: Error in DJGPP
installation. Environment variable DJGPP is not defined" and then
aborts....
Q: GCC aborts with "Internal compiler error" when compiling a
large C++ program.
Q: GCC behaves erratically when compiling programs, sometimes
crashes with register dump, sometimes compiles okay, sometimes reports
"Internal compiler error". Why is this happening?
Q: When I try to compile any program, GCC prints "Abort!" and
doesn't compile anything....
Q: The compiler crashes or dies with "Virtual memory exhausted"
when I compile my simple program!
A: The fatal error message about DJGPP not being defined
means just that--that your DJGPP environment variable is not
defined. The other two messages you could see are:
Environment variable DJGPP point to file `XXYYZZ' which doesn't exist
or
Environment variable DJGPP points to wrong or corrupt file `ABCDE'
(In both cases, you will see an actual file name instead of
XXYYZZ and ABCDE.) These messages mean that
DJGPP points to a non-existing directory, or to a file whose
contents are too messed up. Beginning with version 2.8.1, GCC refuses
to work when the DJGPP variable doesn't point to the actual path
name of a valid DJGPP.ENV file, because GCC uses the value of the
DJGPP variable to find out where to look for its subprograms like
cpp.exe, cc1.exe, etc. To solve this, set the
DJGPP variable as the installation instructions (in the file
readme.1st) describe. Also, make sure you didn't mess up the
beginning of the DJGPP.ENV file, where the value of the
DJDIR variable is computed (when in doubt, compare it with the
stock DJGPP.ENV from the djdevNNN.zip distribution).
A possible cause for the "Abort!" message is that the TMPDIR
environment variable points to a non-writable directory. If you don't
set TMPDIR from your AUTOEXEC.BAT or from the DOS prompt,
the DJGPP startup code sets it to the tmp subdirectory of the
main DJGPP installation directory. If DJGPP is installed on a read-only
drive, like CD-ROM or an unwritable networked drive, this default will
not work. To solve this, set TMPDIR to point to a writable
temporary directory. If TMPDIR is not set at all, GCC tries to
use TEMP and TMP, in that order, so make sure these also
point to a valid directory.
Internal compiler errors (a.k.a. bugs) can also cause GCC to print "Abort!". This FAQ describes a procedure that allows you to find the spot in the sources where the compiler aborts, see use of the -Q switch, above. Once you find the offending code, you could rewrite it and/or submit a bug report to the GCC maintainers.
When GCC aborts with a message such as "Internal compiler error" or "Exiting due to signal SIGSEGV", it might mean a genuine bug in GCC (which should be reported to FSF), but it can also happen when GCC requests additional chunk of memory, and the DPMI server fails to allocate it because it exhausts available memory for its internal tables. Old releases of CWSDPMI could fail like this if an application asks for a large number of small memory chunks. Beginning with release 2, CWSDPMI defines a larger (6KB) default heap that is configurable by CWSPARAM program to be anywhere between 3K and 40K bytes, without recompiling CWSDPMI. You should upgrade to the latest CWSDPMI if you experience such problems, and if that doesn't help, bump up the size of CWSDPMI heap using CWSPARAM.
Some innocent-looking programs are known to cause GCC to gobble preposterous amounts of memory, which could cause it to crash or abort after printing "Virtual memory exhausted". One particular case of such programs is when you initialize very large arrays. For example, to compile a source which initializes a char array of 300,000 elements requires more than 60MB(!) of memory. You should avoid such constructs in your programs.
Some programs require very large amounts of stack to compile. DJGPP
programs have a fixed-size stack that is by default 256KB (512KB in
DJGPP v2.02 and later). If the compiler, cc1.exe or
cc1plus.exe, doesn't have enough stack to compile a program, it
will overflow its stack and crash, or hang, or die with "Internal
compiler error". You can enlarge the stack size of any DJGPP program
by running the stubedit program, like this:
stubedit cc1.exe minstack=1024k
I recommend to enlarge the maximum stack size of cc1.exe to at
least 1024K bytes and that of cc1plus.exe to at least 1.5MB.
Some people report that they needed to enlarge both the heap of CWSDPMI
and the stack of the C++ compiler to make such problems go away.
For a program that you wrote, another work-around for the cases where a
program crashes due to failure of CWSDPMI to allocate more RAM is to use
an alternative algorithm for sbrk, by putting the following
somewhere in your program:
#include <crt0.h> int _crt0_startup_flags = _CRT0_FLAG_UNIX_SBRK;
Note that the Unix algorithm for sbrk might cause trouble in
programs that install hardware interrupts handlers.
Note that the problems with insufficient stack size have nothing to do
with the total available memory as reported by go32-v2. A
compiler can crash because of insufficient stack size even though it has
gobs of memory available to it. When in doubt, always enlarge the
compiler stack size.
Sometimes, GCC can crash due to problems with your system hardware. In particular, bad memory chips can cause GCC to behave erratically, since the compiler is a memory-intensive program: it moves large buffers around alot, and uses lots of memory. One cause of problems with accessing memory is incorrect setting of the wait states in your BIOS setup, or too aggressive CPU cache mode that your motherboard cannot support reliably, or overclocking the CPU. Try to play with your BIOS setup and see if that helps. If you overclocked the CPU, try resetting it back to its normal speed.
One user reported that he had random crashes and seemingly-missing files due to a disk without proper cooling. So if your system sometimes cannot find files that you know are there, check whether your disk gets proper cooling and generally works okay.
Another rare case of crashes in GCC was reported on Windows 3.X. It
seems to be related to the small probability of getting non-contiguous
memory blocks from the Windows' DPMI server. In general, the DJGPP
library handles these cases, so it is possible that the problem is
actually somewhere in GCC (more accurately, in cc1, the C
compiler). A tell-tale sign of this problem is that the CS and
DS limit value printed in the crash message is very close to the
end of the 4GB address space, like fffeffff. The only known cure
for these cases is to patch or rebuild GCC with the Unix sbrk
algorithm, see above.