Hi, We are using lxml in several of our applications with Python 2.6 and from time to time, the application stops responding after a segmentation fault error, and this kind of backtrace: *Jul 1 15:35:01 server4 httpd: *** glibc detected *** /usr/sbin/apache2: malloc(): smallbin double linked list corrupted: 0x00007f583a03f500 **** *Jul 1 15:35:01 server4 httpd: ======= Backtrace: =========* *Jul 1 15:35:01 server4 httpd: /lib/libc.so.6(+0x77806)[0x7f58376c2806]* *Jul 1 15:35:01 server4 httpd: /lib/libc.so.6(+0x7bb39)[0x7f58376c6b39]* *Jul 1 15:35:01 server4 httpd: /lib/libc.so.6(__libc_malloc+0x6e)[0x7f58376c77de]* *Jul 1 15:35:01 server4 httpd: /usr/lib/libxml2.so.2(xmlInitParserCtxt+0x317)[0x7f58343f2887]* *Jul 1 15:35:01 server4 httpd: /usr/lib/libxml2.so.2(xmlNewParserCtxt+0x2c)[0x7f58343f2acc]* *Jul 1 15:35:01 server4 httpd: /usr/lib/python2.6/dist-packages/lxml/etree.so(+0x54eda)[0x7f5818db6eda]* *Jul 1 15:35:01 server4 httpd: /usr/lib/python2.6/dist-packages/lxml/etree.so(+0xddcf3)[0x7f5818e3fcf3]* *Jul 1 15:35:01 server4 httpd: /usr/lib/python2.6/dist-packages/lxml/etree.so(+0xab5ee)[0x7f5818e0d5ee]* *Jul 1 15:35:01 server4 httpd: /usr/lib/python2.6/dist-packages/lxml/etree.so(+0xb7d8e)[0x7f5818e19d8e]* *Jul 1 15:35:01 server4 httpd: /usr/lib/python2.6/dist-packages/lxml/etree.so(+0xb827e)[0x7f5818e1a27e]* *Jul 1 15:35:01 server4 httpd: /usr/lib/libpython2.6.so.1.0(PyEval_EvalFrameEx+0x51a0)[0x7f582face030]* *Jul 1 15:35:01 server4 httpd: /usr/lib/libpython2.6.so.1.0(PyEval_EvalFrameEx+0x5a98)[0x7f582face928]* *Jul 1 15:35:01 server4 httpd: /usr/lib/libpython2.6.so.1.0(PyEval_EvalCodeEx+0x920)[0x7f582facfd60]* *Jul 1 15:35:01 server4 httpd: /usr/lib/libpython2.6.so.1.0(+0x7dd60)[0x7f582fa55d60]* *Jul 1 15:35:01 server4 httpd: /usr/lib/libpython2.6.so.1.0(PyObject_Call+0x53)[0x7f582fa282e3]* *Jul 1 15:35:01 server4 httpd: /usr/lib/libpython2.6.so.1.0(PyEval_EvalFrameEx+0x3adf)[0x7f582facc96f]* *Jul 1 15:35:01 server4 httpd: /usr/lib/libpython2.6.so.1.0(PyEval_EvalCodeEx+0x920)[0x7f582facfd60]* *Jul 1 15:35:01 server4 httpd: /usr/lib/libpython2.6.so.1.0(+0x7dd60)[0x7f582fa55d60]* *Jul 1 15:35:01 server4 httpd: /usr/lib/libpython2.6.so.1.0(PyObject_Call+0x53)[0x7f582fa282e3]* *Jul 1 15:35:01 server4 httpd: /usr/lib/libpython2.6.so.1.0(+0x61cef)[0x7f582fa39cef]* *Jul 1 15:35:01 server4 httpd: /usr/lib/libpython2.6.so.1.0(PyObject_Call+0x53)[0x7f582fa282e3]* *Jul 1 15:35:01 server4 httpd: /usr/lib/libpython2.6.so.1.0(+0xb66dc)[0x7f582fa8e6dc]* *Jul 1 15:35:01 server4 httpd: /usr/lib/libpython2.6.so.1.0(PyObject_Call+0x53)[0x7f582fa282e3]* *Jul 1 15:35:01 server4 httpd: /usr/lib/libpython2.6.so.1.0(PyEval_CallObjectWithKeywords+0x43)[0x7f582fac8193] * *Jul 1 15:35:01 server4 httpd: /usr/lib/apache2/modules/mod_wsgi.so(+0x12fdb)[0x7f582fe9bfdb]* *Jul 1 15:35:01 server4 httpd: /usr/lib/apache2/modules/mod_wsgi.so(+0x17eed)[0x7f582fea0eed]* *Jul 1 15:35:01 server4 httpd: /usr/lib/libapr-1.so.0(+0x29eb3)[0x7f5837c14eb3]* *Jul 1 15:35:01 server4 httpd: /lib/libpthread.so.0(+0x69ca)[0x7f58379d49ca]* *Jul 1 15:35:01 server4 httpd: /lib/libc.so.6(clone+0x6d)[0x7f5837731cdd]* ----------------- *Jul 11 10:44:48 server4 httpd: *** glibc detected *** /usr/sbin/apache2: munmap_chunk(): invalid pointer: 0x00007f3968b8cb68 **** *Jul 11 10:44:48 server4 httpd: ======= Backtrace: =========* *Jul 11 10:44:48 server4 httpd: /lib/libc.so.6(+0x77806)[0x7f39789dd806]* *Jul 11 10:44:48 server4 httpd: /usr/lib/libxml2.so.2(xmlResetError+0x22)[0x7f39755038e2]* *Jul 11 10:44:48 server4 httpd: /usr/lib/libxml2.so.2(__xmlRaiseError+0x237)[0x7f3975504e07]* *Jul 11 10:44:48 server4 httpd: /usr/lib/libxml2.so.2(__xmlSimpleError+0x6b)[0x7f397550543b]* *Jul 11 10:44:48 server4 httpd: /usr/lib/libxml2.so.2(xmlParserInputBufferGrow+0x16b)[0x7f397553271b]* *Jul 11 10:44:48 server4 httpd: /usr/lib/libxml2.so.2(xmlParserInputGrow+0x4c)[0x7f397550739c]* *Jul 11 10:44:48 server4 httpd: /usr/lib/libxml2.so.2(+0x3bd52)[0x7f397550bd52]* *Jul 11 10:44:48 server4 httpd: /usr/lib/libxml2.so.2(xmlParseDocument+0x4b8)[0x7f39755204c8]* *Jul 11 10:44:48 server4 httpd: /usr/lib/libxml2.so.2(+0x505c5)[0x7f39755205c5]* *Jul 11 10:44:48 server4 httpd: /usr/lib/python2.6/dist-packages/lxml/etree.so(+0x8fab0)[0x7f3958ad8ab0]* *Jul 11 10:44:48 server4 httpd: /usr/lib/python2.6/dist-packages/lxml/etree.so(+0x2daa0)[0x7f3958a76aa0]* *Jul 11 10:44:48 server4 httpd: /usr/lib/python2.6/dist-packages/lxml/etree.so(+0x2ddc9)[0x7f3958a76dc9]* *Jul 11 10:44:48 server4 httpd: /usr/lib/python2.6/dist-packages/lxml/etree.so(+0xc26f0)[0x7f3958b0b6f0]* *Jul 11 10:44:48 server4 httpd: /usr/lib/python2.6/dist-packages/lxml/etree.so(+0xc431e)[0x7f3958b0d31e]* *Jul 11 10:44:48 server4 httpd: /usr/lib/libpython2.6.so.1.0(PyEval_EvalFrameEx+0x51a0)[0x7f397063b030]* *Jul 11 10:44:48 server4 httpd: /usr/lib/libpython2.6.so.1.0(PyEval_EvalCodeEx+0x920)[0x7f397063cd60]* *Jul 11 10:44:48 server4 httpd: /usr/lib/libpython2.6.so.1.0(+0x7dd60)[0x7f39705c2d60]* *Jul 11 10:44:48 server4 httpd: /usr/lib/libpython2.6.so.1.0(PyObject_Call+0x53)[0x7f39705952e3]* *Jul 11 10:44:48 server4 httpd: /usr/lib/libpython2.6.so.1.0(PyEval_EvalFrameEx+0x3adf)[0x7f397063996f]* *Jul 11 10:44:48 server4 httpd: /usr/lib/libpython2.6.so.1.0(PyEval_EvalCodeEx+0x920)[0x7f397063cd60]* *Jul 11 10:44:48 server4 httpd: /usr/lib/libpython2.6.so.1.0(+0x7dd60)[0x7f39705c2d60]* *Jul 11 10:44:48 server4 httpd: /usr/lib/libpython2.6.so.1.0(PyObject_Call+0x53)[0x7f39705952e3]* *Jul 11 10:44:48 server4 httpd: /usr/lib/libpython2.6.so.1.0(+0x61cef)[0x7f39705a6cef]* *Jul 11 10:44:48 server4 httpd: /usr/lib/libpython2.6.so.1.0(PyObject_Call+0x53)[0x7f39705952e3]* *Jul 11 10:44:48 server4 httpd: /usr/lib/libpython2.6.so.1.0(+0xb66dc)[0x7f39705fb6dc]* *Jul 11 10:44:48 server4 httpd: /usr/lib/libpython2.6.so.1.0(PyObject_Call+0x53)[0x7f39705952e3]* *Jul 11 10:44:48 server4 httpd: /usr/lib/libpython2.6.so.1.0(PyEval_CallObjectWithKeywords+0x43)[0x7f3970635193] * *Jul 11 10:44:48 server4 httpd: /usr/lib/apache2/modules/mod_wsgi.so(+0x12fdb)[0x7f3970a08fdb]* *Jul 11 10:44:48 server4 httpd: /usr/lib/apache2/modules/mod_wsgi.so(+0x17eed)[0x7f3970a0deed]* *Jul 11 10:44:48 server4 httpd: /usr/lib/libapr-1.so.0(+0x29eb3)[0x7f3978f2feb3]* *Jul 11 10:44:48 server4 httpd: /lib/libpthread.so.0(+0x69ca)[0x7f3978cef9ca]* *Jul 11 10:44:48 server4 httpd: /lib/libc.so.6(clone+0x6d)[0x7f3978a4ccdd]* Stopping apache and restarting it fix the issue, but we have no idea why this is happening. We use Unbuntu 10.10's package of lxml, which is version 2.2.4. *>>> print("%-20s: %s" % ('Python', sys.version_info))* *Python : (2, 6, 5, 'final', 0)* *>>> print("%-20s: %s" % ('lxml.etree', etree.LXML_VERSION))* *lxml.etree : (2, 2, 4, 0)* *>>> print("%-20s: %s" % ('libxml used', etree.LIBXML_VERSION))* *libxml used : (2, 7, 6)* *>>> print("%-20s: %s" % ('libxml compiled', etree.LIBXML_COMPILED_VERSION))* *libxml compiled : (2, 7, 6)* *>>> print("%-20s: %s" % ('libxslt used', etree.LIBXSLT_VERSION))* *libxslt used : (1, 1, 26)* *>>> print("%-20s: %s" % ('libxslt compiled', etree.LIBXSLT_COMPILED_VERSION))* *libxslt compiled : (1, 1, 26)* * * Do you have any idea of what could cause these issues ? I wonder if upgrading to a newer version of the library could change anything. Thanks in advance for any answer you could provide. Regards, B. _____________________ Brieuc SCHAFF +33609898260 _____________________
Brieuc SCHAFF, 12.07.2012 15:47:
We are using lxml in several of our applications with Python 2.6 and from time to time, the application stops responding after a segmentation fault error, and this kind of backtrace:
*Jul 1 15:35:01 server4 httpd: *** glibc detected *** /usr/sbin/apache2: malloc(): smallbin double linked list corrupted: 0x00007f583a03f500 **** *Jul 1 15:35:01 server4 httpd: ======= Backtrace: =========* *Jul 1 15:35:01 server4 httpd: /lib/libc.so.6(+0x77806)[0x7f58376c2806]* *Jul 1 15:35:01 server4 httpd: /lib/libc.so.6(+0x7bb39)[0x7f58376c6b39]* *Jul 1 15:35:01 server4 httpd: /lib/libc.so.6(__libc_malloc+0x6e)[0x7f58376c77de]* *Jul 1 15:35:01 server4 httpd: /usr/lib/libxml2.so.2(xmlInitParserCtxt+0x317)[0x7f58343f2887]* *Jul 1 15:35:01 server4 httpd: /usr/lib/libxml2.so.2(xmlNewParserCtxt+0x2c)[0x7f58343f2acc]* *Jul 1 15:35:01 server4 httpd: /usr/lib/python2.6/dist-packages/lxml/etree.so(+0x54eda)[0x7f5818db6eda]* *Jul 1 15:35:01 server4 httpd: [...] *Jul 1 15:35:01 server4 httpd: /usr/lib/apache2/modules/mod_wsgi.so(+0x12fdb)[0x7f582fe9bfdb]* *Jul 1 15:35:01 server4 httpd: /usr/lib/apache2/modules/mod_wsgi.so(+0x17eed)[0x7f582fea0eed]* *Jul 1 15:35:01 server4 httpd: /usr/lib/libapr-1.so.0(+0x29eb3)[0x7f5837c14eb3]* *Jul 1 15:35:01 server4 httpd: /lib/libpthread.so.0(+0x69ca)[0x7f58379d49ca]* *Jul 1 15:35:01 server4 httpd: /lib/libc.so.6(clone+0x6d)[0x7f5837731cdd]*
-----------------
*Jul 11 10:44:48 server4 httpd: *** glibc detected *** /usr/sbin/apache2: munmap_chunk(): invalid pointer: 0x00007f3968b8cb68 **** *Jul 11 10:44:48 server4 httpd: ======= Backtrace: =========* *Jul 11 10:44:48 server4 httpd: /lib/libc.so.6(+0x77806)[0x7f39789dd806]* *Jul 11 10:44:48 server4 httpd: /usr/lib/libxml2.so.2(xmlResetError+0x22)[0x7f39755038e2]* *Jul 11 10:44:48 server4 httpd: /usr/lib/libxml2.so.2(__xmlRaiseError+0x237)[0x7f3975504e07]* *Jul 11 10:44:48 server4 httpd: /usr/lib/libxml2.so.2(__xmlSimpleError+0x6b)[0x7f397550543b]* *Jul 11 10:44:48 server4 httpd: /usr/lib/libxml2.so.2(xmlParserInputBufferGrow+0x16b)[0x7f397553271b]* *Jul 11 10:44:48 server4 httpd: /usr/lib/libxml2.so.2(xmlParserInputGrow+0x4c)[0x7f397550739c]* *Jul 11 10:44:48 server4 httpd: /usr/lib/libxml2.so.2(+0x3bd52)[0x7f397550bd52]* *Jul 11 10:44:48 server4 httpd: /usr/lib/libxml2.so.2(xmlParseDocument+0x4b8)[0x7f39755204c8]* *Jul 11 10:44:48 server4 httpd: /usr/lib/libxml2.so.2(+0x505c5)[0x7f39755205c5]* *Jul 11 10:44:48 server4 httpd: /usr/lib/python2.6/dist-packages/lxml/etree.so(+0x8fab0)[0x7f3958ad8ab0]* [...]
Stopping apache and restarting it fix the issue, but we have no idea why this is happening. We use Unbuntu 10.10's package of lxml, which is version 2.2.4.
*>>> print("%-20s: %s" % ('Python', sys.version_info))* *Python : (2, 6, 5, 'final', 0)* *>>> print("%-20s: %s" % ('lxml.etree', etree.LXML_VERSION))* *lxml.etree : (2, 2, 4, 0)* *>>> print("%-20s: %s" % ('libxml used', etree.LIBXML_VERSION))* *libxml used : (2, 7, 6)* *>>> print("%-20s: %s" % ('libxml compiled', etree.LIBXML_COMPILED_VERSION))* *libxml compiled : (2, 7, 6)* *>>> print("%-20s: %s" % ('libxslt used', etree.LIBXSLT_VERSION))* *libxslt used : (1, 1, 26)* *>>> print("%-20s: %s" % ('libxslt compiled', etree.LIBXSLT_COMPILED_VERSION))* *libxslt compiled : (1, 1, 26)* * * Do you have any idea of what could cause these issues?
First of all, you should make sure that this isn't due to the system running out of memory for some reason. The stack trace above might (!) hint at that possibility.
I wonder if upgrading to a newer version of the library could change anything.
Given how straight forward it is to builds lxml on Ubuntu, I'd just give the latest release a try. Stefan
Hi, 6 months after and trying several versions of lxml we are still facing the issue. 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 **** *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]* *Feb 12 10:35:58 server1.capcl httpd: /usr/lib/libxml2.so.2(+0x109093)[0x7f967a632093]* *Feb 12 10:35:58 server1.capcl httpd: /usr/lib/libxml2.so.2(+0x10855d)[0x7f967a63155d]* *Feb 12 10:35:58 server1.capcl httpd: /usr/lib/libxml2.so.2(+0x109093)[0x7f967a632093]* *Feb 12 10:35:58 server1.capcl httpd: /usr/lib/libxml2.so.2(+0x10855d)[0x7f967a63155d]* *Feb 12 10:35:58 server1.capcl httpd: /usr/lib/libxml2.so.2(+0x109093)[0x7f967a632093]* *Feb 12 10:35:58 server1.capcl httpd: /usr/lib/libxml2.so.2(+0x10855d)[0x7f967a63155d]* *Feb 12 10:35:58 server1.capcl httpd: /usr/lib/libxml2.so.2(xmlNodeDumpOutput+0xd5)[0x7f967a633c95]* *Feb 12 10:35:58 server1.capcl httpd: /usr/lib/libxslt.so.1(xsltSaveResultTo+0x330)[0x7f966c447ca0]* *Feb 12 10:35:58 server1.capcl httpd: /usr/lib/libxslt.so.1(xsltSaveResultToString+0xbb)[0x7f966c447f4b]* *Feb 12 10:35:58 server1.capcl httpd: /usr/lib/python2.6/dist-packages/lxml/etree.so(+0x50587)[0x7f965e694587]* *Feb 12 10:35:58 server1.capcl httpd: /usr/lib/python2.6/dist-packages/lxml/etree.so(+0x3b4b7)[0x7f965e67f4b7]* *Feb 12 10:35:58 server1.capcl httpd: /usr/lib/libpython2.6.so.1.0(_PyObject_Str+0x7b)[0x7f9675bdbf6b]* *Feb 12 10:35:58 server1.capcl httpd: /usr/lib/libpython2.6.so.1.0(PyObject_Str+0xa)[0x7f9675bdc06a]* *Feb 12 10:35:58 server1.capcl httpd: /usr/lib/libpython2.6.so.1.0(+0xa5277)[0x7f9675bea277]* *Feb 12 10:35:58 server1.capcl httpd: /usr/lib/libpython2.6.so.1.0(+0xad1a3)[0x7f9675bf21a3]* *Feb 12 10:35:58 server1.capcl httpd: /usr/lib/libpython2.6.so.1.0(PyObject_Call+0x53)[0x7f9675b954e3]* *Feb 12 10:35:58 server1.capcl httpd: /usr/lib/libpython2.6.so.1.0(PyEval_EvalFrameEx+0x48e1)[0x7f9675c3a9e1]* *Feb 12 10:35:58 server1.capcl httpd: /usr/lib/libpython2.6.so.1.0(PyEval_EvalFrameEx+0x5a98)[0x7f9675c3bb98]* *Feb 12 10:35:58 server1.capcl httpd: /usr/lib/libpython2.6.so.1.0(PyEval_EvalCodeEx+0x920)[0x7f9675c3cfd0]* *Feb 12 10:35:58 server1.capcl httpd: /usr/lib/libpython2.6.so.1.0(+0x7df90)[0x7f9675bc2f90]* *Feb 12 10:35:58 server1.capcl httpd: /usr/lib/libpython2.6.so.1.0(PyObject_Call+0x53)[0x7f9675b954e3]* *Feb 12 10:35:58 server1.capcl httpd: /usr/lib/libpython2.6.so.1.0(PyEval_EvalFrameEx+0x3adf)[0x7f9675c39bdf]* *Feb 12 10:35:58 server1.capcl httpd: /usr/lib/libpython2.6.so.1.0(PyEval_EvalCodeEx+0x920)[0x7f9675c3cfd0]* *Feb 12 10:35:58 server1.capcl httpd: /usr/lib/libpython2.6.so.1.0(+0x7df90)[0x7f9675bc2f90]* *Feb 12 10:35:58 server1.capcl httpd: /usr/lib/libpython2.6.so.1.0(PyObject_Call+0x53)[0x7f9675b954e3]* *Feb 12 10:35:58 server1.capcl httpd: /usr/lib/libpython2.6.so.1.0(+0x61f1f)[0x7f9675ba6f1f]* *Feb 12 10:35:58 server1.capcl httpd: /usr/lib/libpython2.6.so.1.0(PyObject_Call+0x53)[0x7f9675b954e3]* *Feb 12 10:35:58 server1.capcl httpd: /usr/lib/libpython2.6.so.1.0(+0xb692c)[0x7f9675bfb92c]* *Feb 12 10:35:58 server1.capcl httpd: /usr/lib/libpython2.6.so.1.0(PyObject_Call+0x53)[0x7f9675b954e3]* *Feb 12 10:35:58 server1.capcl httpd: /usr/lib/libpython2.6.so.1.0(PyEval_CallObjectWithKeywords+0x43)[0x7f9675c35403] * *Feb 12 10:35:58 server1.capcl httpd: /usr/lib/apache2/modules/mod_wsgi.so(+0x12fdb)[0x7f9676008fdb]* *Feb 12 10:35:58 server1.capcl httpd: /usr/lib/apache2/modules/mod_wsgi.so(+0x17eed)[0x7f967600deed]* *Feb 12 10:35:58 server1.capcl httpd: /usr/lib/libapr-1.so.0(+0x29eb3)[0x7f967dd84eb3]* *Feb 12 10:35:58 server1.capcl httpd: /lib/libpthread.so.0(+0x69ca)[0x7f967db449ca]* *Feb 12 10:35:58 server1.capcl httpd: /lib/libc.so.6(clone+0x6d)[0x7f967d8a121d]* Have you ever heard of such behaviour ? I'm considering rebuilding apache, mod_wsgi and lxml in debug mode, maybe I'll know more. B. _____________________ Brieuc SCHAFF +33609898260 _____________________ On Sat, Jul 14, 2012 at 10:36 AM, Stefan Behnel <stefan_ml@behnel.de> wrote:
Brieuc SCHAFF, 12.07.2012 15:47:
We are using lxml in several of our applications with Python 2.6 and from time to time, the application stops responding after a segmentation fault error, and this kind of backtrace:
*Jul 1 15:35:01 server4 httpd: *** glibc detected *** /usr/sbin/apache2: malloc(): smallbin double linked list corrupted: 0x00007f583a03f500 **** *Jul 1 15:35:01 server4 httpd: ======= Backtrace: =========* *Jul 1 15:35:01 server4 httpd: /lib/libc.so.6(+0x77806)[0x7f58376c2806]* *Jul 1 15:35:01 server4 httpd: /lib/libc.so.6(+0x7bb39)[0x7f58376c6b39]* *Jul 1 15:35:01 server4 httpd: /lib/libc.so.6(__libc_malloc+0x6e)[0x7f58376c77de]* *Jul 1 15:35:01 server4 httpd: /usr/lib/libxml2.so.2(xmlInitParserCtxt+0x317)[0x7f58343f2887]* *Jul 1 15:35:01 server4 httpd: /usr/lib/libxml2.so.2(xmlNewParserCtxt+0x2c)[0x7f58343f2acc]* *Jul 1 15:35:01 server4 httpd: /usr/lib/python2.6/dist-packages/lxml/etree.so(+0x54eda)[0x7f5818db6eda]* *Jul 1 15:35:01 server4 httpd: [...] *Jul 1 15:35:01 server4 httpd: /usr/lib/apache2/modules/mod_wsgi.so(+0x12fdb)[0x7f582fe9bfdb]* *Jul 1 15:35:01 server4 httpd: /usr/lib/apache2/modules/mod_wsgi.so(+0x17eed)[0x7f582fea0eed]* *Jul 1 15:35:01 server4 httpd: /usr/lib/libapr-1.so.0(+0x29eb3)[0x7f5837c14eb3]* *Jul 1 15:35:01 server4 httpd: /lib/libpthread.so.0(+0x69ca)[0x7f58379d49ca]* *Jul 1 15:35:01 server4 httpd: /lib/libc.so.6(clone+0x6d)[0x7f5837731cdd]*
-----------------
*Jul 11 10:44:48 server4 httpd: *** glibc detected *** /usr/sbin/apache2: munmap_chunk(): invalid pointer: 0x00007f3968b8cb68 **** *Jul 11 10:44:48 server4 httpd: ======= Backtrace: =========* *Jul 11 10:44:48 server4 httpd: /lib/libc.so.6(+0x77806)[0x7f39789dd806]* *Jul 11 10:44:48 server4 httpd: /usr/lib/libxml2.so.2(xmlResetError+0x22)[0x7f39755038e2]* *Jul 11 10:44:48 server4 httpd: /usr/lib/libxml2.so.2(__xmlRaiseError+0x237)[0x7f3975504e07]* *Jul 11 10:44:48 server4 httpd: /usr/lib/libxml2.so.2(__xmlSimpleError+0x6b)[0x7f397550543b]* *Jul 11 10:44:48 server4 httpd: /usr/lib/libxml2.so.2(xmlParserInputBufferGrow+0x16b)[0x7f397553271b]* *Jul 11 10:44:48 server4 httpd: /usr/lib/libxml2.so.2(xmlParserInputGrow+0x4c)[0x7f397550739c]* *Jul 11 10:44:48 server4 httpd: /usr/lib/libxml2.so.2(+0x3bd52)[0x7f397550bd52]* *Jul 11 10:44:48 server4 httpd: /usr/lib/libxml2.so.2(xmlParseDocument+0x4b8)[0x7f39755204c8]* *Jul 11 10:44:48 server4 httpd: /usr/lib/libxml2.so.2(+0x505c5)[0x7f39755205c5]* *Jul 11 10:44:48 server4 httpd: /usr/lib/python2.6/dist-packages/lxml/etree.so(+0x8fab0)[0x7f3958ad8ab0]* [...]
Stopping apache and restarting it fix the issue, but we have no idea why this is happening. We use Unbuntu 10.10's package of lxml, which is version 2.2.4.
*>>> print("%-20s: %s" % ('Python', sys.version_info))* *Python : (2, 6, 5, 'final', 0)* *>>> print("%-20s: %s" % ('lxml.etree', etree.LXML_VERSION))* *lxml.etree : (2, 2, 4, 0)* *>>> print("%-20s: %s" % ('libxml used', etree.LIBXML_VERSION))* *libxml used : (2, 7, 6)* *>>> print("%-20s: %s" % ('libxml compiled', etree.LIBXML_COMPILED_VERSION))* *libxml compiled : (2, 7, 6)* *>>> print("%-20s: %s" % ('libxslt used', etree.LIBXSLT_VERSION))* *libxslt used : (1, 1, 26)* *>>> print("%-20s: %s" % ('libxslt compiled', etree.LIBXSLT_COMPILED_VERSION))* *libxslt compiled : (1, 1, 26)* * * Do you have any idea of what could cause these issues?
First of all, you should make sure that this isn't due to the system running out of memory for some reason. The stack trace above might (!) hint at that possibility.
I wonder if upgrading to a newer version of the library could change anything.
Given how straight forward it is to builds lxml on Ubuntu, I'd just give the latest release a try.
Stefan _________________________________________________________________ Mailing list for the lxml Python XML toolkit - http://lxml.de/ lxml@lxml.de https://mailman-mail5.webfaction.com/listinfo/lxml
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
participants (2)
-
Brieuc SCHAFF -
Stefan Behnel