nodejs crashed with SIGSEGV in libxmljs::XmlNode::~XmlNode()

[lanoxx]

I just got this error when executing my script. I am not sure whats causing it yet. There are only few things I could pull from the crash log:

StacktraceTop:
libxmljs::XmlNode::~XmlNode() () from /home/user/Code/libxmljs/build/Release/xmljs.node
libxmljs::XmlElement::~XmlElement() () from /home/user/Code/libxmljs/build/Release/xmljs.node

SegvReason: reading NULL VMA

Any idea?

[defunctzombie]

What is "my script"? What have you tried to debug? This report needs a lot more information.

[lanoxx]

I am still on it. When I know more, I will add it here. Its not so easy, there is no exception in nodejs it just fishes with error code 139 and thats it.

Edit: Error code 139 means SIGSEGV

[lanoxx]

Ok, I can give some more information. I have this loop:

for (var i = 3; i < 7; i++) {
    var conversionObject = conversionList[i];
    console.log('Converting: ' + conversionObject.source);
    converter.convertXml(conversionObject);
}

The function convertXml performs some transformation of the XML document and writes it to a file. If I limit the loop indices to a small number (e.g. two or three), then it works, but when I increase the loop indices to a higher number, then the node process finishes with exit code 139. If I invoke the script separately and convert one file at a time, then all files are converted without error.

[lanoxx]

Finally managed to get debug build and a meaning full stacktrace:

Program received signal SIGSEGV, Segmentation fault.
0x00007ffff57efa55 in libxmljs::XmlNode::~XmlNode (this=0x7c8870, __in_chrg=<optimized out>) at ../src/xml_node.cc:205
205     XmlDocument* doc = static_cast<XmlDocument*>(xml_obj->doc->_private);
(gdb) p xml_obj 
$1 = (xmlNode *) 0x7f2a08
(gdb) p xml_obj->doc
$2 = (_xmlDoc *) 0x41    <--- this looks strange to me
(gdb) p xml_obj->doc->_private
Cannot access memory at address 0x41

For future reference. In the Makefile one has to add the --debug argument to the node-gyp configure and node-gyp build commands and then run make clean all.

[lanoxx]

I fixed this temporarily but just commenting out most of the XmlNode destructor. I am thinking that my bug might actually be the same as #163. Anyway this should really be investigated and fixed, since it makes an otherwise very nice library unusable for larger projects.

[lanoxx]

Here is another one, this time I am getting SIGABRT:

Program received signal SIGABRT, Aborted.
0x00007ffff60adf77 in __GI_raise (sig=sig@entry=6) at ../nptl/sysdeps/unix/sysv/linux/raise.c:56
56  ../nptl/sysdeps/unix/sysv/linux/raise.c: No such file or directory.
(gdb) backtrace 
#0  0x00007ffff60adf77 in __GI_raise (sig=sig@entry=6) at ../nptl/sysdeps/unix/sysv/linux/raise.c:56
#1  0x00007ffff60b15e8 in __GI_abort () at abort.c:90
#2  0x00007ffff60eb4fb in __libc_message (do_abort=do_abort@entry=2, fmt=fmt@entry=0x7ffff61ff240 "*** Error in `%s': %s: 0x%s ***\n")
at ../sysdeps/unix/sysv/linux/libc_fatal.c:199
#3  0x00007ffff60f7996 in malloc_printerr (ptr=0x7e26f0, str=0x7ffff61ff3e0 "free(): invalid next size (fast)", action=3) at malloc.c:4923
#4  _int_free (av=<optimized out>, p=0x7e26e0, have_lock=0) at malloc.c:3779
#5  0x00007ffff57edb52 in libxmljs::XmlElement::~XmlElement (this=0x7e26f0, __in_chrg=<optimized out>) at ../src/xml_element.h:10
#6  0x0000000000428316 in node::ObjectWrap::WeakCallback(v8::Persistent<v8::Value>, void*) ()

Am I the only one who has such grave issues with the memory management of this library?

[defunctzombie]

@lanoxx probably, yes. It all depends on what you are trying to do. Your best bet is to post a simple script that shows the memory failure. You may be using parts of the bindings that are not commonly used or well tested. There are many uses of this library that present no segfaults. I use this library in production for web scraping and don't get segfaults.

[polotek]

I believe this is part of the long standing bug in #163. If we fix that, we should close this unless it can be reproduced.

[teleological]

I agree that this looks like #163. Since that issue was corrected by #323, I think this issue can be closed.

[rchipka]

I agree, this issue is pretty likely to be fixed and we can't test it because no tests were provided.