Segmentation fault in some rare cases #28
Comments
|
Interesting. Can't reproduce the segfault here locally. Valgrind has lots of stuff to complain, though. Will have to enable debug symbols and see which of these reports could be related to this. |
The above example does not cause an segfault on your environment? |
|
It didn't with node 4.1.1 in release mode, but it does now ith node 5.0.0 in debug mode. Not sure it's the version or build mode which is to blame. Might also be my other cpu usage, since it's likely related to asynchroneous execution. Running the thing through The instance indicated by gdb just now was somewhere in I'd say it's up to you whether you store JavaScript objects to the persistent storage and their contained native objects to additional members, or whether you use the persistent storage exclusively and unwrap objects from there during execution only. Either approach should work in my opinion, and the former should be less work in the short run. So I'd say take all the arguments to |
|
With this PR my test example is now working fine, but my real application with big xsl-files keeps throwing segfault on synthetic highload tests... |
|
Can you try some of this: cd node_modules/libxmljs-mt
node-gyp rebuild -d
ln -s Debug build/Release
cd -
node-gyp rebuild -dThis should enable debug symbols for libxmljs and node-libxslt. Hopefully this will give us a line number for the segfault. It would be even better if you could attach Of course, it would also be nice to have a small reproducing example, like the previous one, so I can try that out for myself. |
|
@gagern thank you for clarification of points to debug! require('segfault-handler').registerHandler('crash.log');
var libxslt = require('libxslt');
var xml = '<?xml version="1.0" encoding="utf-8"?>\n<root></root>';
var transform = function () {
libxslt.parseFile('./test.xsl', function (err, xslObject) {
xslObject.apply(xml, function (err, result) {});
});
}
var counter = 1e3;
while (counter--) {
transform();
}test.xsl <?xml version="1.0" encoding="utf-8"?>
<xsl:stylesheet version="1.0" xmlns:xsl="http://www.w3.org/1999/XSL/Transform">
<xsl:template match="/">
<xsl:apply-templates select="root" >
<xsl:with-param name="total">1000</xsl:with-param>
</xsl:apply-templates>
</xsl:template>
<xsl:template match="root">
<xsl:param name="current">1</xsl:param>
<xsl:param name="total" />
<xsl:value-of select="generate-id()" />
<xsl:if test="$current < $total">
<xsl:apply-templates select="../root">
<xsl:with-param name="current" select="$current + 1" />
<xsl:with-param name="total" select="$total" />
</xsl:apply-templates>
</xsl:if>
</xsl:template>
</xsl:stylesheet> |
|
I can reproduce this. This is part of a 1500+ frame stack trace. The depth of which might be contributing to the problem in some way I don't understand yet. Frame 2 happens at |
|
Not resolved, as indicated by #28 (comment) and subsequent comments. |
|
I'd guess that the remaining issue is because the stylesheet refers to the xml document from which it was constructed, but on the v8 level the stylesheet object doesn't preserve a reference to the xml document object. Note the comment in the
Well, that problem isn't restricted to the destructor alone; with enough memory pressure, the xml document will be gone by the time the stylesheet is used. I tried adding a |
|
@tornillo A pleasure. Looking forward to the next release here. |
Hi!
I have a project with a complex structure of xsl and xml data.
Production environment is not highload (less than 10 rps).
Segfault occurs for every 300-1000 request, but 100% when I try to run synthetic performance tests.
To reproduce this error, i've created a isolated example, in which the error occurs on different versions of Node (0.12, 4, 5), but more often on 4-5.
(libxslt is compiled from master to work with Node 4-5)
Error logs are different from run to run.
Log1:
Log2:
@gagern may be you can help with this strange error?:)
The text was updated successfully, but these errors were encountered: