[lxml-dev] Tracking down bugs
lxml occasionally goes crashing on me, with an error message and backtrace like the one below. Usually, the same program runs just fine if I try again. What can I do to track down the cause? *** glibc detected *** python: free(): invalid pointer: 0x0a0388cb *** ======= Backtrace: ========= /lib/libc.so.6[0x1d3b16] /lib/libc.so.6(cfree+0x90)[0x1d7070] /usr/lib/libxml2.so.2(xmlNodeSetName+0xa5)[0x68fc0c5] /home/stp02/salo/lib/python/lxml-2.1.2-py2.4-linux-i686.egg/lxml/etree.so[0x3b988f] /usr/lib/libpython2.4.so.1.0[0x5437d83] /usr/lib/libpython2.4.so.1.0(PyObject_GenericSetAttr+0x104)[0x5455b84] /usr/lib/libpython2.4.so.1.0(PyObject_SetAttr+0xbb)[0x54561db] /usr/lib/libpython2.4.so.1.0(PyEval_EvalFrame+0x2d51)[0x548cd91] /usr/lib/libpython2.4.so.1.0(PyEval_EvalCodeEx+0x896)[0x548fc76] /usr/lib/libpython2.4.so.1.0(PyEval_EvalCode+0x63)[0x548fd03] /usr/lib/libpython2.4.so.1.0[0x54acad8] /usr/lib/libpython2.4.so.1.0(PyRun_SimpleFileExFlags+0x198)[0x54ae1e8] /usr/lib/libpython2.4.so.1.0(PyRun_AnyFileExFlags+0x7a)[0x54ae8ca] /usr/lib/libpython2.4.so.1.0(Py_Main+0xb85)[0x54b52d5] python(main+0x32)[0x80485b2] /lib/libc.so.6(__libc_start_main+0xdc)[0x180dec] python[0x80484c1] -- filip salomonsson
Hi, thanks for the report. Filip Salomonsson wrote:
lxml occasionally goes crashing on me, with an error message and backtrace like the one below. Usually, the same program runs just fine if I try again. What can I do to track down the cause?
First of all, use the latest released (!) version of lxml and build it without having Cython installed and with debug symbols enabled (add "-g3" to your CFLAGS) so that the stack trace shows line numbers that can be looked up in the released sources. Then, install valgrind and try to make your program crash under valgrind control. Valgrind usually gives pretty accurate information about the origin of a bad memory location, so that's a lot more informative than a bare stack trace. There is a command line in the Makefile (make valtest) that you can use to find the appropriate options. Stripping down your program to a shorter snippet that shows the crash more or less reliably is a very good way to track down the circumstances that are required to trigger the problem. In the best case, you end up with a short test case that we can add to lxml's test suite to make sure the problem never comes back. Lastly, if you know how to use gdb and can investigate a bit more, any further hints that you find can be helpful in tracking down the problem. Thanks, Stefan
On Thu, Dec 4, 2008 at 15:37, Stefan Behnel <stefan_ml@behnel.de> wrote:
First of all, use the latest released (!) version of lxml and build it without having Cython installed and with debug symbols enabled (add "-g3" to your CFLAGS)
Then, install valgrind and try to make your program crash under valgrind control.
Excellent; thanks! I'll try that and see what I can find. (Hadn't noticed 2.1.3, really - I'll go get that regardless.)
Stripping down your program to a shorter snippet that shows the crash more or less reliably is a very good way to track down the circumstances that are required to trigger the problem.
Sure will - if and when I'm able to provoke a repeatable crash. It all seems annoyingly random so far.
Lastly, if you know how to use gdb and can investigate a bit more, any further hints that you find can be helpful in tracking down the problem.
I'm afraid gdb is mostly black voodoo magic to me so far, but I'll probably try to dive into it if I get to the point where that seems useful. Thank you, Filip (If I didn't have lxml, I think my job would be really tedious, so thanks for that too!)
participants (2)
-
Filip Salomonsson -
Stefan Behnel