| www.delorie.com/djgpp/v2faq/faq126.html | search |
| www.delorie.com/djgpp/v2faq/faq126.html | search |
Q: How much stack space do I have in my program?
Q: My program seems to overflow the stack, but only when I run it under a debugger...
Q: My program crashes with SIGSEGV, but the traceback makes no sense: it points to something called ___djgpp_exception_table... When I try to debug this, the traceback mysteriously changes to some innocent library function, like getc(). The same program works flawlessly when compiled with DJGPP v1.x What is going on??
_stklen in your program. Example:
unsigned _stklen = 1048576; /* need a 1MB stack */
The DJGPP startup code checks both the value in the stub info and the value of _stklen, and uses the larger of these two. Therefore, programs that are known to require large stack size
should set _stklen to make sure they will always work, even if somebody stub-edits them to a lower value. This technique is also safer when you need to debug your program with
gdb (see below). However, you might need to use STUBEDIT with programs for which you don't have the sources.
Programs which need an unusually large stack might crash with bogus stack traces, because part of the heap gets overwritten by the overflowing stack. To see if that is the cause of such crashes, run
STUBEDIT on your program and crank up the stack size to a large value (like 4MBytes). If that makes the problem go away, tune the stack limit to the minimum value your program can live
with, then set _stklen to an appropriate value as explained above and recompile the program. (Some DPMI hosts will actually allocate the entire stack, even if not all of it is used, so
leaving it at unnecessarily large value will hurt the program on low-memory machines.)
Some users have reported that they needed to enlarge the stack size of the C++ compiler, cc1plus.exe, to prevent it from crashing when compiling some exceedingly large and complex C++ programs. Another program that was reported to need a stack larger than the default is bccbgi.exe from the BCC2GRX package.
After you've used STUBEDIT to change the stack size, run it again to make sure it displays as default the value you thought you entered. This is because STUBEDIT will sometimes silently set the stack size to 0 (and then you will get the default 256K stack) if it doesn't like the value you type (e.g. if it has a wrong syntax).
When you run a program under a debugger, the stack size field in the stub info is ignored, so the only way to change the default stack size is to set _stklen.
Under Windows 3.X, be sure you've allocated a sufficiently large swap file (let's say, 40MBytes) from the Windows' Control Panel, and make sure the .PIF file for your program doesn't have too low limit on EMS/XMS usage (better make them both -1). What's that? You don't have a .PIF file for this program? Then Windows uses the default file DOSPRMPT.PIF, which almost surely defines very low limits on these two, and your program might have problems getting the memory it needs for its stack.
DJGPP v2.0 has a subtle bug in its startup code that is seen very rarely, and that manifests itself by a program crashing with Page Fault or SIGSEGV. If you are using v2.0 and enlarging the stack and the CWSDPMI heap size didn't help, try adding some (e.g., 4KB) static data to your program and see if that helps. But the best way to overcome this is to upgrade to DJGPP v2.01 or later.
| webmaster donations bookstore | delorie software privacy |
| Copyright ⌐ 1998 by Eli Zaretskii | Updated Sep 1998 |
You can help support this site by visiting the advertisers that sponsor it! (only once each, though)