Hi, Dmitri Fedoruk wrote:
Here is a trivial patch (the one against xslt.pxi) It seems to work for me, any chance you could give it a try? Thank you for the patches, I'll apply them and see what happens next.
Thanks.
The thing is that such an exception occurs very seldom and I can not reproduce it.
You will still notice if it doesn't work. :)
Nevertheless, coming back to the thread subject. As we have managed to find out, it is indeed the deallocation problem. I've played around with the variable taht caused the trouble, tried to make it global, for example - this changed only the positon of the crash, but not the reason. When the memory has to be free'd, the crash happens.
Unfortunatelly I managed to reproduce this bug on 3 versions of FreeBSD 6.2 and on the i386 architecture too, which had never happened in 6 months of development.
It shouldn't be machine dependent. If it's there, it's in the code. Garbage collection and threading might work different on different architectures, but that won't remove the actual problem.
But i386 is capable of running valgrind. So I got this errors: ==77394== Invalid free() / delete / delete[] ==77394== at 0x3C03867F: free (in /usr/local/lib/valgrind/vgpreload_memcheck.so) ==77394== by 0x3CF97668: xmlFreeNodeList (in /usr/X11R6/lib/libxml2.so.5) ==77394== by 0x3CF974F0: xmlFreeProp (in /usr/X11R6/lib/libxml2.so.5) ==77394== by 0x3CF9754F: xmlFreePropList (in /usr/X11R6/lib/libxml2.so.5) ==77394== Address 0x3C9C5E8B is 743 bytes inside a block of size 1024 alloc'd ==77394== at 0x3C038183: malloc (in /usr/local/lib/valgrind/vgpreload_memcheck.so) ==77394== by 0x3D02B4EE: xmlDictAddString (in /usr/X11R6/lib/libxml2.so.5) ==77394== by 0x3D02BBEB: xmlDictLookup (in /usr/X11R6/lib/libxml2.so.5) ==77394== by 0x3CF80425: xmlDetectSAX2 (in /usr/X11R6/lib/libxml2.so.5)
Funny place for a malloc. Anyway, this is only a symptom. The problem is that the document or an XML node gets freed either while it's still in use, or by two independent parties (i.e. Python element proxies that refer to it). With a bug that occurs this seldom and a setup as complex as mod_python, it's really hard to narrow down the test case, so I don't how far you could get here. However, I'm currently chasing a (pretty old) bug myself. Maybe it's related already. Could you check with the current SVN trunk if that works better for you? Although the stack trace above gives me doubts...
More than that, this messages were preceeded by a bunch of errors from the libpython itself: ==77390== Use of uninitialised value of size 4 ==77390== at 0x3C6D2AC9: PyObject_Realloc (in /usr/X11R6/lib/libpython2.5.so) ==77390== by 0x3C735BA4: _PyObject_GC_Resize (in /usr/X11R6/lib/libpython2.5.so) ==77390== by 0x3C6BE525: PyFrame_New (in /usr/X11R6/lib/libpython2.5.so) ==77390== by 0x3C711382: PyEval_EvalFrameEx (in /usr/X11R6/lib/libpython2.5.so) ==77390== ==77390== Invalid read of size 4 ==77390== at 0x3C6D2AAF: PyObject_Realloc (in /usr/X11R6/lib/libpython2.5.so) ==77390== by 0x3C735BA4: _PyObject_GC_Resize (in /usr/X11R6/lib/libpython2.5.so) ==77390== by 0x3C6BE525: PyFrame_New (in /usr/X11R6/lib/libpython2.5.so) ==77390== by 0x3C711382: PyEval_EvalFrameEx (in /usr/X11R6/lib/libpython2.5.so) ==77390== Conditional jump or move depends on uninitialised value(s) ==77390== at 0x3C6D2AB8: PyObject_Realloc (in /usr/X11R6/lib/libpython2.5.so) ==77390== by 0x3C735BA4: _PyObject_GC_Resize (in /usr/X11R6/lib/libpython2.5.so) ==77390== by 0x3C6BE525: PyFrame_New (in /usr/X11R6/lib/libpython2.5.so) ==77390== by 0x3C711382: PyEval_EvalFrameEx (in /usr/X11R6/lib/libpython2.5.so) (repeated many times during the apache thread initialisation).
Hmmm, not sure what this means. Might be entirely unrelated. Valgrind uses a suppression file that drops a lot of false positives, maybe those are just false positives of mod_python.
So, this is not the lxml problem really... But maybe somebody has any idea? Right now I'm thinking of opportunity to replace mod_python with mod_fastcgi .
I have neither experience with mod_python nor with mod_fastcgi, sorry. Stefan