From: Nate Eldredge <neldredge AT hmc DOT edu>
Newsgroups: comp.os.msdos.djgpp
Subject: Re: My program hangs under RHIDE's debugger
Date: 10 Nov 2000 17:57:30 -0800
Organization: InterWorld Communications
Lines: 54
Sender: nate AT mercury DOT st DOT hmc DOT edu
Message-ID: <83wvebclth.fsf@mercury.st.hmc.edu>
References: <Pine DOT SUN DOT 3 DOT 91 DOT 1001109084112 DOT 16891F-100000 AT is> <8ueodf$5ep$1 AT nnrp1 DOT deja DOT com> <9743-Thu09Nov2000224218+0200-eliz AT is DOT elta DOT co DOT il> <8ufgue$reg$1 AT nnrp1 DOT deja DOT com> <9003-Fri10Nov2000120410+0200-eliz AT is DOT elta DOT co DOT il> <8uho2n$kr9$1 AT nnrp1 DOT deja DOT com> <2427-Sat11Nov2000013157+0200-eliz AT is DOT elta DOT co DOT il> <8ui4h7$vac$1 AT nnrp1 DOT deja DOT com>
NNTP-Posting-Host: mercury.st.hmc.edu
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
X-Trace: nntp1.interworld.net 973907850 13445 134.173.57.219 (11 Nov 2000 01:57:30 GMT)
X-Complaints-To: usenet AT news DOT interworld DOT net
NNTP-Posting-Date: Sat, 11 Nov 2000 01:57:30 +0000 (UTC)
User-Agent: Gnus/5.0802 (Gnus v5.8.2) Emacs/20.5
To: djgpp AT delorie DOT com
DJ-Gateway: from newsgroup comp.os.msdos.djgpp
Reply-To: djgpp AT delorie DOT com

dcasale AT my-deja DOT com writes:

> In article <2427-Sat11Nov2000013157+0200-eliz AT is DOT elta DOT co DOT il>,
>   djgpp AT delorie DOT com wrote:
> > > From: dcasale AT my-deja DOT com
> > > Newsgroups: comp.os.msdos.djgpp
> > > Date: Fri, 10 Nov 2000 21:07:40 GMT
> > >
> > > Here's an update on the situation, though.  I was able to get my
> > > compression program working with Nate Eldredge's YAMD (Yet Another
> > > Malloc Debugger).  My program has a loop which allocates some bytes,
> > > allocates some more bytes, then deallocates both.  The loop executes
> > > without any trouble several times, then fails on an allocation.
> >
> > What do you mean by ``fails''?  Did it crash with a Page Fault?  If
> > so, the place where it crashed is the code which overwrites an
> > allocated buffer, and you should look closely at the code which
> > crashed.
> 
> No, I mean the allocation failed _but the program continued_.  The
> crash happened slightly later.
> 
> Here's what YAMD's log file says:
> 
> INFO: Failed allocation
> Failed to malloc 12 bytes (aligned to 1) at
> 	new1.cc:0(___builtin_new+28)  0x02c538
> 	new2.cc:0(___builtin_vec_new+19)  0x02d70f
> 	det.cpp:104(_SetLongPath__4CDETPCUw+212)  0x007b18
> 	dirdisk.cpp:849
> ...
> 
> INFO: Failed allocation
> Failed to malloc 4 bytes (aligned to 1) at
> 	exception.cc:0(___eh_alloc+18)  0x02d19e
> 	new1.cc:0(___builtin_new+65)  0x02c55d
> 	new2.cc:0(___builtin_vec_new+19)  0x02d70f
> 	det.cpp:104(_SetLongPath__4CDETPCUw+212)  0x007b18
> 	dirdisk.cpp:849
> ...
> 
> Why did the malloc suddenly fail when there was memory still
> available?  12 bytes and 40 bytes had been freed previous to these two
> failed allocations.

Yes, but YAMD doesn't actually free memory.  It keeps the block
around, so it can see if you try to access it later (which would be an
error).  So you do need quite a lot of memory (or swap) to use YAMD on
a program of any size.  The README explains this.

-- 

Nate Eldredge
neldredge AT hmc DOT edu