From:	s335194 AT student DOT uq DOT edu DOT au (David Wilson)
Newsgroups:	comp.os.msdos.djgpp
Subject:	Re: problem with malloc in djgpp?
Date:	14 Mar 1997 13:10:28 GMT
Organization:	University of Queensland
Message-ID:	<5gbio4$874$1@nargun.cc.uq.edu.au>
References:	<Pine DOT SUN DOT 3 DOT 91 DOT 970313130450 DOT 6426C-100000 AT is>
NNTP-Posting-Host:	student.uq.edu.au
Lines:	98
To:	djgpp AT delorie DOT com
DJ-Gateway:	from newsgroup comp.os.msdos.djgpp

> On 12 Mar 1997, David Wilson wrote:
> 
> > With DPMI you need to realize that the values returned from
> > __dpmi_get_free_memory_information (yes it is a long name), and the
> > corresponding _go32_dpmi_remaining_*() functions, are subject to
change at
> > the whims of Windows/CWSDPMI/... 
> 
> AFAIK, this is incorrect.  The reported *physical* memory might
> sometimes change on Windows (although I never saw this myself), but
> the total *virtual* memory should never change during a program's
> run.  With CWSDPMI, it *never* changes.  If you can describe a test
> which shows such changes in reported virtual memory, please post the
> description.

I didn't say that the total physical/virtual memory stats might change. I
said that the FREE physical/virtual memory stats might change.

However, there definitely is something more complex happening than I
thought originally. I've just done some playing around with DJGPP 2 in a
Windows 95 DOS box.  I compiled and ran the short program below:

------[cut here]------
// test.cc
#include <stdio.h>
#include <stdlib.h>
#include <dpmi.h>
#include <go32.h>

#define MEGS    15

main(int argc, char* argv[])
{
    unsigned long   avl1, avl2, avl3, avl4, megs;
    char* t;

    megs = (argc > 1) ? atoi(argv[1]) : MEGS;
    megs *= 1024*1024;

    avl1 = _go32_dpmi_remaining_physical_memory();
    avl2 = _go32_dpmi_remaining_virtual_memory();

    printf("Before large malloc: %lu phys, %lu virtual free\n", avl1,
avl2);

    t = (char*) malloc(megs);
    if(!t) { printf("Malloc (%lu) failed\n", megs); return 1; }

    *t = 0;

    avl3 = _go32_dpmi_remaining_physical_memory();
    avl4 = _go32_dpmi_remaining_virtual_memory();

    printf("After large malloc: %lu phys, %lu virtual free\n", avl3,
avl4);
    printf("A %lu-sized block uses %lu bytes phys, %lu bytes virtual\n",
        megs, avl1-avl3, avl2-avl4);

    return 0;
}

------[cut here]------

I ran it in a DOS box with the XMS and DPMI memory values set to 32768
each.  Here is what I got:

------[cut here]------

E:\DJGPP2>test 15
Before large malloc: 9785344 phys, 31784960 virtual free
After large malloc: 9781248 phys, 16252928 virtual free
A 15728640-sized block uses 4096 bytes phys, 15532032 bytes virtual

E:\DJGPP2>test 16
Before large malloc: 9781248 phys, 31784960 virtual free
After large malloc: 9781248 phys, 16252928 virtual free
A 16777216-sized block uses 0 bytes phys, 15532032 bytes virtual

E:\DJGPP2>test 17
Before large malloc: 9781248 phys, 31784960 virtual free
Malloc (17825792) failed

------[cut here]------

This goes to prove my original point which I perhaps didn't make as clear
as I had intended:  Free memory values under Windows aren't very accurate.

I suspect the problem is from the malloc() implementation.  I think it
allocates blocks in fixed sizes that keep on doubling. So when asking for
the 17M chunk, it's trying to get a 30 or 31 meg chunk, which is being
refused by DPMI since Windows only wants to give the program 32 megs.

The only thing I can't figure out is "test 16"... How does a 16MB
allocation fit in *LESS* than 16MB of virtual memory?  Can anyone shed any
light on this?

--Dave
<s335194 AT student DOT uq DOT edu DOT au>

- Raw text -