[ale] C++ Debuggery and the Path of Destruction

[Joe Knapka]

I've found njamd to be a decent tool for catching various kinds of
heap bogosity. However, it is absolutely critical (and not very well
documented) that when using njamd with C++ code, one define the
GLIBCPP_FORCE_NEW environment variable. If you don't, every invocation
of operator new appears to be a memory leak, because of the way the
libstdc++ allocator works. (Probably defining GLIBCPP_FORCE_NEW would
be required when using any memory debugger, but I'm not sure about
that.)

<http://sourceforge.net/projects/njamd>. It ships with Fedora Core 1,
and probably other distros as well.

However, if you've got any kind of real-time constraints, even fairly
soft ones, njamd is likely to make your code run way too slow.
Valgrind <http://valgrind.kde.org/> is reputed to be much faster, but
I haven't been able to get it to work (which may very well be a RTFM
issue on my part).

Cheers,

-- Joe

John Mills <johnmills at speakeasy.net> writes:

> ALErs -
> 
> I'm debugging some C++ compiled with gcc-[2.96|3.3], using gdb-5.2 in a
> RH-7.3 environment. One of my objects is segfaulting on destruction and
> I'm having trouble tracking it down. In fact, when I back up the fatal
> stack I find I'm in the destructor for an identical object which happens
> to be in a different class!
> 
> $%#$@^!!!
> 
> Naturally, I got a bit too clever and am handing pointers to one object
> whose targets were allocated in another, and the originator - not the user
> - must do the destruction.  I may be tripping on something like this, but
> I'm not finding where I jumped the rails.
> 
> Any suggestions how to track this self-administered wedgie down?
> 
> TIA.
> 
>  - John Mills
>    john.m.mills at alum.mit.edu
> 
> _______________________________________________
> Ale mailing list
> Ale at ale.org
> http://www.ale.org/mailman/listinfo/ale
> 
> 

-- 
"We sat and watched as this whole       <-- (Died Pretty -- "Springenfall")
 blue sky turned to black..."
... Re-defeat Bush in '04.
--
pub  1024D/BA496D2B 2004-05-14 Joseph A Knapka
     Key fingerprint = 3BA2 FE72 3CBA D4C2 21E4  C9B4 3230 94D7 BA49 6D2B
If you really want to get my attention, send mail to
jknapka .at. kneuro .dot. net.