> I've found a problem with the Ruby interpreter, wherein the
> interpreter seg faults.  I have not found a way to reliably
> reproduce this; like the Great White Shark, I've only seen it
> reproduce in the wild.  I hesitate, therefore, to submit a formal
> bug report.
> 
> However, I have noticed that certain situations can increase the
> possibility of these segfaults occurring.  I believe it has to do
> with the actual internal translation of source to execution.  Hmm.
> That's pretty obscure.  Try this:
> 
> In cases where Ruby code re-defines the same method several times in
> a row, it is more likely that Ruby will segfault at some obscure
> point in the program. It also seems to be aggravated by threaded
> code.
> 
> With the same Ruby VM version, and the same version of an
> application running on two different machines, one may suddenly
> exhibit the problem, and the other won't.  And then the one that was
> having the problem may not have the problem the next morning.
> 
> I know how frustrating it is to have to track down no-see-ums.  Is
> this something you're aware of?  Have observed?
> 
> I'm curious, because I get occasional bug reports about seg-faults
> that *I* can't reproduce, and I don't know what to tell users.

In the unit tests for libxml, I think I've pushed things to SEGV land
with the do_hash() macro during cleanup when it can't determine the
classname of an object.  Does this seem plausible?  I'm not sure if
I'm running across an instance of libxml trodding on Ruby's memory or
what the problem is, but, all of a sudden, I'm getting SEGV'ing with
my unit tests.  I'm hoping that by backing down the number of unit
tests and seeing the problem disappear, but no promises.  Any chance
you can get a core file from your users?  And do you know if this is
something that's happening in cleanup or the GC of old objects?  -sc

-- 
Sean Chittenden