[lxml-dev] lxml 1.3 coming up - core dump

[Stefan Behnel]

jholg at gmx.de wrote:
> My first try on running the tests produce a reproduceable core, however:
> 
> $ make test PYTHON=python2.4
> python2.4 setup.py  build_ext -i
> Building lxml version 1.3-44288
> running build_ext
> python2.4 test.py -p -v 
> 
> TESTED VERSION:
>     Python:            (2, 4, 4, 'final', 0)
>     lxml.etree:        (1, 3, 0, 44288)
>     libxml used:       (2, 6, 27)
>     libxml compiled:   (2, 6, 27)
>     libxslt used:      (1, 1, 20)
>     libxslt compiled:  (1, 1, 20)
> 
>  552/552 (100.0%): Doctest: xpathxslt.txt                                                    
> ----------------------------------------------------------------------
> Ran 552 tests in 1.264s
> 
> OK
> make: *** [test_inplace] Illegal Instruction (core dumped)
[...]
> (gdb) where
> #0  0x50e070 in ?? ()
> #1  0x576b0 in tupletraverse (o=0x3943cc, visit=0xb6c28 <visit_decref>, arg=0x0)
>     at Objects/tupleobject.c:443
> #2  0xb62fc in collect (generation=2) at Modules/gcmodule.c:294
> #3  0xb6a68 in PyGC_Collect () at Modules/gcmodule.c:1196
> #4  0xadf28 in Py_Finalize () at Python/pythonrun.c:353
> #5  0xafefc in Py_Exit (sts=0) at Python/pythonrun.c:1593
> #6  0xaeb70 in handle_system_exit () at Python/pythonrun.c:1050
> #7  0xaeb9c in PyErr_PrintEx (set_sys_last_vars=1) at Python/pythonrun.c:1060
> #8  0xafea8 in PyErr_Print () at Python/pythonrun.c:974
> #9  0xae5f8 in PyRun_SimpleFileExFlags (fp=0xffffffff, filename=0xffbef8b6 "test.py", 
>     closeit=1, flags=0xffbef5d8) at Python/pythonrun.c:873
> #10 0xaf8cc in PyRun_AnyFileExFlags (fp=0x12a938, filename=0xffbef8b6 "test.py", closeit=1, 
>     flags=0xffbef5d8) at Python/pythonrun.c:673
> #11 0x1e9ec in Py_Main (argc=4, argv=0xffbef75c) at Modules/main.c:493
> #12 0x1dfe4 in main (argc=4, argv=0xffbef75c) at ./Modules/python.c:23
> (gdb) 

Yes, I've seen that before and it's reproduceable if it occurs. So far, I have
no idea where this might come from. The "tupletraverse" makes it look like a
GC crash when collecting Python (!) references, but I really don't see where
this might be triggered in lxml. All problems we had so far were related to
libxml2 data being double freed and stuff.

I'd be happy about any idea how to investigate this any deeper.

Stefan