delorie.com is funded by banner ads.
  www.delorie.com/djgpp/v2faq/faq074.html   search  

| Previous | Next | Up | Top |

9.1 My program crashes only in v2.0!

Q: I have this program which runs fine when compiled with DJGPP v1.12, but crashes and burns in v2. Isn't it obvious that you guys blew it with v2?

Q: My v2 program crashes, but only under CWSDPMI; it runs OK under other DPMI hosts like Windows, OS/2 or QDPMI. Is this a bug in CWSDPMI?

A: Not necessarily so, it could still be a bug in your program which just went unnoticed until now. One area where such things can happen is use of uninitialized memory. In v1.x, memory first allocated to the stack or by a call to malloc is always zeroed, but v2 doesn't behave this way, so your program might exhibit erratic behavior or crash with SIGSEGV because of such bugs. In particular, if the program behaves differently depending on which program was run before it, you might suspect bugs of this kind.

To check whether this is the source of your grief, include the header crt0.h in your main and set _crt0_startup_flags to _CRT0_FLAG_FILL_SBRK_MEMORY; this will fill the memory with zeroes when it is first allocated. If the program will run OK after recompilation, then this is probably the cause of your problem. To make spotting uninitialized memory simpler, you can set _crt0_startup_flags to _CRT0_FLAG_FILL_DEADBEEF (don't laugh!); this will cause the sbrk()'ed memory to be filled with the value 0xdeadbeef (-559038737 in signed decimal or 3735928559 in unsigned decimal) which should be easy to spot with a debugger. Any variable which has this value was used without initializing it first.

Another possible cause of problems will most probably be seen only under CWSDPMI; its telltale sign is a message "Page fault at ..." that is printed when a program crashes, and an error code of 4 or 6. Unlike other DPMI hosts, CWSDPMI supports some DPMI 1.0 extensions which allow DJGPP to capture and disallow illegal dereference of pointers which point to addresses less than 1000h (a.k.a. NULL pointer protection). This feature can be disabled by setting the _CRT0_FLAG_NULLOK bit in _crt0_startup_flags; if this makes SIGSEGV crashes go away, your program is using such illegal pointers; the stack trace printed when the program crashes should be a starting point to debug this. See how to debug SIGSEGV, for more details about these problems.

An insufficient stack size can also be a cause of your program's demise, see setting the stack size, below.


  webmaster   donations   bookstore     delorie software   privacy  
  Copyright ⌐ 1998   by Eli Zaretskii     Updated Sep 1998  

Powered by Apache!

You can help support this site by visiting the advertisers that sponsor it! (only once each, though)