[lxml-dev] swig_sources problem with Pyrex
one for the archives ... Paul Everitt wrote:
Stefan Behnel wrote:
Paul Everitt wrote:
I'm stuck on compiling the trunk (the swig_sources error) for OS X.
Check if you have this line in Pyrex/Distutils/build_ext.py (line ~35)
def swig_sources (self, sources, extension=None):
I have:
def swig_sources (self, sources): if not self.extensions: return
Then change it. You may just as well use def swig_sources(self, sources, *otherargs): It doesn't matter. It's just there to allow either two or three arguments. Stefan
Stefan Behnel wrote:
one for the archives ...
Paul Everitt wrote:
Stefan Behnel wrote:
Paul Everitt wrote:
I'm stuck on compiling the trunk (the swig_sources error) for OS X. Check if you have this line in Pyrex/Distutils/build_ext.py (line ~35)
def swig_sources (self, sources, extension=None): I have:
def swig_sources (self, sources): if not self.extensions: return
Then change it. You may just as well use
def swig_sources(self, sources, *otherargs):
It doesn't matter. It's just there to allow either two or three arguments.
from lxml import etree xmldoc = etree.ElementTree(file="../contentdoc.xml") xsldoc = etree.ElementTree(file="compiledtheme.xsl") style = etree.XSLT(xsldoc) result = style.apply(xmldoc) xmldoc2 = etree.ElementTree(file="../contentdoc.xml") result2 = style.apply(xmldoc2) result3 = style.apply(xmldoc2) result3 = style.apply(xmldoc2)
Hooray, that worked! Thanks, Stefan. I have the trunk compiled and installed now. And, I can happily report a test case for my malloc problems and segfault. :^) I'm on OS X, Python 2.4. The runpipeline.py in this SVN directory: http://codespeak.net/svn/z3/deliverance/trunk/lib/ ...works fine with lxml 0.8 but fails quite badly with the trunk. Specifically, in line 120 of: http://codespeak.net/svn/z3/deliverance/trunk/lib/runpipeline.py ...I have: resultdoc = processor.apply(contentdoc) I also noted, just by trying to limit the problem to a smaller test case, that applying a stylesheet repeatedly leads to an unusual problem. As shown below, all is fine, unless you re-use the same variable name for the transformation output: python(20949) malloc: *** Deallocation of a pointer not malloced: 0x1; This could be a double free(), or free() called with the middle of an allocated block; Try setting environment variable MallocHelp to see tools to help debug python(20949) malloc: *** Deallocation of a pointer not malloced: 0x128b60; This could be a double free(), or free() called with the middle of an allocated block; Try setting environment variable MallocHelp to see tools to help debug python(20949) malloc: *** Deallocation of a pointer not malloced: 0x3bc0e0; This could be a double free(), or free() called with the middle of an allocated block; Try setting environment variable MallocHelp to see tools to help debug python(20949) malloc: *** Deallocation of a pointer not malloced: 0x390e40; This could be a double free(), or free() called with the middle of an allocated block; Try setting environment variable MallocHelp to see tools to help debug python(20949) malloc: *** error for object 0x390de0: double free python(20949) malloc: *** set a breakpoint in szone_error to debug --Paul
Paul Everitt wrote:
I can happily report a test case for my malloc problems and segfault. :^) I'm on OS X, Python 2.4. The runpipeline.py in this SVN directory:
http://codespeak.net/svn/z3/deliverance/trunk/lib/
...works fine with lxml 0.8 but fails quite badly with the trunk. Specifically, in line 120 of:
http://codespeak.net/svn/z3/deliverance/trunk/lib/runpipeline.py
...I have:
resultdoc = processor.apply(contentdoc)
Sorry, I can't reproduce that. I seem to be missing some files, so I can't run the script completely.
I also noted, just by trying to limit the problem to a smaller test case, that applying a stylesheet repeatedly leads to an unusual problem. As shown below, all is fine, unless you re-use the same variable name for the transformation output:
It isn't that easy. Simply reusing the variable doesn't trigger a problem on my side. It seems to also depend on the stylesheet you use. Anyway, when I run your runpipeline.py through valgrind (as far as it runs), it brings up a problem in the changeDocumentBelow function, that calls the namespace reconsiliation functions of libxml2. You do an element.append somewhere and that seems to trigger it. I think it's this line: themeroot.append(copy.deepcopy(themedoc.getroot())) Maybe you can do some more testing, I'll also see what I can come up with. If you want to run valgrind yourself, use the command line from doc/valgrind.txt Stefan
participants (2)
-
Paul Everitt -
Stefan Behnel