From: "A. Sinan Unur" Newsgroups: comp.os.msdos.djgpp Subject: Re: malloc() problem, DJDEV 203 Date: 3 Jul 2001 12:25:59 GMT Organization: Cornell University Lines: 35 Sender: verified_for_usenet AT cornell DOT edu (asu1 on slip-32-102-40-168.ny.us.prserv.net) Message-ID: References: NNTP-Posting-Host: slip-32-102-40-168.ny.us.prserv.net X-Trace: news01.cit.cornell.edu 994163159 1108 32.102.40.168 (3 Jul 2001 12:25:59 GMT) X-Complaints-To: usenet AT news01 DOT cit DOT cornell DOT edu NNTP-Posting-Date: 3 Jul 2001 12:25:59 GMT User-Agent: Xnews/4.06.22 To: djgpp AT delorie DOT com DJ-Gateway: from newsgroup comp.os.msdos.djgpp Reply-To: djgpp AT delorie DOT com Eli Zaretskii wrote in news:Pine DOT SUN DOT 3 DOT 91 DOT 1010703150621 DOT 19306K-100000 AT is: > On 3 Jul 2001, A. Sinan Unur wrote: > >> Anyway, GNU Malloc seems to work as expected (returning null) for >> large allocations up to 0xFFF5FFFF. After that it goes into an >> infinite loop (can still do CTRL-BREAK to exit). > > On what OS was that? And what version of GNU malloc did you try? It was in a DOS box using Win 98 SP1. 96 MB physical memory installed and go32-v2 reports: DPMI memory available: 43136 Kb DPMI swap space available: 51816 Kb This sounds pathetic but I am not sure what version of GNU malloc I used. I went to ftp.gnu.org and downloaded malloc.tar.gz. The change log included indicates Thu Jul 11 18:15:04 1991 as the most recent change, and points to the change log included in the C library for the more recent changes, but I don't have it. > I recently found a nasty bug in gmalloc, whereby large allocation > requests were treated as negative numbers in some of the subroutines of > gmalloc. It's quite possible that the loop you see is due to that. > (The reason of the bug was that they mixed signed and unsigned, if > someone's interested.) Definitely possible. Sorry I cannot provide more info at this point. -- -------------------------------- A. Sinan Unur http://www.unur.com/