segfault of interpreter (possibly related to libxml-ruby)
I get a segfault of interpreter in some code of libxml-ruby extension. It is very susceptible to slight changes of my script, even totally unrelated to libxml-ruby, so I report it here.
Segfault is reproducible 90% of times on 2 different computers with different linux distros. Segfault message is attached as well as the code and data needed to reproduce.
Steps to reproduce:
- gem install libxml-ruby
- untar the archive, cd into libxml-ruby-bug/test directory
- run ../crash.rb
- wait a bit
2a. If ../crash.rb doesn't fail, try ../full_script.rb (more messy code, but segfaults every time for me).
The crash.rb code is truncated a bit till it started to be sensitive even to such changes like removing of an empty, unused method. Unfortunately it is still large.
The script processes few sets of xml files. It doesn't crash when run on single set (or I didn't found such a set). The order of xmls processed also matters.
My system info:
gentoo distro, ruby interpreter installed from distro, libxml-ruby (2.3.3) installed with gem; libxml2 version: 2.8.0
gcc (Gentoo 4.5.3-r2 p1.5, pie-0.4.7) 4.5.3
CFLAGS="-march=native -O2 -pipe"
#2 [ruby-core:48837] Updated by mame (Yusuke Endoh) over 5 years ago
- Status changed from Open to Third Party's Issue
- Assignee set to authorNari (Narihiro Nakamura)
- Target version set to 2.0.0
This is very subtle bug.
libxml makes sure to free a object by writing NULL to the entries,
which breaks Ruby internal finalizing list.
Applying the following patch to libxml fixes the issue in my
But because I'm not familiar with libxml internal, the fix may not
be appropriate. Could you contact on libxml developer(s)?
diff --git a/ext/libxml/ruby_xml_node.c b/ext/libxml/ruby_xml_node.c
index 926875c..174d17d 100644
@@ -50,8 +50,6 @@ static void rxml_node_deregisterNode(xmlNodePtr xnode)
try to free the node a second time. */
VALUE node = (VALUE) xnode->_private;
RDATA(node)->data = NULL;
- RDATA(node)->dfree = NULL;
- RDATA(node)->dmark = NULL; } }
Yusuke Endoh firstname.lastname@example.org