From:	pjfarley AT banet DOT net (Peter J. Farley III)
Newsgroups:	comp.os.msdos.djgpp
Subject:	Re: Are there any memory debuggers other than MSS and YAMD?
Date:	Thu, 21 Oct 1999 14:58:10 GMT
Message-ID:	<380f2831.307867@news3.banet.net>
References:	<380e090b DOT 11437752 AT news3 DOT banet DOT net> <380E8714 DOT CF2B8E8C AT hmc DOT edu>
X-Newsreader:	Forte Free Agent 1.1/32.230
NNTP-Posting-Host:	32.100.252.27
X-Trace:	21 Oct 1999 14:58:37 GMT, 32.100.252.27
Organization:	Global Network Services - Remote Access Mail & News Services
Lines:	30
X-Complaints-To:	abuse AT prserv DOT net
To:	djgpp AT delorie DOT com
DJ-Gateway:	from newsgroup comp.os.msdos.djgpp
Reply-To:	djgpp AT delorie DOT com

Nate Eldredge <neldredge AT hmc DOT edu> wrote:
<Snipped>
>There is a package called Fortify, but I can't find it at the moment and
>haven't used it enough to know what it's like.

Thanks, Nate, I'll look for it myself.

>Please do email me regarding YAMD, though.

Will do.

<Snipped>
>Luckily the traceback is confined to two files, which may simplify
>things a bit.

Well, it's a mite more complex than that, I fear. The function that
actually calls libc malloc in the trace is defined in a header
included in the second source file.  And I suspect (and need a memory
debugger to track down and prove) that the real problem is potentially
elsewhere in the library code.  I think I'm looking at a memory
overrun or reuse of a freed memory allocation, and that could be
happening anywhere, not just in the files in the symified trace.  The
symify trace only shows me where the real problem causes a failure,
not necessarily where the problem originates.

I'll be talking to you.

----------------------------------------------------
Peter J. Farley III (pjfarley AT nospam DOT dorsai DOT org OR
                     pjfarley AT nospam DOT banet DOT net)

- Raw text -