| www.delorie.com/djgpp/v2faq/faq036.html | search |
| www.delorie.com/djgpp/v2faq/faq036.html | search |
| Previous | Next | Up | Top |
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!
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 `ABCDEFG'
(In both cases, you will see an actual file name instead of XXYYZZ and ABCDEFG.) 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. 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=512k
I recommend to enlarge the maximum stack size of cc1.exe to at least 512K bytes and that of cc1plus.exe to at least 1MB. 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.
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. 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. Try to play with your BIOS setup and see if that helps.
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.
| webmaster donations bookstore | delorie software privacy |
| Copyright ⌐ 1998 by Eli Zaretskii | Updated Nov 1998 |
You can help support this site by visiting the advertisers that sponsor it! (only once each, though)