Hi John, John Krukoff wrote:

Thanks for the response. Yeah, I know just how vague an error report this is. I was really hoping I was hitting something that someone else had already encountered. I've already wasted a day trying to strip the program down to just the lxml operations, and haven't been able to come up with a reduced set of the program that still causes the crash.

Try to think about the main treatments you apply to trees. Do you move elements between trees? What happens to the source tree? Does the crash go away if you keep a reference to it? (maybe in a set or list) Do you keep cyclic references between objects that reference elements, i.e. is the Python cyclic garbage collector involved in cleaning up XML trees? If you use XSLT, can you reproduce the crash if you build the result tree (or a simpler one) by hand? Do you use XPath calls or extension functions? Are they required to trigger the crash? These kinds of bugs are mostly related to garbage collection and Python reference counting, so try to concentrate on code that results in freeing references to elements and trees. There is also a tool we commonly use to debug memory handling in lxml.etree. It's called "valgrind". doc/valgrind.txt contains a command line that allows you to run lxml with it. This gives you a stack trace when problems occur or when the program crashes that *might* give us a hint on what happened. In case you want to try, you can send me the output in private e-mail (preferably bzip2-ed or gzipped) so that I can take a look at it.

I'll spend another day on this, and see if I can't do better.

Thanks, we really appreciate this kind of help. Stefan