> |>  I can't reproduce, sorry
> 
> |$ time rubytest -F -i 0 -n xml_parser4
> |./tests/tc_xml_parser4.rb:12: [BUG] Segmentation fault
> |ruby 1.7.3 (2002-09-27) [i386-freebsd5]
> |Abort (core dumped)
> |68.013u 0.509s 1:23.42 82.1%    5+3350k 0+51io 0pf+0w
> 
> Unfortunately this runs forever on my machine without dumping core.
> No clue.

I was on a gentoo system and it seemed to core about 50% of the time
on the linux box.  :-( Did you try running the command a few times?  I
know it sounds hokey, but this really made a difference.  Are you
running with a stripped ruby interpreter?  From watching this crop up
and testing this on several systems, it looks like something that
crops up under memory constraints.  xml_parser4 is the least demanding
of all of the libxml tests...  I'm not convinced that if if you just
run 'rubytest -F -i 0' that the core is a result of a ruby bug vs a
libxml bug, but there's clearly something going on someplace and I'm
not sure where it's happening.  The current core dump I'm getting
right now, however, leads me to think that it's a ruby
problem... though I'm not 100% sure of that.

$ rubytest -i 0

> p.s.
> Some reports from valgrind is due to Ruby's conservative GC, which
> touch all C stack region.

That's what I figured.  Ruby's internals are far from simple so it
doesn't surprise me that valgrind choked or reported false positives.

-sc

-- 
Sean Chittenden