From:	nikki AT gameboutique DOT co (nikki)
Newsgroups:	comp.os.msdos.djgpp
Subject:	Re: problem with malloc in djgpp?
Date:	13 Mar 1997 19:50:28 GMT
Organization:	GameBoutique Ltd.
Lines:	46
Message-ID:	<5g9lq4$6bb@bore.pipex.net>
References:	<5g491r$mbg AT lyra DOT csx DOT cam DOT ac DOT uk>
	<5g7b20$uc$1 AT nargun DOT cc DOT uq DOT edu DOT au>
NNTP-Posting-Host:	www.gameboutique.com
Mime-Version:	1.0
To:	djgpp AT delorie DOT com
DJ-Gateway:	from newsgroup comp.os.msdos.djgpp

> Is the program failing in needmem() or in main(), after the call to
> needmem()?  

needmem always succeeds. ie it will always tell me there is enough memory,
but then fail to actually allocate it with malloc :(

> 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/... 

yeh i always make sure i'm effectively single tasking to avoid these problems.
i try to run under dos wherever possible, the only reason i had to run under
winblows at all was because dos would only let me get hold of 0.7meg real
memory ;( and i can't do anything about it because it's someone elses 
machine.

> What MIGHT be happening is that the DPMI client reports only a small
> amount of free memory, but if you malloc() a huge chunk it will get more
> memory from the system for you, using virtual memory if appropriate.  So
> even if your program only got told it had 4 MB free you still might be
> able to allocate a 64MB buffer.

i switched to calloc to ensure against this on someones suggestion. i'm right
in thinking calloc will affect go32_longname whereas malloc won't until the
memory is actually used aren't i? it certainly seems to be that way. changing
to calloc fixed the page fault problems, so my needmem routines are now checking
correctly.

> Possible solution to problem:  try the 14-meg malloc first, and if it
> fails, then report free memory to user and abort.

this does seem to be something connected with the problem. the order of the
mallocs appears to make a difference. i can only assume this is due to
fragmentation of the memory. although for 120meg to be fragmented in such a
way that i can't contiguously allocate a 14meg block seems strange.
my current 'solution' to the problem is to allocate 2 7meg buffers and try
and split the work up. this isnt really a solution just a workaround but it
will have to do it seems.

regards,
nik

-- 
Graham Tootell           
nikki AT gameboutique DOT com  

- Raw text -