I've recently fixed some issues: - closure variables were not tracked - scoped expression variables were initialized to None So, I should fix broken tests, here are some of them: nogil (should be fixed) purecdef (upstream) cfunc_directive_in_pyclass (upstream) bufaccess_noassignT444 (should be removed?) bufaccess (should be fixed) ass2longlong (should be fixed) builtinfuncs (should be fixed) extcmethcall (should be fixed) extcoerce (fixed or removed?) e_extweakref (should be fixed) -- vitja.
On 05/27/2011 04:27 PM, Vitja Makarov wrote:
I've recently fixed some issues:
- closure variables were not tracked - scoped expression variables were initialized to None
So, I should fix broken tests, here are some of them:
nogil (should be fixed) purecdef (upstream) cfunc_directive_in_pyclass (upstream) bufaccess_noassignT444 (should be removed?)
One could make it an error testcase instead, trapping the syntax error you now raise. Depends on how confident you are on new control flow tests and whether buffers are tested there.
bufaccess (should be fixed)
Yeah, feel free to just remove nousage() and printbuf().
ass2longlong (should be fixed) builtinfuncs (should be fixed) extcmethcall (should be fixed) extcoerce (fixed or removed?) e_extweakref (should be fixed)
Dag
On Fri, May 27, 2011 at 7:27 AM, Vitja Makarov <vitja.makarov@gmail.com> wrote:
I've recently fixed some issues:
- closure variables were not tracked - scoped expression variables were initialized to None
So, I should fix broken tests, here are some of them:
nogil (should be fixed) purecdef (upstream) cfunc_directive_in_pyclass (upstream) bufaccess_noassignT444 (should be removed?) bufaccess (should be fixed) ass2longlong (should be fixed) builtinfuncs (should be fixed) extcmethcall (should be fixed) extcoerce (fixed or removed?)
Unless you see this code being exercised elsewhere (a run test would be better her anyways) it's an easy fix that should be done.
e_extweakref (should be fixed)
-- vitja. _______________________________________________ cython-devel mailing list cython-devel@python.org http://mail.python.org/mailman/listinfo/cython-devel
2011/5/28 Robert Bradshaw <robertwb@math.washington.edu>:
On Fri, May 27, 2011 at 7:27 AM, Vitja Makarov <vitja.makarov@gmail.com> wrote:
I've recently fixed some issues:
- closure variables were not tracked - scoped expression variables were initialized to None
So, I should fix broken tests, here are some of them:
nogil (should be fixed) purecdef (upstream) cfunc_directive_in_pyclass (upstream) bufaccess_noassignT444 (should be removed?) bufaccess (should be fixed) ass2longlong (should be fixed) builtinfuncs (should be fixed) extcmethcall (should be fixed) extcoerce (fixed or removed?)
Unless you see this code being exercised elsewhere (a run test would be better her anyways) it's an easy fix that should be done.
e_extweakref (should be fixed)
I've fixed all the tests. Now I see this strange error in py2.4: https://sage.math.washington.edu:8091/hudson/view/cython-vitek/job/cython-vi... ***************** compiling (c) w_uninitialized_py3 === Expected errors: === 7:11: local variable 'i' referenced before assignment 13:11: local variable 'i' referenced before assignment === Got errors: === 7:9: undeclared name not builtin: print 7:11: local variable 'i' referenced before assignment 13:11: local variable 'i' referenced before assignment -- vitja.
Vitja Makarov, 28.05.2011 11:48:
2011/5/28 Robert Bradshaw:
On Fri, May 27, 2011 at 7:27 AM, Vitja Makarov wrote:
I've recently fixed some issues:
- closure variables were not tracked - scoped expression variables were initialized to None
So, I should fix broken tests, here are some of them:
nogil (should be fixed) purecdef (upstream) cfunc_directive_in_pyclass (upstream) bufaccess_noassignT444 (should be removed?) bufaccess (should be fixed) ass2longlong (should be fixed) builtinfuncs (should be fixed) extcmethcall (should be fixed) extcoerce (fixed or removed?)
Unless you see this code being exercised elsewhere (a run test would be better her anyways) it's an easy fix that should be done.
e_extweakref (should be fixed)
I've fixed all the tests.
Cool.
Now I see this strange error in py2.4:
https://sage.math.washington.edu:8091/hudson/view/cython-vitek/job/cython-vi...
***************** compiling (c) w_uninitialized_py3 === Expected errors: === 7:11: local variable 'i' referenced before assignment 13:11: local variable 'i' referenced before assignment
=== Got errors: === 7:9: undeclared name not builtin: print 7:11: local variable 'i' referenced before assignment 13:11: local variable 'i' referenced before assignment
I guess that's http://trac.cython.org/cython_trac/ticket/69 In short, print() still isn't supported before Py2.6. I'd just disable that test in older Python versions for now. Stefan
2011/5/28 Stefan Behnel <stefan_ml@behnel.de>:
Vitja Makarov, 28.05.2011 11:48:
2011/5/28 Robert Bradshaw:
On Fri, May 27, 2011 at 7:27 AM, Vitja Makarov wrote:
I've recently fixed some issues:
- closure variables were not tracked - scoped expression variables were initialized to None
So, I should fix broken tests, here are some of them:
nogil (should be fixed) purecdef (upstream) cfunc_directive_in_pyclass (upstream) bufaccess_noassignT444 (should be removed?) bufaccess (should be fixed) ass2longlong (should be fixed) builtinfuncs (should be fixed) extcmethcall (should be fixed) extcoerce (fixed or removed?)
Unless you see this code being exercised elsewhere (a run test would be better her anyways) it's an easy fix that should be done.
e_extweakref (should be fixed)
I've fixed all the tests.
Cool.
Now I see this strange error in py2.4:
https://sage.math.washington.edu:8091/hudson/view/cython-vitek/job/cython-vi...
***************** compiling (c) w_uninitialized_py3 === Expected errors: === 7:11: local variable 'i' referenced before assignment 13:11: local variable 'i' referenced before assignment
=== Got errors: === 7:9: undeclared name not builtin: print 7:11: local variable 'i' referenced before assignment 13:11: local variable 'i' referenced before assignment
I guess that's
http://trac.cython.org/cython_trac/ticket/69
In short, print() still isn't supported before Py2.6. I'd just disable that test in older Python versions for now.
I've replaced print() with dummy ref(obj) function -- vitja.
Vitja Makarov, 28.05.2011 13:48:
2011/5/28 Stefan Behnel<stefan_ml@behnel.de>:
Vitja Makarov, 28.05.2011 11:48:
2011/5/28 Robert Bradshaw:
On Fri, May 27, 2011 at 7:27 AM, Vitja Makarov wrote:
I've recently fixed some issues:
- closure variables were not tracked - scoped expression variables were initialized to None
So, I should fix broken tests, here are some of them:
nogil (should be fixed) purecdef (upstream) cfunc_directive_in_pyclass (upstream) bufaccess_noassignT444 (should be removed?) bufaccess (should be fixed) ass2longlong (should be fixed) builtinfuncs (should be fixed) extcmethcall (should be fixed) extcoerce (fixed or removed?)
Unless you see this code being exercised elsewhere (a run test would be better her anyways) it's an easy fix that should be done.
e_extweakref (should be fixed)
I've fixed all the tests.
Cool.
Now I see this strange error in py2.4:
https://sage.math.washington.edu:8091/hudson/view/cython-vitek/job/cython-vi...
***************** compiling (c) w_uninitialized_py3 === Expected errors: === 7:11: local variable 'i' referenced before assignment 13:11: local variable 'i' referenced before assignment
=== Got errors: === 7:9: undeclared name not builtin: print 7:11: local variable 'i' referenced before assignment 13:11: local variable 'i' referenced before assignment
I guess that's
http://trac.cython.org/cython_trac/ticket/69
In short, print() still isn't supported before Py2.6. I'd just disable that test in older Python versions for now.
I've replaced print() with dummy ref(obj) function
Ok, I think we're done then, right? Anything else to do before merging it back? Stefan
2011/5/28 Stefan Behnel <stefan_ml@behnel.de>:
Vitja Makarov, 28.05.2011 13:48:
2011/5/28 Stefan Behnel<stefan_ml@behnel.de>:
Vitja Makarov, 28.05.2011 11:48:
2011/5/28 Robert Bradshaw:
On Fri, May 27, 2011 at 7:27 AM, Vitja Makarov wrote:
I've recently fixed some issues:
- closure variables were not tracked - scoped expression variables were initialized to None
So, I should fix broken tests, here are some of them:
nogil (should be fixed) purecdef (upstream) cfunc_directive_in_pyclass (upstream) bufaccess_noassignT444 (should be removed?) bufaccess (should be fixed) ass2longlong (should be fixed) builtinfuncs (should be fixed) extcmethcall (should be fixed) extcoerce (fixed or removed?)
Unless you see this code being exercised elsewhere (a run test would be better her anyways) it's an easy fix that should be done.
e_extweakref (should be fixed)
I've fixed all the tests.
Cool.
Now I see this strange error in py2.4:
https://sage.math.washington.edu:8091/hudson/view/cython-vitek/job/cython-vi...
***************** compiling (c) w_uninitialized_py3 === Expected errors: === 7:11: local variable 'i' referenced before assignment 13:11: local variable 'i' referenced before assignment
=== Got errors: === 7:9: undeclared name not builtin: print 7:11: local variable 'i' referenced before assignment 13:11: local variable 'i' referenced before assignment
I guess that's
http://trac.cython.org/cython_trac/ticket/69
In short, print() still isn't supported before Py2.6. I'd just disable that test in older Python versions for now.
I've replaced print() with dummy ref(obj) function
Ok, I think we're done then, right? Anything else to do before merging it back?
I hope so ;) -- vitja.
Vitja Makarov, 28.05.2011 14:12:
2011/5/28 Stefan Behnel:
Ok, I think we're done then, right? Anything else to do before merging it back?
I hope so ;)
I gave your branch a test with lxml and it spit out a couple of missing initialisation warnings. Most of them were due to the usage of C out arguments, e.g. cdef Py_ssize_t step ... _PyEval_SliceIndex(sliceobject.step, &step) Here, it doesn't matter that "step" isn't initialised. I guess it's still ok to get a warning, since it's not obvious that "step" will always be set by the function call. Similarly: cdef void _receiveXSLTError(void* c_log_handler, char* msg, ...) nogil: cdef cstd.va_list args ... cstd.va_start(args, msg) Cython now tells me that "args" isn't initialised. That's true again, although this is an even more special case here. I guess I'll have to live with that as well for now, maybe until there's dedicated va_list support in Cython. Next, I got a crash in a part of code where I was manually releasing the GIL, but only conditionally, and Cython figured out that a variable wasn't initialised in one case and injected an exception. I would have liked to get a compile time warning here, but didn't. I assume that's because it was only a "may be used uninitialised", not a "is used uninitialised"? I'm currently looking through the other issues. A major problem is that I often relied on Cython setting uninitialised variables to None, especially in performance critical code where I wanted to avoid double initialisations. Cython is smarter now, so this needs fixing in the code. I'm sure I'm not the only one who'll run into that, so more warnings would be very helpful. Stefan
2011/5/28 Stefan Behnel <stefan_ml@behnel.de>:
Vitja Makarov, 28.05.2011 14:12:
2011/5/28 Stefan Behnel:
Ok, I think we're done then, right? Anything else to do before merging it back?
I hope so ;)
I gave your branch a test with lxml and it spit out a couple of missing initialisation warnings. Most of them were due to the usage of C out arguments, e.g.
cdef Py_ssize_t step ... _PyEval_SliceIndex(sliceobject.step, &step)
Here, it doesn't matter that "step" isn't initialised. I guess it's still ok to get a warning, since it's not obvious that "step" will always be set by the function call.
Similarly:
cdef void _receiveXSLTError(void* c_log_handler, char* msg, ...) nogil: cdef cstd.va_list args ... cstd.va_start(args, msg)
Cython now tells me that "args" isn't initialised. That's true again, although this is an even more special case here. I guess I'll have to live with that as well for now, maybe until there's dedicated va_list support in Cython.
Next, I got a crash in a part of code where I was manually releasing the GIL, but only conditionally, and Cython figured out that a variable wasn't initialised in one case and injected an exception. I would have liked to get a compile time warning here, but didn't. I assume that's because it was only a "may be used uninitialised", not a "is used uninitialised"?
I'm currently looking through the other issues. A major problem is that I often relied on Cython setting uninitialised variables to None, especially in performance critical code where I wanted to avoid double initialisations. Cython is smarter now, so this needs fixing in the code. I'm sure I'm not the only one who'll run into that, so more warnings would be very helpful.
Do you run cython as "cython -Wextra"? -Wextra enables "maybe uninitialized" warning and unused entry. By default error is generated for uninitialized pyobject variables and warning for ctypes. -- vitja.
Vitja Makarov, 28.05.2011 16:58:
2011/5/28 Stefan Behnel:
Vitja Makarov, 28.05.2011 14:12:
2011/5/28 Stefan Behnel:
Ok, I think we're done then, right? Anything else to do before merging it back?
I hope so ;)
I gave your branch a test with lxml and it spit out a couple of missing initialisation warnings. Most of them were due to the usage of C out arguments, e.g.
cdef Py_ssize_t step ... _PyEval_SliceIndex(sliceobject.step,&step)
Here, it doesn't matter that "step" isn't initialised. I guess it's still ok to get a warning, since it's not obvious that "step" will always be set by the function call.
Similarly:
cdef void _receiveXSLTError(void* c_log_handler, char* msg, ...) nogil: cdef cstd.va_list args ... cstd.va_start(args, msg)
Cython now tells me that "args" isn't initialised. That's true again, although this is an even more special case here. I guess I'll have to live with that as well for now, maybe until there's dedicated va_list support in Cython.
Next, I got a crash in a part of code where I was manually releasing the GIL, but only conditionally, and Cython figured out that a variable wasn't initialised in one case and injected an exception. I would have liked to get a compile time warning here, but didn't. I assume that's because it was only a "may be used uninitialised", not a "is used uninitialised"?
I'm currently looking through the other issues. A major problem is that I often relied on Cython setting uninitialised variables to None, especially in performance critical code where I wanted to avoid double initialisations. Cython is smarter now, so this needs fixing in the code. I'm sure I'm not the only one who'll run into that, so more warnings would be very helpful.
Do you run cython as "cython -Wextra"? -Wextra enables "maybe uninitialized" warning and unused entry. By default error is generated for uninitialized pyobject variables and warning for ctypes.
No, I was setting the warning level to 0. That should give me all warnings and that, IMHO, includes this one. Stefan
Vitja Makarov, 28.05.2011 16:58:
-Wextra enables "maybe uninitialized" warning and unused entry.
Interesting: cdef int _raise_if_stored(self) except -1: if self._exc_info is None: return 0 type, value, traceback = self._exc_info self._exc_info = None if value is None and traceback is None: raise type else: raise type, value, traceback src/lxml/lxml.etree.pyx:277:12: Unused entry 'type' I guess that's just a missing marker in RaiseStatNode. Stefan
Vitja, here are some more quirks, but they are minor issues. I'll commit my changes to lxml to keep it working, and then merge in the branch. It's certainly in a "good enough for a merge" state. I'm actually surprised how few problems I had to fix, given how old the code in lxml is by now. Let's see how much of Sage we break. Stefan Some more issues: cdef Py_ssize_t c = 0, i [...] while c_node is not NULL and c < count: for i from 0 <= i < step: c_next = next_element(c_next) _removeNode(doc, c_node) c = c + 1 c_node = c_next return 0 src/lxml/apihelpers.pxi:1079:23: Unused entry 'i' (Although the best fix is to change the code to for-in-range() here...) Here's another interesting constellation: live_refs = _convert_xslt_parameters(transform_ctxt, kw, ¶ms) c_result = self._run_transform( c_doc, params, context, transform_ctxt) if params is not NULL: # deallocate space for parameters python.PyMem_Free(params) live_refs = None # release objects src/lxml/xslt.pxi:519:22: Unused entry 'live_refs' So, holding on to Python references to keep their C char* alive gives me a warning. Fine. I guess I'll have to live with that... Another missing bit: cdef void registerExsltFunctions(self): cdef xpath.xmlXPathContext* ctxt = self._xpathCtxt cdef int i cdef char* c_href if xslt.LIBXSLT_VERSION < 10125: # we'd only execute dummy functions anyway return tree.xmlHashScan( self._xpathCtxt.nsHash, _registerExsltFunctionsForNamespaces, self._xpathCtxt) src/lxml/xpath.pxi:80:34: Unused entry 'ctxt' Ok, right, "ctxt" is unused here. But all *3* declarations are actually left-over code from the last refactoring. None of them is used, and I only get one warning?
Stefan Behnel, 28.05.2011 18:06:
Let's see how much of Sage we break.
... quite a bit. From a superficial glance, there seem to be some real bugs, but most of the failures and warnings are most likely just uninitialised variables that are expected to be None. https://sage.math.washington.edu:8091/hudson/view/All/job/sage-build/740/con... Stefan
2011/5/28 Stefan Behnel <stefan_ml@behnel.de>:
Stefan Behnel, 28.05.2011 18:06:
Let's see how much of Sage we break.
... quite a bit. From a superficial glance, there seem to be some real bugs, but most of the failures and warnings are most likely just uninitialised variables that are expected to be None.
https://sage.math.washington.edu:8091/hudson/view/All/job/sage-build/740/con...
I've started new branch called control_flow_fixes. I've fixed the issue with RaiseStatNode. And unused variables that were not assigned or referenced now you get correct message. And I started to look inside sage problems. Error compiling Cython file: ------------------------------------------------------------ ... # allow lambda functions if self._nrows==0 or self._ncols==0: return self.__copy__() v = [z.derivative(var) for z in self.list()] if R is None: ^ ------------------------------------------------------------ sage/matrix/matrix_dense.pyx:451:13: local variable 'R' referenced before assignment I've looked into the sources and I think as cython is right here. 'R' is allways NULL at that point. -- vitja.
Vitja Makarov, 29.05.2011 10:11:
2011/5/28 Stefan Behnel:
Stefan Behnel, 28.05.2011 18:06:
Let's see how much of Sage we break.
... quite a bit. From a superficial glance, there seem to be some real bugs,
Bugs in Sage, to be clear.
but most of the failures and warnings are most likely just uninitialised variables that are expected to be None.
https://sage.math.washington.edu:8091/hudson/view/All/job/sage-build/740/con...
I've started new branch called control_flow_fixes.
I think you can safely apply the subsequent fixes to the master branch, now that the feature is in. That will also give you broader feedback from Jenkins.
I've fixed the issue with RaiseStatNode. And unused variables that were not assigned or referenced now you get correct message.
Cool.
And I started to look inside sage problems.
Error compiling Cython file: ------------------------------------------------------------ ... # allow lambda functions
if self._nrows==0 or self._ncols==0: return self.__copy__() v = [z.derivative(var) for z in self.list()] if R is None: ^ ------------------------------------------------------------
sage/matrix/matrix_dense.pyx:451:13: local variable 'R' referenced before assignment
I've looked into the sources and I think as cython is right here. 'R' is allways NULL at that point.
Yes, that's one of the things I meant. It looked like a Sage bug right away. Stefan
2011/5/29 Stefan Behnel <stefan_ml@behnel.de>:
Vitja Makarov, 29.05.2011 10:11:
2011/5/28 Stefan Behnel:
Stefan Behnel, 28.05.2011 18:06:
Let's see how much of Sage we break.
... quite a bit. From a superficial glance, there seem to be some real bugs,
Bugs in Sage, to be clear.
Ok.
but most of the failures and warnings are most likely just uninitialised variables that are expected to be None.
https://sage.math.washington.edu:8091/hudson/view/All/job/sage-build/740/con...
I've started new branch called control_flow_fixes.
I think you can safely apply the subsequent fixes to the master branch, now that the feature is in. That will also give you broader feedback from Jenkins.
I don't have write access to upstream repo. Btw there is one more commit in control_flow_fixes branch with few new tests.
I've fixed the issue with RaiseStatNode. And unused variables that were not assigned or referenced now you get correct message.
Cool.
What about "Error running command, failed with status 256." lines in sage build log? Is that cython crash? -- vitja.
Vitja Makarov, 29.05.2011 11:17:
2011/5/29 Stefan Behnel:
Vitja Makarov, 29.05.2011 10:11:
I've started new branch called control_flow_fixes.
I think you can safely apply the subsequent fixes to the master branch, now that the feature is in. That will also give you broader feedback from Jenkins.
I don't have write access to upstream repo.
Ah, sorry. I added you to the project members.
Btw there is one more commit in control_flow_fixes branch with few new tests.
That makes a good test for your write access then. ;)
What about "Error running command, failed with status 256." lines in sage build log? Is that cython crash?
Don't think so. Not sure what those failures are, but given that some modules fail to compile, maybe it's just the late result of such a build failure. Stefan
2011/5/29 Stefan Behnel <stefan_ml@behnel.de>:
Vitja Makarov, 29.05.2011 11:17:
2011/5/29 Stefan Behnel:
Vitja Makarov, 29.05.2011 10:11:
I've started new branch called control_flow_fixes.
I think you can safely apply the subsequent fixes to the master branch, now that the feature is in. That will also give you broader feedback from Jenkins.
I don't have write access to upstream repo.
Ah, sorry. I added you to the project members.
Btw there is one more commit in control_flow_fixes branch with few new tests.
That makes a good test for your write access then. ;)
Thanks. I've successfully pushed my changes. I removed old ControlFlow stuff completely.
What about "Error running command, failed with status 256." lines in sage build log? Is that cython crash?
Don't think so. Not sure what those failures are, but given that some modules fail to compile, maybe it's just the late result of such a build failure.
-- vitja.
2011/5/29 Vitja Makarov <vitja.makarov@gmail.com>:
2011/5/29 Stefan Behnel <stefan_ml@behnel.de>:
Vitja Makarov, 29.05.2011 11:17:
2011/5/29 Stefan Behnel:
Vitja Makarov, 29.05.2011 10:11:
I've started new branch called control_flow_fixes.
I think you can safely apply the subsequent fixes to the master branch, now that the feature is in. That will also give you broader feedback from Jenkins.
I don't have write access to upstream repo.
Ah, sorry. I added you to the project members.
Btw there is one more commit in control_flow_fixes branch with few new tests.
That makes a good test for your write access then. ;)
Thanks. I've successfully pushed my changes. I removed old ControlFlow stuff completely.
What about "Error running command, failed with status 256." lines in sage build log? Is that cython crash?
Don't think so. Not sure what those failures are, but given that some modules fail to compile, maybe it's just the late result of such a build failure.
I see sigsegv in lxml tests: 1222/1364 ( 89.6%): test_xmlschema_import_file (lxml.tests.test_xmlschema.ETreeXMLSchemaTestCase) ... Segmentation fault https://sage.math.washington.edu:8091/hudson/job/cython-devel-lxml-trunk-py2... Is that control flow related issue? -- vitja.
Vitja Makarov, 30.05.2011 20:53:
I see sigsegv in lxml tests:
1222/1364 ( 89.6%): test_xmlschema_import_file (lxml.tests.test_xmlschema.ETreeXMLSchemaTestCase) ... Segmentation fault https://sage.math.washington.edu:8091/hudson/job/cython-devel-lxml-trunk-py2...
Is that control flow related issue?
No, don't bother with that one. It's been crashing at that point for ages and I can't figure out why. It only crashes on sage.math, and only when running two of the tests in combination (a threading test and the one above). So far, I couldn't reproduce this on any other machine, nor is it any clear what may trigger this. I'm pretty sure it's not a Cython related bug, though. Stefan
2011/5/30 Stefan Behnel <stefan_ml@behnel.de>:
Vitja Makarov, 30.05.2011 20:53:
I see sigsegv in lxml tests:
1222/1364 ( 89.6%): test_xmlschema_import_file (lxml.tests.test_xmlschema.ETreeXMLSchemaTestCase) ... Segmentation fault
https://sage.math.washington.edu:8091/hudson/job/cython-devel-lxml-trunk-py2...
Is that control flow related issue?
No, don't bother with that one.
It's been crashing at that point for ages and I can't figure out why. It only crashes on sage.math, and only when running two of the tests in combination (a threading test and the one above). So far, I couldn't reproduce this on any other machine, nor is it any clear what may trigger this. I'm pretty sure it's not a Cython related bug, though.
Ok, according to last 4 builds it's fails 75% so maybe try to run it under gdb with bt hook? -- vitja.
Vitja Makarov, 30.05.2011 22:15:
2011/5/30 Stefan Behnel:
Vitja Makarov, 30.05.2011 20:53:
I see sigsegv in lxml tests:
1222/1364 ( 89.6%): test_xmlschema_import_file (lxml.tests.test_xmlschema.ETreeXMLSchemaTestCase) ... Segmentation fault
https://sage.math.washington.edu:8091/hudson/job/cython-devel-lxml-trunk-py2...
Is that control flow related issue?
No, don't bother with that one.
It's been crashing at that point for ages and I can't figure out why. It only crashes on sage.math, and only when running two of the tests in combination (a threading test and the one above). So far, I couldn't reproduce this on any other machine, nor is it any clear what may trigger this. I'm pretty sure it's not a Cython related bug, though.
Ok, according to last 4 builds it's fails 75% so maybe try to run it under gdb with bt hook?
I *know* where it fails. But that doesn't really tell me *why* it fails. As I said, it only crashes when one of the threading tests runs before it. I can only guess that the thread interaction somehow leaves libxml2 in an inconsistent state, which then triggers a crash later on in the schema test. Stefan
participants (4)
-
Dag Sverre Seljebotn -
Robert Bradshaw -
Stefan Behnel -
Vitja Makarov