From: Ruben <Ruben.Vandeginste@...>
Date: 2004-09-17T20:57:51+09:00
Subject: Re: horribly impossible debugging task

At Fri, 17 Sep 2004 14:46:07 +0900,
Clifford Heath wrote:
> 
> Ara.T.Howard wrote:
> > i've isolated the bit of code that causes the core dumps to occur
> > ...
> > now heres the tricky bit.  the core dump doesn't happen here - it 
> > happens at some random time later, and then again sometimes it doesn't.
> 
> This sort of scenario is almost always caused by a memory corruption,
> either an array-out-of-bounds write causing corruption of the memory
> allocation arena, or a reference to an object that's been deleted.
> I've chased dozens of these up until five or so years ago, when I got
> my hands on a copy of Purify. It catches the corruption *at source*,
> and has become quite simply indispensable for this (and many other)
> tasks.
> 
> The world would be a better place if every developer used Purify on
> every release. Note that it's *not* the same as most "bounds checker"
> type tools; it actually maintains a parallel table of markers for
> every memory location, and *rewrites the machine instructions* for every
> memory reference so it can also check validity against the marker table.
> 
> It's quite simply the bee's knees if you must write in C or a similarly
> primitive language :-).
> 
> Clifford Heath.

Sounds like the same thing valgrind does (for free). It might be
interesting to try valgrind on this, if it's a memory related bug. The
downside is that running the code through valgrind will give you a
slowdown with a factor 30 to 60 (from personal experience). So, not
really an option if the bug only shows up after a couple of days...

Ruben