Mail Archives: djgpp/2001/02/06/20:34:03
In article <95pvlm$hurnd$1 AT ID-57378 DOT news DOT dfncis DOT de>,
"Alexei A. Frounze" <dummy_addressee AT hotmail DOT com> wrote:
> <dcasale AT my-deja DOT com> wrote in message news:95pqqk$t55
$1 AT nnrp1 DOT deja DOT com...
> > Me again. I've broken my compression proggy again by trying to add
> > another feature. This time, I've managed to get it to give me
> > a "General Protection Fault" when I try to do a new. This is under
> > straight DOS, by the way.
> >
> > I'm building a huge (about 8000ish or so) linked list of objects (16
> > bytes per object, not including allocation overhead) for the
> > purpose of sorting a huge list of files. When I'm getting towards
> > the end of the list of files, I get a GPF when I try to create
> > another linked list object.
>
> Make sure it's not a bug in your program (like use of a wrong
> pointer, e.g. pointing outside allocated memory).
If there is a wrong pointer somewhere, I haven't found it yet.
> > I've tried making the stack bigger (a-la FAQ 15.9). I've tried
> > increasing the CWSDPMI heap size (a-la FAQ 15.4). Neither seems to
> > have helped. Whether I'm debugging the program under RHIDE or just
> > running it straight, it seems to fail with the exact same error, in
> > the exact same spot, on the exact same file, every time.
> >
> > The GPF gives me esi=00000010, meaning that my stack has somehow
> > wrapped around. Right? But how is that possible if I've increased
> > the stack size? What else could be causing this problem?
>
> ESI has nothing to do with the stack.
Woops. Should have looked at ESP, not ESI. ^^;;
My stack pointer is 0000227a, which looks a little low. However, the
new should be allocating memory off of the heap, right?
I tried including a call to __dpmi_get_free_memory_information and
checking the largest_available_free_block_in_bytes member. It says
that it has about 300MB available, including virtual memory I assume.
Since GO32-V2 says that I have 94MB in physical memory and 256MB in
virtual memory, that means I should only be using 50MB of physical
memory and no virtual memory. If I still have physical _and_ virtual
memory available, what gives? Even if this value isn't accurate, I
couldn't possibly be using up 350MB of memory, including swap space. I
doubt I'm using 94MB, even if all memory allocations are page-aligned
(e.g., to 4096 byte boundaries). I haven't noticed that kind of
allocation alignment in my debugging.
BTW, the pointer to the new element is not being placed in unallocated
memory. In other words, the element with the "next" pointer to this
new element is valid, itself.
Damon Casale, damon AT WRONG DOT redshift DOT com (remove the obvious)
Full-contact debugging! The 3133+ sport of the new millenium.
Sent via Deja.com
http://www.deja.com/
- Raw text -