[ILUG] cool debugging info...

[valen at tuatha.org]

 This is one of those little features that you never hear about....anyone
know many more ?

Kate

----- Forwarded message from Havoc Pennington <hp at redhat.com> -----

X-From_: gtk-app-devel-list-request at redhat.com  Mon Aug 23 09:01:08 1999
X-From_: gtk-app-devel-list-request at redhat.com  Sun Aug 22 23:32:45 1999
Delivered-To: valen at redbrick.dcu.ie
X-Authentication-Warning: icon.labs.redhat.com: hp owned process doing -bs
Date: Sun, 22 Aug 1999 18:31:59 -0400 (EDT)
From: Havoc Pennington <hp at redhat.com>
X-Sender: hp at icon.labs.redhat.com
To: gtk-app-devel-list <gtk-app-devel-list at redhat.com>
Subject: Re: casting causing a core dump
Reply-To: gtk-app-devel-list at redhat.com
X-Mailing-List: <gtk-app-devel-list at redhat.com> archive/latest/3207
X-URL: http://www.redhat.com


Hi,

What you're seeing is pretty standard. In C if you are corrupting memory
you'll generally get crashes at random times, and crashes will appear and
disappear as you change random aspects of the program (because memory
layout changes, or the exact pattern of calls to malloc/free changes).

On glibc 2 systems (i.e. recent Linux) you can set the MALLOC_CHECK_
environment variable to 2:

$ MALLOC_CHECK_=2 progname

This will call abort() if you free a pointer twice. Electric Fence will
tell you if you overwrite memory you don't own. Those are the two best
memory debugging tools. However, just carefully checking your code is
often faster than fooling with efence. Check the docs and make sure all
your assumptions are valid.

Another tactic is what I call "#if 0 binary search" in which you use #if
0/#endif pairs to comment out hunks of your program until you comment out
the buggy part, then start commenting sub-hunks of the buggy hunk, etc.,
until you find the single line whose presence makes the bug happen. Of
course see the first paragraph of this mail for the problem with this
approach; if your bug is systemic or a heisenbug it won't work. But it can
work if your bug is a single bad free() or something.

Havoc



-- 
         To unsubscribe: mail gtk-app-devel-list-request at redhat.com with 
                       "unsubscribe" as the Subject.

	Mailing list concerns should be mailed to <listmaster at redhat.com>


----- End forwarded message -----