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