Xref: news2.mv.net comp.os.msdos.djgpp:915
From: Charles Sandmann <sandmann AT clio DOT rice DOT edu>
Newsgroups: comp.os.msdos.djgpp
Subject: Re: CWSDPMI bug [was Infernal compiler error.]
Date: Fri, 09 Feb 1996 10:20:21 CST
Organization: Rice University, Houston, Texas
Lines: 20
Message-ID: <311b7445.sandmann@clio.rice.edu>
References: <Pine DOT SUN DOT 3 DOT 91 DOT 960208133940 DOT 1575J-100000 AT n8g> <311aca97 DOT sandmann AT clio DOT rice DOT edu> <DMHv6z DOT 7Ku AT cfanews DOT harvard DOT edu>
Reply-To: sandmann AT clio DOT rice DOT edu
NNTP-Posting-Host: clio.rice.edu
To: djgpp AT delorie DOT com
DJ-Gateway: from newsgroup comp.os.msdos.djgpp

> : Its a CWSDPMI bug.  CWSDPMI ran out of memory zones (after around 3000
> : sbrk calls).  This can be fixed by bumping the internal heap size.
> Is a program which does a lot of small malloc's likely to trigger this bug?

Maybe.  The current distributed CWSDPMI can run up to around 200 memory zones
before returning 0 for the malloc() call.  Since each memory zone is a 
minimum of 64K, this would be around 13Mb of memory allocated in calls of
less than 32K each.  Note that some other DPMI providers will have a similar
problem at around 16Mb, so you might want to consider fix 2/3 below.

There are few potential fixes:
1) ftp.neosoft.com:pub/users/s/sandmann/csdpmi1heapfix.zip contains a program
   and explaination to work around this problem if you see it.  Since noone
   reported it in 2 months of beta'ing, I don't think this is a huge problem.
   With the fix, you can probably go as big as you want.
2) #include <crt0.h> and then set the flag to use the unix sbrk algorithm if
   you have the source.  This will use a single resized zone, and there are
   no limits.
3) Yet another bin-patch utility I have someplace, which modifies the sbrk()
   algorithm for a DJGPP v2 image in the binary to be unix-style.