Mail Archives: djgpp/2000/11/10/21:01:50
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
- Raw text -