Christopher, As far as I know, the problems are known and so (now) are the solutions. Anything prior to 0.5.1 has known bugs and anything prior to 0.5 (i.e. 0.3.x) has memory model flaws. As for the SEGV problems, and the release notes state this quite clearly, only Node, Document and Attr have been modified under the MEM2 branch. There are numerous other parts (Parser, Ns, etc) that still use the old model and may cause SEGV under duress (maybe even slight duress). The test failures you are seeing may originate from the unmodified parts, and it will likely be impossible to tell because the SEGV will happen inside the GC.
Your situation is defined by the modules you use. If you are using unmodified components, then you have risk. The time table for reducing that risk is on the scale of weeks. As for your options, REXML is much slower, and PHP is not Ruby. You have come along at a good time, because most of us have been suffering with these memory problems for a long time. Dan On Sep 6, 2007, at 20:22, Christopher J. Bottaro wrote: > On 9/5/07, Dan Janowski <[EMAIL PROTECTED]> wrote: >> libxml at rubyforge (http://rubyforge.org/projects/libxml/) >> >> A new packaged development release from the MEM2 branch (New Memory >> Model) is available: >> >> http://rubyforge.org/frs/?group_id=494&release_id=14239 >> >> Subversion tag available at (use svn checkout): >> >> http://libxml.rubyforge.org/svn/tags/MEM2-0_5_1 >> >> Release notes: >> http://rubyforge.org/frs/shownotes.php?release_id=14239 >> >> Notes: >> Fix child= to do implicit copy when rhs is not a root node. >> >> >> Changes: >> * ext/xml/ruby_xml_node.c: _child_set now performs implicit >> copy >> when adding a non-root node to another node, the return >> value is >> the new node. The return value is now the new node or the >> original if not copied. rb_warning when implicit copy >> done. added >> child_add to api so return value can be used after >> implicit copy. >> >> See ChangeLog for more details >> _______________________________________________ >> libxml-devel mailing list >> libxml-devel@rubyforge.org >> http://rubyforge.org/mailman/listinfo/libxml-devel >> > > Hey, > I'm kinda in a pickle. I recently convinced my work to move from our > internally developed PHP web framework to Rails. Our application is > very heavy on XML processing, including XSLT. I did a proof of > concept before we made the decision to go 100% with Rails and during > that proof of concept, I didn't run into a single problem with > libxml-ruby. > > Now that our entire team is on board for the Rails port and a lot more > code has been written, I'm seeing problems... and it's making my boss > very nervous. He asked me to do an assessment on whether we should a) > stick with libxml-ruby and hope that the bugs get ironed out (we have > a 2 month deadline before a major release), switch to REXML, or go > back to PHP (please god no). > > So I just have a few questions. > a) Are the problems known? > b) Are the solutions known? > c) If the answer to the two above questions is yes, what is a > realistic expectation for how long it will take to implement the > solutions and bug test them? > > Mainly I'm interested in a and b. Are you guys stabbing in the dark? > Or are the problems known and solutions developed and it's just a > matter of development time? > > What can I do to help? Let me describe what is happening. If we run > unit tests individually, they run fine, no errors, no crashes, they > exit normally. But if we run them all at once via rake:test:units, > then about 10-12% of them produce errors and usually the rake process > ends in a crash... sometimes with a stack trace, but most of the time > with a "[bug] segfault" message. > > Are those stack traces useful to you? I don't really know what to do > short of just sending you all our source code (how can you make sense > of the trace without seeing what we're trying to do?), but I doubt my > company would appreciate that... ;) > > Btw, these symptoms occur regardless of using 0.3.8.4 or 0.5.1. > > Thank you for the help, > -- Christopher > _______________________________________________ > libxml-devel mailing list > libxml-devel@rubyforge.org > http://rubyforge.org/mailman/listinfo/libxml-devel _______________________________________________ libxml-devel mailing list libxml-devel@rubyforge.org http://rubyforge.org/mailman/listinfo/libxml-devel
