Mail Archives: djgpp/2000/04/18/05:53:45
On Mon, 17 Apr 2000, J.P. Morris wrote:
> Under Linux, the program runs correctly for an indefinite period.
> Under DJGPP, however, it crashes between 9:00 and 11:00 game time,
> i.e. about 180-300 cycles of the game loop.
Linux (and most or all Unix systems in general) zero out sbrk'ed
memory allocated for the process. DJGPP's sbrk doesn't do that by
default (for performance reasons), so these crashes might mean you are
using uninitialized memory.
I suggest using the _CRT0_FLAG_FILL_SBRK_MEMORY (not
_CRT0_FLAG_FILL_DEADBEEF!) to see whether this is your problem.
> The reason it crashes is that some of my pointers appear to be
> spontaneously changing, either to 0xA7 (which causes an RMCB fault)
> or to 0x20320?.
It would be a *very* good idea to post a couple of tracebacks, there
might be something in them that you overlooked.
Btw, 0x20320? looks like ASCII text to me.
If these pointers are always the same, I suggest running the program
under GDB and setting a data-write breakpoint (a.k.a. watchpoint) at
those pointers. Then the debugger will catch the offending code
red-handed when it tries to write to those locations.
> I used the sbrk fill option to fill allocated memory with 0xdeadbeef,
> but the memory I'm using isn't memory I've allocated, because I have
> my own malloc() wrapper, which I used to try and find the rogue blocks.
The memory is filled with 0xdeadbeef by `sbrk', not by `malloc'. So
in effect, you are using memory that wasn't allocated at all (assuming
your program doesn't call `sbrk' directly).
> Does sbrk fill memory with DEADBEEF only during allocation, or also
> when memory is freed?
`sbrk' doesn't free memory, ever. It fills it when it is allocated
from the DPMI host, and it does that only once for each allocated
block; you can see the code which does that in the file
src/libc/crt0/crt0.S in the library sources.
> I have made utterly sure that memory is being locked in my interrupt
> handlers. In addition I have also used fortify, which detects memory
> overruns. It has not detected any.
> Since each part of the program relies on something which has happened
> previously and the problems only manifest when the program is fully
> operational, I cannot effectively reduce the potential problem area.
Can you run the program under a debugger? If so, do the crashes
happen when it is run under a debugger? If they do, I suggest to run
it under a debugger as a matter of habit, for a while, and when it
crashes, poke around to find the problems. DJGPP doesn't support core
files, so running under a debugger is your only bet to find out the
cause for such complex and elusive bugs.
> I would guess that the problem must be one of these:
>
> 1. A memory overrun of statically-allocated data (is there a tool to detect
> this?)
I don't understand what overrun do you have in mind, and neither do I
think such things can happen. Please elaborate.
> 2. Memory overrun in a 3rd-party library
> 3. Memory is being used long after deallocation (NOT through M_get() or M_free()
> wrappers)
It's also possible that some function writes beyond the limits of an
automatic array.
Another possibility is that you have stack overflow.
But my best bet is that some code either uses uninitialized memory or
uses a stale pointer that was already `free'd.
Did you try to use YAMD? It's quite good in catching such problems.
- Raw text -