2011/6/1 Francois Bissey <francois.bis...@canterbury.ac.nz>: >> 2011/4/9 Francois Bissey <francois.bis...@canterbury.ac.nz>: >> > It turns out that warnings are not visible to the end users anymore. >> > This is according to the python documentation: >> > http://docs.python.org/library/warnings.html >> > Section 27.6.5 to be precise. >> > Actually more explicit in http://docs.python.org/using/cmdline.html : >> > Starting from Python 2.7, DeprecationWarning and its descendants are >> > ignored by default. The -Wd option can be used to re-enable them. >> > >> > Passing -Wd to python I get to see the warnings again but to see the >> > warnings >> > globally we'll need to add: >> > PYTHONWARNINGS=default >> > to sage-env this is I hope harmless for 2.6 but useful for 2.7. >> >> I am just ignoring doctest failures due to it expecting a warning >> but no warning generated. >> > Hi Paulo, > > we have move a bit from this hack now: > http://trac.sagemath.org/sage_trac/ticket/11244 > >> But I am almost ashamed of myself by adding this to >> sage/all.py: >> >> import gc >> gc.set_debug(gc.DEBUG_SAVEALL) >> >> I still need to run a full sage -testall with that to see if >> there are any remaining crashes. Last one I was debugging >> was rooted in >> sage/libs/singular/groebner_strategy.pyx:GroebnerStrategy:__dealloc__ >> where the call id_Delete(&self._strat.Shdl, self._parent._ring) >> would pass "garbage" to the related singular function. >> >> Maybe for the people more familiar with sage internals >> it would be easier to figure out why python thinks that >> memory is unreachable, and it can garbage collect it. >> >> Disabling gc has a very bad side effect, e.g. I am >> testing a sage rebuild, and sphynx is already using >> almost 3Gb of memory while generating documentation.
I needed to revert that change, because a computer with 4GB or ram would not be able to rebuild sage from source; could patch after rebuilding documentation, but would just leave the problem for the user... > Martin (our "chief sage-on-gentoo" debugger of glibc fame) has > tracked down that one to cython: > https://github.com/cschwan/sage-on-gentoo/issues/51#issuecomment-1181259 > and we now have a trac ticket for it: > http://trac.sagemath.org/sage_trac/ticket/11339 > so far it is not encouraging. > > I consider this particular issue to be a "canary in a coal mine" case. > It is revealed by the upgrade to python-2.7 but it is just waiting to > bite people on 2.6, in fact there are indication in the code that > similar issues have been worked around band aid style in the code > before. If I understand it correctly, at least for this particular case: sage/libs/singular/groebner_strategy.pyx:GroebnerStrategy(SageObject)._parent => sage/rings/polynomial/multi_polynomial_libsingular.pyx:MPolynomialRing_libsingular(MPolynomialRing_generic) and the _parent field has a __dealloc__ as: singular_ring_delete(self._ring) while the GroebnerStrategy __dealloc__ deferences _parent._ring. So, again if I understand correctly, the crash is happening because MPolynomialRing_libsingular:__deallocate__ should be called after pyx:GroebnerStrategy:__deallocate__, but in python 2.7 this is not happening, as the order is not guaranteed, and apparently just happens to be in the correct order with python 2.6. Maybe python's Modules/gcmodule.c is the one at fault here then? I mean, it should not just release a list of objects, but should make some kind of topological sort before releasing objects? But that probably would still find cycles in other cases, so, it would more likely need to have an api to, and use it to construct some list of pointers to be released, but that assuming stuff is allocated with malloc... Damn, this indeed does not look much encouraging :-) > Francois Paulo -- To post to this group, send an email to sage-devel@googlegroups.com To unsubscribe from this group, send an email to sage-devel+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/sage-devel URL: http://www.sagemath.org
