delorie.com/archives/browse.cgi   search  
Mail Archives: djgpp/1999/06/08/17:02:30

X-Sender: dlanor AT mail DOT dds DOT nl
Message-Id: <l03130301b38313f880cf@[145.98.116.203]>
In-Reply-To: <Pine.SUN.3.91.990608130841.10724B-100000@is>
References: <v01540b00b3829355e235@[145.18.167.138]>
Mime-Version: 1.0
Date: Tue, 8 Jun 1999 22:02:40 +0200
To: djgpp AT delorie DOT com
From: Dlanor Blytkerchan <dlanor AT dds DOT nl>
Subject: Re: malloc() problem
Reply-To: djgpp AT delorie DOT com
X-Mailing-List: djgpp AT delorie DOT com
X-Unsubscribes-To: listserv AT delorie DOT com

>> >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.
I'm sorry if I stepped on your toes here, but I said nothing about
portability: I just said the same code does work under Borland C. Any
conclusions you draw from that are entirely your own.
I am aware of DJGPPs way of maneging memory (roughly). I am also aware that
the same type of code - save the malloc() itself - has no problem with
thesystem's memory, and much "heavier" programs don't either. This is not
jumping to conclusions, this is suggesting there's something other than
lack of memory causing this. The reason I posted this in the first place,
is that I wanted more info before I drew _any_ conclusions.

>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'm afraid it doesn't, as the "evidence" I just posted counters that: your
own suggestion to use go32-v2 to see how much memory is available suggests
that all memory needed for this allocation is available and therefore, my
program has evidently not run out. The problem is therefore probably
somewhere else. The question is: where.

>> 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.
Okay, I'll accept that - I won't do it. I still need some way to get this
memory, though..

>> >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.
Done that - doesn't shed much light other than consolidating my own hypothesis

>> 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.
.. which it probably tries to do with malloc(), thus, getting back to the
problem with malloc()?

>> 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.)
Physical RAM is low: 8 MB. I have a _lot_ of free space on my C: drive:
about 40 MBs freely available..
I do use CWSDPMI: it is loaded just before the memory is allocated.

Greetz!

Dlanor

====================================================================
*    Dlanor Blytkerchan                                 * * * *    *
*    <dlanor AT dds DOT nl>                                     | | |     *
*    RLSystems software & support                       \_/-\_/    *
--------------------------------------------------------------------
*    Sites by Dlanor Blytkerchan you should visit:                 *
*    The Hazardous Domain:                                         *
*                                <http://huizen.dds.nl/~dlanor>    *
*    Including:                                                    *
*    - The Hazardous Area:                VGA Planets game site    *
*    - The Catacombes:                 VGA Planets support site    *
*    - The TKon Empire:              Rulers of The Echo Cluster    *
*    - The Insatiables:          an undefeated VGA Planets team    *
*    and:                                                          *
*    - The RLSystems main page:           miscelanious software    *
*    - The Third Domain:                 Dlanor's personal site    *
*                                                                  *
*    The Hazardous Forum - Bulletin & chat                         *
*                           <http://www.delphi.com/blytkerchan>    *
- - - - - - - - - - - - - - - - -  - - - - - - - - - - - - - - - - -
*    Other sites you should visit:                                 *
*    The Holodeck: a VGA Planets site by Andrew Sartori            *
*                         <http://neelix.ruralnet.net.au/vgap/>    *
*    The Last Wave: a VGA Planets site by Alan L. Warchuck         *
*     <http://www.thelastdomain.com/alan/thelastwavevgap1.html>    *
- - - - - - - - - - - - - - - - -  - - - - - - - - - - - - - - - - -
*           These sites are on The Hazardous LinkList..            *
--------------------------------------------------------------------
*    PGP public key is available at                                *
*            <http://huizen.dds.nl/~dlanor/keyring/pubring.pgp>    *
====================================================================


- Raw text -


  webmaster     delorie software   privacy  
  Copyright © 2019   by DJ Delorie     Updated Jul 2019