Mail Archives: djgpp/1999/06/08/06:28:44
On Tue, 8 Jun 1999, Dlanor Blytkerchan wrote:
> >If you ran go32-v2 *before* invoking your program, it is possible that
> >the programn's code, data and stack used up quite a lot of memory, and
> >you really don't have 34KB left.
> In this case, that's hard to imagine: all it does is call a method from
> main(), which allocates the 34 kb using malloc() and tries to open a file.
This issue has nothing to do with imagination. For example, are you
aware of the fact that the run-time stack for your program is allocated
at startup, all at once, and gobbles at least 512KB of memory? And if
you stubedit the program to have a larger stack, then that much memory is
allocated before your program executes its first instruction.
So I suggest to gather the hard evidence before jumping to conclusions
about what is and what isn't probable. So far, every piece of evidence
you have posted points to one direction: that somehow your system is
really running out of memory. I suggest to accept this as a working
hypothesis and try to understand what is it that eats up all the memory.
If the real problem is elsewhere, you will discover that in the process,
but for now, this seems to me as a very reasonable assumption.
> I have found a way of getting memory in dpmi.h. however, the address of
> that memory is returned inside an info structure as an int. What I do not
> know is how to use my pointers to point to the place that int is pointing
> at. That might help.
Don't do that. Getting memory directly from sbrk and managing it is very
complicated, full of weird aspects that are specific to different DPMI
servers, and could drive you crazy. It is much easier to find the reason
for malloc returning NULL than go to DPMI functions.
> >Try invoking go32-v2 (via `system') at the beginning of `main', or near
> >the place where you allocate those 34KB, and see what does it print then.
> I'll do that, but I doubt it will change anything: I simply see no reason
> for the program to use 4MBs of memory just for allocating 34 K of mem and
> opening a file.
Let's stick to the facts, for a while, before we are trying to explain
them away. Sometimes simply printing out memory usage figures (which is
what go32-v2 does) sheds some new light on an otherwise mysterious
behavior.
> One interesting thingy, though: the same type of error occured earlier when
> making this program: I had defined the same buffer not as a pointer, but as
> bufferType buffer;. When I started the program it died with "Load error: no
> DPMI memory".
This is one more evidence that your system runs out of memory somehow.
This message is printed when the stub loader cannot allocate enough
memory to load the code and static data of your program.
> As for system stuff: I'm using DOS 6.22 dutch edition with QEMM and HIMEM
> alternatively (it doesn't work under either).
How much physical RAM do you have, and how much free disk space is there
on drive C:? (I assume you use CWSDPMI as your DPMI server.)
- Raw text -