This segfaulting of Syck has been discovered and eliminated.
Originally, I thought it was a problem in the functions which control
buffering IO.  Turns out that the lexer was hanging on to an old buffer
pointer (while lexing blocks, quoted scalars, plain scalars, and
comments) causing the buffer to become full and either segfault or throw
a parse error (depending on the type of node being parsed).

This affected any node whose content exceeded the default buffer size
(previously 16k).  I've reduced the default buffer size to 4k for now,
because I've discovered it's slightly faster on some systems for an
average-sized set of YAML documents.

Fix is committed to both Syck CVS (currently at 0.42) and Ruby CVS.
If you use the YAML module, I would truly appreciate the testing.
Thanks!

_why

why the lucky stiff (ruby-core / whytheluckystiff.net) wrote:
> Agh!  Sorry, I just noticed this message!
> 
> Richard Kilmer (rich / infoether.com) wrote:
> > 
> > Also, when running with yaml/syck loaded vs. not loaded the system incurs quite an 
> > overhead.  In a very CPU/Memory heavy script, the time was cut in half 
> > w/o yaml/syck loaded (5 minutes vs. 10 minutes).
> > 
> 
> Looks like we've got a pretty heavy memory leak.  Or are you saying that
> simply _loading_ the library (and not directly using it) was incurring
> cost?
> 
> > _why...please contact me directly and I can send you some YAML that 
> > will crash syck ;-)
> 
> Please do, right away!  I have just been made aware of leak in the
> parser's buffering code.  This could be related.  In any case, I want to
> get this solved immediately.
> 
> Anyone else have YAML that will crash Syck?  I'd like to have all the
> cases of such behavior to test against as I repair this.
> 
> _why
>