From:	dcasale AT my-deja DOT com
Newsgroups:	comp.os.msdos.djgpp
Subject:	Re: Debugger that can detect buffer overruns?
Date:	Tue, 21 Nov 2000 20:09:23 GMT
Organization:	Deja.com - Before you buy.
Lines:	54
Message-ID:	<8vekpc$3es$1@nnrp1.deja.com>
References:	<Pine DOT SUN DOT 3 DOT 91 DOT 1001121103130 DOT 7635H-100000 AT is>
NNTP-Posting-Host:	199.249.234.30
X-Article-Creation-Date:	Tue Nov 21 20:09:23 2000 GMT
X-Http-User-Agent:	Mozilla/4.0 (compatible; MSIE 5.5; Windows 98)
X-Http-Proxy:	1.1 x57.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 <Pine DOT SUN DOT 3 DOT 91 DOT 1001121103130 DOT 7635H-100000 AT is>,
  djgpp AT delorie DOT com wrote:
>
> On Mon, 20 Nov 2000 dcasale AT my-deja DOT com wrote:
>
> > I just noticed that the malloc data structures are all declared
> > static.  That means I'll have to change them to non-static and
> > recompile the library so that the heap walker will have access to
> > them.
>
> Alternatively, you could add a bunch of small functions to malloc.c
> which will return the necessary information about those internal data
> structures.  This would allow to access the information without risk
> of corrupting it via some programmatic error.
>
> I think it pays off to think data encapsulation even though this is
> not C++ ;-).

True.  Anyway, after I sent this post, I wondered how YAMD was able to
access this information, so I went and looked at the code.  Apparently
it doesn't.  It wraps malloc instead so that it doesn't need to have
access to these static variables.  I can't quite figure out _how_ it's
wrapping malloc, but whatever.

I'm still planning on writing a heap walker for future use, but I think
I'll shelve this project for now.  You see, I found the bug.

The problem was that I didn't read the YAMD documentation closely
enough, or else I would have realized that there were more detailed
logging levels.  Level 2 and level 3 both told me that I was deleting a
pointer twice.  I had made it a point to 0xDEADBEEF every pointer after
I deleted it, but this was an instance where that practice didn't
help.  I had passed a pointer to a string to an object.  Both the
caller and the called function ended up deleting their reference to the
object.  Woops.

I wish level 1 -- the default logging level -- would have displayed
this information.  (In other words, level 1 = ERROR, level 2 = WARNING,
level 3 = INFO, the reverse of what it is now.)  It would have made
things so much easier, and it would have taken about a week less than
it did to debug this problem.  User friendly debuggers are a _good_
thing!  :-)

In any case, thanks for all the help, everyone.  Now I can go on doing
what they pay me to do:  write buggy code so I can fix it.  ^_-  (Just
kidding!)

Damon Casale, damon AT WRONG DOT redshift DOT com (remove the obvious)
Looking for some "closure" on this problem...by shooting the monitor!
(Watch the movie "Analyze THIS!" to get the joke.)


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

- Raw text -