From: "Ara.T.Howard" Date: 2004-09-17T22:24:51+09:00 Subject: Re: horribly impossible debugging task On Fri, 17 Sep 2004, Ruben wrote: > 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 actually both are options since the code in question simply manages a queue of jobs and the cost is about 1000th the actual work. i'm used valgrind and purify before with some success. i had a really hard to track down bug about a year ago and ended up needing valgrind, purify, and dmalloc to track it down. these are good suggestions as i'd forgotten about them. it'll be pretty tough to set up but possible. this is getting a bit OT now so any responders should probably ping me offline unless anyone has anything specific to ruby regarding closing all file descriptors after a fork and related bugs. kind regards. -a -- =============================================================================== | EMAIL :: Ara [dot] T [dot] Howard [at] noaa [dot] gov | PHONE :: 303.497.6469 | A flower falls, even though we love it; | and a weed grows, even though we do not love it. | --Dogen ===============================================================================