Node:Internal error, Next:, Previous:Missing subprograms, Up:Trouble

6.6 What does "Internal compiler error" mean?

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.