…t my recent inability to concentrate.
…path when adding files to the gem." This reverts commit a330f14.
…n adding files to the gem.
…ree, so I'm just going to give up and add `.gemtest` to the repo.
… registering a gc mark function. Partly fixes #439.
Nokogiri::XML::Document or the path of an existing file. Previously, passing in any other string would fail silently. For example, if rendered XML was passed in as a string, it would simply return an empty list of errors. Now an ArgumentError will be thrown.
…:Document. Closes #452
…X,H,XH}TML Conflicts: CHANGELOG.rdoc
If an IO object returns a string that is longer than expected, io_read_callback() writes past the limit of the buffer and crashes the interpreter. This patch checks against the size of our buffer before copying the data over. I can't really think of a case where an IO object would do something this silly, but seems like a good practice anyways.
This example will use up all system memory: require 'nokogiri' class BadIO def read(*args) raise 'hell' end end 100000000.times do Nokogiri::XML.parse(BadIO.new) rescue nil end The example above is obscure, but imagine an HTTP object raising TimeoutError. Nokogiri leaks memory every time this happens. I became suspicious of this when looking at ext/nokogiri/xml_io.c. io_read_callback() is invoked in the middle of some libxml operation, which may not behave well when a ruby exception is thrown and it gets interrupted. It seems that the safe way to handle this is to wrap the method call in rb_rescue. Note that the same applies to io_write_callback() in xml_io.c. Although I did not notice a memory leak with io_write_callback(), wrapping with rb_rescue() seems like the correct thing to do in both cases. A side effect of this fix is that IO errors will be silently discarded.
instead of being converted to CSS. This seems like a reasonable bit of XPath and our users have tried it many, many times. Might want to consider search(".") as XPath instead of CSS also. However, this was left out.