Dan, I am only working with libxml through the TAP class. It is a single XML document being parsed with a moderate number of accesses to that document. All of the SEGV do have the garbage_collect line at approximately the same spot.
I started putting what I am doing together as a test case to see if I can reproduce the problems that way without the extra overhead of all the rails stuff. I'll finish that up tomorrow and pass that along to you if I can reproduce it that way. If I create a libxml document using the XML::Document.file method instead of the parser as I am doing now, should that be using all features that have been fixed? It creates an extra step of writing the string (which I retrieve from a rails TempFile object) to an intermediate file, but at least I could test to see if the parser is causing the problem that way. Thanks, Calvin Dan Janowski wrote: > Calvin, > > This may have nothing to do with the latest code changes. There are > still plenty of features that have not been fixed (like I just did > for xpath). The parser class is one. I looked at the _xpath_context > code and there does not appear to be much of an opportunity for > corruption there. > > Are you only working with libxml via the TAP class? Are you parsing a > lot of documents or doing a lot of access to few documents? If you > change the use pattern, does it change the frequency of segv? Do all > the SEGV have a garbage_collect at about this position? > > That being said, the parser is the next thing I will fix. It has some > particularly concerning code in it and would not be surprised if this > is from that. > > Dan > > > _______________________________________________ libxml-devel mailing list libxml-devel@rubyforge.org http://rubyforge.org/mailman/listinfo/libxml-devel
