From: dcasale AT my-deja DOT com
Newsgroups: comp.os.msdos.djgpp
Subject: Re: My program hangs under RHIDE's debugger
Date: Sat, 11 Nov 2000 00:40:07 GMT
Organization: Deja.com - Before you buy.
Lines: 108
Message-ID: <8ui4h7$vac$1@nnrp1.deja.com>
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>
NNTP-Posting-Host: 199.249.234.30
X-Article-Creation-Date: Sat Nov 11 00:40:07 2000 GMT
X-Http-User-Agent: Mozilla/4.0 (compatible; MSIE 5.5; Windows 98)
X-Http-Proxy: 1.1 x52.deja.com:80 (Squid/1.1.22) for client 199.249.234.30
X-MyDeja-Info: XMYDJUIDdcasale
To: djgpp AT delorie DOT com
DJ-Gateway: from newsgroup comp.os.msdos.djgpp
Reply-To: djgpp AT delorie DOT com

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.

> The way YAMD works, it causes a Page Fault whenever a program tries to
> access any address outside of any buffer allocated via malloc.

Unfortunately, I can't see the crash screen because YAMD scrolls it off
the screen too quickly to be seen.  How do I get around this?

I've been running it this way, according to the YAMD docs:

bash run-yamd -dsoC:\SYM.LOG C:\000\QPAK22\QPAK.EXE E:\SMEG.PAK D:\ >
C:\OUT.TXT

The OUT.TXT file is the debug output from the program.  Since disk
output is buffered, the last bit of debug output gets truncated,
immediately prior to the crash.  When this runs, I see the crash screen
briefly, but then it scrolls off of the screen because of the YAMD
debugging stuff.

I've tried running QPAK without the bash script, but it dumps
unsymified debugging stuff to stderr, again, scrolling the crash output
off of the screen.

Any ideas on how to get at this crash info?

> > Any ideas why that would happen?  Is there a DJGPP equivalent to the
> > Microsoft _fheapmin call that I don't know about, that might solve
> > this problem?
>
> What do you need the equivalent of _fheapmin for?  How would it help
> to solve this problem?

Because the malloc'ed pointer isn't in the same spot in memory every
time, even though the requested number of bytes is the same.  That
looks like a slow leak in malloc to me, although it might be just the
way it's supposed to work.

> > I'll post a snippet from YAMD's symify'ed log file if you'd like,
> > but it's kind of large.
>
> If the program's run ends with a Page Fault and a crash, look at the
> spot where it crashed.  If there's no Page Fault, it's useless to post
> the log file here, because no one will be able to interpret it without
> knowing a lot about your program.
>
> > One of the things that I noticed was that it
> > wasn't malloc'ing in the same spot.  One time it would malloc at
> > 0x272eff4 and 0x2732fd8 (and deallocate them both properly).  The
> > next time it would malloc at 0x2736ff4 and 0x273afd8 (again,
> > deallocating them both properly).  There's nothing else in between
> > these two allocations and deallocations in the log file, either,
> > and they both happen to be 12 bytes and 40 bytes.  So why didn't
> > the malloc's happen in the same spot?
>
> Perhaps malloc couldn't merge the small allocations back into a larger
> block, before the other allocation comes.  Or maybe the smaller
> allocation belongs to another bucket.

Like I said, the requested number of bytes was the same as the previous
two allocations/deallocations.  So this isn't suspicious?

Damon Casale, damon AT redshift DOT com
YANK-HAIR (Yet Another Non-Known Hidden Arbitrary Invective Replicator)


Sent via Deja.com http://www.deja.com/
Before you buy.