Hi, Brieuc SCHAFF, 12.02.2013 10:51:
6 months after and trying several versions of lxml we are still facing the issue.
Sorry to hear that.
I've checked for the system memory consumption as per your recommendation but everything looks fine to me, plenty of memory available, I don't see any process consuming abnormally.
I've found a way to "trigger" the issue everytime. If I use apache reload command or graceful stop, the issue occurs.
*Feb 12 10:35:58 server1.capcl httpd: *** glibc detected *** /usr/sbin/apache2: munmap_chunk(): invalid pointer: 0x00007f9681b48f70 ****
This bit is interesting. It seems to crash on some mmap cleanup operation. What does your Apache setup look like? Do you use pre-forked processes?
*Feb 12 10:35:58 server1.capcl httpd: ======= Backtrace: =========* *Feb 12 10:35:58 server1.capcl httpd: /lib/libc.so.6(+0x78bb6)[0x7f967d830bb6]* *Feb 12 10:35:58 server1.capcl httpd: /usr/lib/libxml2.so.2(xmlResetError+0x34)[0x7f967a55c8e4]* *Feb 12 10:35:58 server1.capcl httpd: /usr/lib/libxml2.so.2(__xmlRaiseError+0x237)[0x7f967a55ddf7]* *Feb 12 10:35:58 server1.capcl httpd: /usr/lib/libxml2.so.2(__xmlSimpleError+0x6b)[0x7f967a55e42b]* *Feb 12 10:35:58 server1.capcl httpd: /usr/lib/libxml2.so.2(xmlBufferGrow+0xcd)[0x7f967a57b77d]* *Feb 12 10:35:58 server1.capcl httpd: /usr/lib/libxml2.so.2(xmlOutputBufferWriteEscape+0x2a8)[0x7f967a58b358]*
Ok, so it's serialising an XSLT result (as the further stack trace shows) and tries to report an error while doing so. Looking at xmlBufferGrow(), the only reason why it would report an error is because a realloc() failed. So at least this stack trace definitely hints at some memory related problem. Are you sure there is no memory limit on the Apache processes or something like that? Maybe it's trying to serialise a large document and your server has run into excessive memory fragmentation. In that case, realloc() may not be able to reuse the current buffer and needs to allocate a substantially larger one in addition(!) to the existing one in order to copy over the current data. That might trigger a peak in memory allocation that would be hard to see before the (for whatever reason) immediately resulting crash. That being said, I assume you read through this already? http://lxml.de/FAQ.html#my-program-crashes-when-run-with-mod-python-pyro-zop... It's certainly a bit outdated, but I kept dumping things in there as they came up, so it might still give you an idea what else you could try. Stefan