Sage: Ticket #11339: Refcounting for Singular rings
https://trac.sagemath.org/ticket/11339
<h1 id="RefcountingforSingularrings">Ref counting for Singular rings</h1>
<p>
Python makes no guarantees that destructors are called if circular references are involved. This patch implements an extra Python proxy layer that correctly refcounts Singular rings. In contrast to our earlier code, it will release the singular rings once they are no longer in use. This triggers various issues in Sage/libSingular that are dealt with in the follow-up ticket <a class="closed ticket" href="https://trac.sagemath.org/ticket/10903" title="defect: Update Singular to 3-1-3-3 (closed: fixed)">#10903</a>
</p>
<h1 id="Historicdiscussion">Historic discussion</h1>
<p>
As <a class="ext-link" href="https://github.com/cschwan/sage-on-gentoo/issues/51#issuecomment-1181259"><span class="icon"></span>described for the Sage on Gentoo project</a>, there is a problem in how parts of sage use <code>__deallocate__</code> in their Cython code. I've actually traced an instance of <a class="ext-link" href="http://hg.sagemath.org/sage-main/file/361a4ad7d52c/sage/libs/singular/groebner_strategy.pyx#l134"><span class="icon"></span>groebner_strategy.pyx</a> causing segmentation faults under Python 2.7.
</p>
<p>
What happens is that the garbage collector invokes the <a class="ext-link" href="http://docs.python.org/c-api/typeobj.html#tp_clear"><span class="icon"></span>tp_clear</a> function for the object. Its implementation is provided by Cython, and one of its effects is that every python reference will be set to <code>None</code>. A bit later on, <a class="ext-link" href="http://docs.python.org/c-api/typeobj.html#tp_dealloc"><span class="icon"></span>tp_dealloc</a> is called and invokes the <code>__deallocate__</code> method. By that time, <code>_parent</code> is <code>None</code>, so accessing <code>_parent._ring</code> is a bad idea, and in this case it turns out to be null.
</p>
<p>
Others have had similar problems before. There are <a class="ext-link" href="http://stackoverflow.com/questions/4501938/how-can-c-object-lifetimes-be-correctly-managed-in-cython"><span class="icon"></span>crude workarounds</a> floating around. I guess a proper solution would be twaking cython to allow custom code in the tp_clear function. In other words, have a "magic" mehod <code>__clear__</code> similar to the magic <code>__deallocate__</code>. But I'll wait for comments here first, before taking this to cython upstream. Perhaps people with more experience have better solutions to offer. And I won't mind if you decide to take this to Cython devs yourselves.
</p>
<h1 id="Apply">Apply</h1>
<p>
Apply:
</p>
<ul><li><a class="attachment" href="https://trac.sagemath.org/attachment/ticket/11339/trac_11339_refcount_singular_rings.patch" title="Attachment 'trac_11339_refcount_singular_rings.patch' in Ticket #11339">trac_11339_refcount_singular_rings.patch</a><a class="trac-rawlink" href="https://trac.sagemath.org/raw-attachment/ticket/11339/trac_11339_refcount_singular_rings.patch" title="Download"></a>
</li><li><a class="attachment" href="https://trac.sagemath.org/attachment/ticket/11339/trac_11339_refcount_singular_polynomials.patch" title="Attachment 'trac_11339_refcount_singular_polynomials.patch' in Ticket #11339">trac_11339_refcount_singular_polynomials.patch</a><a class="trac-rawlink" href="https://trac.sagemath.org/raw-attachment/ticket/11339/trac_11339_refcount_singular_polynomials.patch" title="Download"></a>
</li></ul>en-usSagehttps://trac.sagemath.org/chrome/site/logo_sagemath_trac.png
https://trac.sagemath.org/ticket/11339
Trac 1.1.6fbisseyMon, 16 May 2011 21:44:50 GMTcc set
https://trac.sagemath.org/ticket/11339#comment:1
https://trac.sagemath.org/ticket/11339#comment:1
<ul>
<li><strong>cc</strong>
<em>fbissey</em> <em>robertwb</em> added
</li>
</ul>
TicketvbraunTue, 17 May 2011 09:40:39 GMT
https://trac.sagemath.org/ticket/11339#comment:2
https://trac.sagemath.org/ticket/11339#comment:2
<p>
The documentation is fairly clear, you are only allowed to touch C data structures in <code>__dealloc__</code>: <a class="ext-link" href="http://docs.cython.org/src/userguide/special_methods.html#finalization-method-dealloc"><span class="icon"></span>http://docs.cython.org/src/userguide/special_methods.html#finalization-method-dealloc</a>
</p>
<p>
Really, this shows the difference between the C++ and the Python object model. In Python, executing constructors/destructors in derived classes is optional and leaves a lot of freedom to the programmer. Because of the garbage collection you can allocate resources wherever you want. By comparison, C++ is very strict and essentially forces you to use RAII. This is why there is no try/finally in C++. Which is why there is necessarily some tension in Cython between C++ and Python object instantiation/finalization.
</p>
<p>
Having said that, it seems like the cleanest solution would be if Cython would also call the Python destructor <code>__del__</code> according to the normal Python rules (why <code>__clear__</code>?). Then the Python and C++ object model could just peacefully coexist. The lifetime of a cdef class would be
</p>
<pre class="wiki">__cinit__() # always called
__init__() # not necessarily called for derived classes
... do something ...
__del__() # not necessarily called for derived classes
__dealloc__() # always called
</pre>
TicketfbisseyTue, 17 May 2011 11:36:31 GMT
https://trac.sagemath.org/ticket/11339#comment:3
https://trac.sagemath.org/ticket/11339#comment:3
<p>
Thanks for your input Volker. I think we should definitely put some work in libs/singular to have some <span class="underline">del</span> and <span class="underline">dealloc</span> functions. I think the current state of things in there is a bit messy. I remember reading about <span class="underline">del</span> in the python doc about garbage collection and wondering why singular_ring_delete in libs/singular/rings.pyx wasn't a <span class="underline">del</span> method instead as its intent is clear.
</p>
TicketvbraunTue, 17 May 2011 11:43:39 GMT
https://trac.sagemath.org/ticket/11339#comment:4
https://trac.sagemath.org/ticket/11339#comment:4
<p>
Just to clarify, right now Cython extension classes do not call the Python destructor <code>__del__</code> upon finalization, so Sage can't rely on this mechanism. I'm not quite sure if it is an intentional thing or if the Cython devs just haven't gotten around to implementing it. Maybe we can hack on that on Sage Days 31 since both Robert and Burcin will be around :-)
</p>
TicketfbisseyTue, 17 May 2011 11:53:55 GMT
https://trac.sagemath.org/ticket/11339#comment:5
https://trac.sagemath.org/ticket/11339#comment:5
<p>
OK, well something as to be done about this if we want to move to python-2.7. I think this problem is probably the biggest issue in the way of <a class="closed ticket" href="https://trac.sagemath.org/ticket/9958" title="enhancement: Upgrade python to 2.7.x (closed: fixed)">#9958</a> there are a few other things to look at but that's the only one producing a segfault.
</p>
TicketgagernTue, 17 May 2011 12:21:09 GMT
https://trac.sagemath.org/ticket/11339#comment:6
https://trac.sagemath.org/ticket/11339#comment:6
<p>
I notice that <a class="ext-link" href="http://svn.python.org/view/python/branches/release27-maint/Include/object.h?revision=84346&view=markup"><span class="icon"></span>PyTypeObject</a> has a member <code>tp_del</code> which is not included in <a class="ext-link" href="http://docs.python.org/c-api/typeobj.html"><span class="icon"></span>the documentation</a>. So perhaps it's as simple as associating a function with that slot. Otoh, perhaps there is a reason that member isn't documented. The single reply to <a class="ext-link" href="http://bugs.python.org/issue4934"><span class="icon"></span>Python issue 4934</a> doesn't rule out that possibility.
</p>
TicketburcinWed, 01 Jun 2011 19:25:05 GMTcc changed
https://trac.sagemath.org/ticket/11339#comment:7
https://trac.sagemath.org/ticket/11339#comment:7
<ul>
<li><strong>cc</strong>
<em>burcin</em> added
</li>
</ul>
TicketgagernFri, 03 Jun 2011 10:50:52 GMTattachment set
https://trac.sagemath.org/ticket/11339
https://trac.sagemath.org/ticket/11339
<ul>
<li><strong>attachment</strong>
set to <em>bug11339a.patch</em>
</li>
</ul>
<p>
Workaround patch
</p>
TicketgagernFri, 03 Jun 2011 10:51:10 GMTattachment set
https://trac.sagemath.org/ticket/11339
https://trac.sagemath.org/ticket/11339
<ul>
<li><strong>attachment</strong>
set to <em>bug11339a.bundle</em>
</li>
</ul>
<p>
Workaround hg bundle
</p>
TicketfbisseyTue, 14 Jun 2011 03:15:57 GMTstatus changed
https://trac.sagemath.org/ticket/11339#comment:8
https://trac.sagemath.org/ticket/11339#comment:8
<ul>
<li><strong>status</strong>
changed from <em>new</em> to <em>needs_review</em>
</li>
</ul>
<p>
For the record this works with sage-on-gentoo with python-2.7.1 so as far as I am concerned it works as advertised so far. I can do a review against a vanilla sage using python-2.6 later this week provided that I get the all clear to go back to work (we got a couple more earthquakes down here - the magnitude 6 one was scary but very few people got hurt).
</p>
<p>
What is the "workaround hg bundle" Martin? I can reformat things if needed.
</p>
TicketgagernTue, 14 Jun 2011 20:58:58 GMT
https://trac.sagemath.org/ticket/11339#comment:9
https://trac.sagemath.org/ticket/11339#comment:9
<p>
Replying to <a class="ticket" href="https://trac.sagemath.org/ticket/11339#comment:8" title="Comment 8">fbissey</a>:
</p>
<blockquote class="citation">
<p>
What is the "workaround hg bundle" Martin? I can reformat things if needed.
</p>
</blockquote>
<p>
It's what I perceived to be the hg equivalent of a "bzr send": a file which describes a number of hg commits inclusing metadata, so that other hg users can pull from it.
See hg manual for <a class="ext-link" href="http://www.selenic.com/mercurial/hg.1.html#unbundle"><span class="icon"></span>unbundle</a> and related documentation.
</p>
TicketfbisseyTue, 14 Jun 2011 21:32:34 GMT
https://trac.sagemath.org/ticket/11339#comment:10
https://trac.sagemath.org/ticket/11339#comment:10
<p>
Hi Martin, Steve sent me a note about it earlier this morning. The patch is the only thing necessary here, am I right?
</p>
TicketstrogdonTue, 14 Jun 2011 23:16:54 GMT
https://trac.sagemath.org/ticket/11339#comment:11
https://trac.sagemath.org/ticket/11339#comment:11
<p>
Replying to <a class="ticket" href="https://trac.sagemath.org/ticket/11339#comment:8" title="Comment 8">fbissey</a>:
</p>
<blockquote class="citation">
<p>
For the record this works with sage-on-gentoo with python-2.7.1 so as far as I am concerned it works as advertised so far. I can do a review against a vanilla sage using python-2.6 later this week provided that I get the all clear to go back to work (we got a couple more earthquakes down here - the magnitude 6 one was scary but very few people got hurt). What is the "workaround hg bundle" Martin? I can reformat things if needed.
</p>
</blockquote>
<p>
This patch works fine for me too on sage-on-gentoo with python-2.7.1. I have applied this patch to the vanilla sage-4.7.1.alpha2 (python-2.6.4.p10) spkg and all long tests pass. I have also applied the patch along with the patches and required spkgs in ticket <a class="closed ticket" href="https://trac.sagemath.org/ticket/9958" title="enhancement: Upgrade python to 2.7.x (closed: fixed)">#9958</a> to the sage-4.7.1.alpha2 (python-2.7.1) spkg and all the tests that failed without this patch because of segfaults, i.e.
</p>
<p>
sage -t -force_lib "devel/sage/sage/schemes/generic/scheme.py"
</p>
<p>
sage -t -force_lib "devel/sage/sage/rings/morphism.pyx"
</p>
<p>
sage -t -force_lib "devel/sage/sage/rings/homset.py"
</p>
<p>
now pass.
</p>
TicketfbisseyTue, 14 Jun 2011 23:58:40 GMTstatus, description changed; reviewer set
https://trac.sagemath.org/ticket/11339#comment:12
https://trac.sagemath.org/ticket/11339#comment:12
<ul>
<li><strong>status</strong>
changed from <em>needs_review</em> to <em>positive_review</em>
</li>
<li><strong>reviewer</strong>
set to <em>François Bissey, Steven Trogdon</em>
</li>
<li><strong>description</strong>
modified (<a href="/ticket/11339?action=diff&version=12">diff</a>)
</li>
</ul>
<p>
I am giving this a positive review on my and Steve's observations. I unfortunately won't be able to run some extra tests before Monday it seems.
</p>
TicketvbraunWed, 15 Jun 2011 00:07:16 GMTstatus changed
https://trac.sagemath.org/ticket/11339#comment:13
https://trac.sagemath.org/ticket/11339#comment:13
<ul>
<li><strong>status</strong>
changed from <em>positive_review</em> to <em>needs_work</em>
</li>
</ul>
<p>
As it is, the patch is spectacularly ugly. I agree that it works, but we should investigate alternatives. It is not a particularly pressing issue since Sage is not going to switch to Python-2.7 this week. I'll have a closer look at it with Burcin duing this week at SD31.
</p>
TicketfbisseyWed, 15 Jun 2011 00:13:32 GMT
https://trac.sagemath.org/ticket/11339#comment:14
https://trac.sagemath.org/ticket/11339#comment:14
<p>
I am ok with this. I don't plan to push python-2.7.1 in 4.7.1.
I would like most of the other pending bits and pieces that will make testing easier to be in 4.7.1 however. It would be nice if at least some testing could be done in 4.7.2 and really land it by the next release.
</p>
TicketgagernWed, 15 Jun 2011 08:56:19 GMT
https://trac.sagemath.org/ticket/11339#comment:15
https://trac.sagemath.org/ticket/11339#comment:15
<p>
Replying to <a class="ticket" href="https://trac.sagemath.org/ticket/11339#comment:13" title="Comment 13">vbraun</a>:
</p>
<blockquote class="citation">
<p>
As it is, the patch is spectacularly ugly. [...] we should investigate alternatives.
</p>
</blockquote>
<p>
I agree, that's why I titled the patch "workaround" instead of "solution". I can't think of a way to address this in sage alone, though, as in my opinion a proper solution would entail modifications to cython as discussed above.
</p>
TicketvbraunSat, 18 Jun 2011 07:45:30 GMTstatus, description changed; keywords, author set
https://trac.sagemath.org/ticket/11339#comment:16
https://trac.sagemath.org/ticket/11339#comment:16
<ul>
<li><strong>keywords</strong>
<em>sd31</em> added
</li>
<li><strong>status</strong>
changed from <em>needs_work</em> to <em>needs_review</em>
</li>
<li><strong>description</strong>
modified (<a href="/ticket/11339?action=diff&version=16">diff</a>)
</li>
<li><strong>author</strong>
set to <em>Volker Braun, Martin von Gagern</em>
</li>
</ul>
<p>
In the case at hand we don't really need the Cython class <code>GroebnerStrategy._parent</code>, only the C struct <code>GroebnerStrategy._parent._ring</code> is used in <code>__deallocate__()</code>. I've made a minimal patch that adds a <code>cdef ring *_parent_ring</code> data member to <code>GroebnerStrategy</code> to keep track of the ring only. Because it refers to a C struct, it is safe to access it the Cython destructor. Because parents are immutable we don't have to worry about the <code>ring *</code> pointer becoming invalid.
</p>
<p>
The patch should fix the crash, but I don't have a Sage-on-Python-2.7 install to test it. Can somebody give it a try?
</p>
TicketvbraunSat, 18 Jun 2011 07:45:45 GMTattachment set
https://trac.sagemath.org/ticket/11339
https://trac.sagemath.org/ticket/11339
<ul>
<li><strong>attachment</strong>
set to <em>trac_11339_illegal_use_of__deallocate__in_libsingular.patch</em>
</li>
</ul>
<p>
Initial patch
</p>
TicketgagernSat, 18 Jun 2011 08:52:47 GMT
https://trac.sagemath.org/ticket/11339#comment:17
https://trac.sagemath.org/ticket/11339#comment:17
<p>
Replying to <a class="ticket" href="https://trac.sagemath.org/ticket/11339#comment:16" title="Comment 16">vbraun</a>:
</p>
<p>
I had considered keeping only that C pointer, but decided against it.
</p>
<blockquote class="citation">
<p>
Because parents are immutable we don't have to worry about the <code>ring *</code>
pointer becoming invalid.
</p>
</blockquote>
<p>
Can you explain this in more detail? Why does the parent object being immutable help in keeping the pointer valid? Do you mean that the parent cython object doesn't change it's ring member? That is correct, but not enough to make the approach safe: if you don't keep a reference to the parent python object around, python might decide to garbage-collect that first, leading to a call to the singula function rDelete. I guess that function at least frees the memory, so if you are unlucky, some thread will overwrite the memory that ring points to with completely different data. Of course, in most cases you'd be lucky, so you wouldn't notice the problem. But unless singular does some reference counting of its own in such a way that a rDelete call on the parent won't have immediate effect, your approach isn't safe.
</p>
TicketstrogdonSat, 18 Jun 2011 18:57:36 GMT
https://trac.sagemath.org/ticket/11339#comment:18
https://trac.sagemath.org/ticket/11339#comment:18
<p>
Replying to <a class="ticket" href="https://trac.sagemath.org/ticket/11339#comment:16" title="Comment 16">vbraun</a>:
</p>
<blockquote class="citation">
<p>
The patch should fix the crash, but I don't have a Sage-on-Python-2.7 install to test it. Can somebody give it a try?
</p>
</blockquote>
<p>
Here, the new patch doesn't solve the segfault problems when applied to sage-on-gentoo. In testing vanilla Sage with python-2.7.1 I've been patching the Sage spkg and then building. So my sage-main isn't a pristine sage-4.7.1.alpha2 with python-2.7.1. However the last patch that I've applied is the bug11339a patch. So, I cloned Sage to the patchset just prior to this last patch, apply the new patch and issued 'sage -ba'. The 3 tests listed #<a class="ticket" href="https://trac.sagemath.org/ticket/11339#comment:11" title="Comment 11">comment:11</a> all segfault. Let me know if you think my results are "overly" tainted.
</p>
TicketfbisseySat, 18 Jun 2011 20:36:02 GMT
https://trac.sagemath.org/ticket/11339#comment:19
https://trac.sagemath.org/ticket/11339#comment:19
<p>
Replying to <a class="ticket" href="https://trac.sagemath.org/ticket/11339#comment:16" title="Comment 16">vbraun</a>:
</p>
<blockquote class="citation">
<p>
In the case at hand we don't really need the Cython class <code>GroebnerStrategy._parent</code>, only the C struct <code>GroebnerStrategy._parent._ring</code> is used in <code>__deallocate__()</code>. I've made a minimal patch that adds a <code>cdef ring *_parent_ring</code> data member to <code>GroebnerStrategy</code> to keep track of the ring only. Because it refers to a C struct, it is safe to access it the Cython destructor. Because parents are immutable we don't have to worry about the <code>ring *</code> pointer becoming invalid.
</p>
<p>
The patch should fix the crash, but I don't have a Sage-on-Python-2.7 install to test it. Can somebody give it a try?
</p>
</blockquote>
<p>
Does it depend on other patches that are post 4.7.1.alpha2? The feedback so far is that it doesn't work but I noticed there was some work in singular and rings in alpha3 and alpha4. Would it rely on any of these fixes?
</p>
TicketfbisseySat, 18 Jun 2011 21:02:38 GMT
https://trac.sagemath.org/ticket/11339#comment:20
https://trac.sagemath.org/ticket/11339#comment:20
<p>
hum, after looking at the tickets there are not so many that could have an influence (<a class="closed ticket" href="https://trac.sagemath.org/ticket/11218" title="defect: factor is broken for polynomials over relative number fields (closed: fixed)">#11218</a> and <a class="closed ticket" href="https://trac.sagemath.org/ticket/11186" title="defect: Missing parentheses when typesetting coefficients of multivariate ... (closed: fixed)">#11186</a> and they would be long shot). Must have been stuff that I have seen on trac but not yet merged.
</p>
TicketvbraunSat, 18 Jun 2011 21:19:39 GMTstatus changed
https://trac.sagemath.org/ticket/11339#comment:21
https://trac.sagemath.org/ticket/11339#comment:21
<ul>
<li><strong>status</strong>
changed from <em>needs_review</em> to <em>needs_work</em>
</li>
</ul>
<p>
By immutable I meant that the ring of the Parent object can't change. But I wasn't aware that the parent is part of the cycle that the garbage collector is trying to break, then it won't work of course.
</p>
<p>
Actually, if the cycle is Parent <-> <a class="missing wiki">GroebnerStrategy?</a> then I don't understand Martin's orginal patch. By manually increasing the refcount of Parent by one, the garbage collector should conclude that an external reference is keeping the cycle alive, right? Hence <code>__dealloc__</code> would never be run. This fixes the crash, of course, but at the cost of leaking memory?
</p>
<p>
I'm leaning towards refcounting the libsingular rings in C. This would be rather easy to implement, I think.
</p>
<p>
Also, Burcin told me that the need to explicitly reset the ring after the groebner strategy is going to go away in the future. But I would wager that Sage is going to transition to Python 3 first ;-)
</p>
TicketgagernSat, 18 Jun 2011 21:40:38 GMT
https://trac.sagemath.org/ticket/11339#comment:22
https://trac.sagemath.org/ticket/11339#comment:22
<p>
Replying to <a class="ticket" href="https://trac.sagemath.org/ticket/11339#comment:21" title="Comment 21">vbraun</a>:
</p>
<blockquote class="citation">
<p>
But I wasn't aware that the parent is part of the cycle that the
garbage collector is trying to break, then it won't work of course.
</p>
<p>
Actually, if the cycle is Parent <-> <a class="missing wiki">GroebnerStrategy?</a> then I don't understand
Martin's orginal patch.
</p>
</blockquote>
<p>
I'm not sure there really is a cycle. I had interpreted the situation in such a way that tp_clear will be called for unreachable objects just in case there might be some kind of cycle between them. So there might be no actual cycle involved at all, or it might be with some other member object. One requirement is that the function does cut all cycles, which should work as the parent shouldn't be referring back to the Gröbner strategy. So by keeping the reference in one direction, we satisfy tp_clear and still manage to finalize things. As a bonus, we ensure their finalization in the correct order.
</p>
<p>
But I might be completely off target with my above understanding. Someone with intricate knowledge of python, its evolution, as well as cython, might know better.
</p>
<p>
Until then, someone could add breakpoints to see if the finalizer is executed with my patch in place. Don't have the time just now, but might do it myself in a week or so if you remind me.
</p>
TicketvbraunSat, 18 Jun 2011 22:48:15 GMT
https://trac.sagemath.org/ticket/11339#comment:23
https://trac.sagemath.org/ticket/11339#comment:23
<p>
The Python docs say "The <code>tp_clear</code> member function is used to break reference cycles in cyclic garbage detected by the garbage collector.", so there must have been a cycle involving the <code>GroebnerStrategy</code> instance.
</p>
<p>
I looked a bit at the source and we definitely have cycles ideal<-><code>GroebnerStrategy</code>. Both refer to the parent ring, and this explains why <code>tp_clear</code> was called on <code>GroebnerStrategy</code>. I haven't found a place where the parent refers back to the cycle. In this situation Martin's patch should work as we can get rid of the cycle while the parent has positive refcount. It could be that Python 2.7 got smarter and deletes the parent together with the cycle while Python 2.6 first deleted the cycle and only then noticed that nothing else refers to the parent any more. This would explain why Martin's patch works but my attempt of blindly accessing the ring C structure fails on Python 2.7.
</p>
<p>
There is a lot of stuff that could conceivably create a larger cycle involving the parent even though I haven't found one. For one, the parent keeps a reference to the "one" element. Even then, I think it is too dangerous to make the hidden assumption that there are no complete cycles involving the parents. Somebody is bound to trip over this sooner or later.
</p>
TicketvbraunSun, 19 Jun 2011 16:25:11 GMT
https://trac.sagemath.org/ticket/11339#comment:24
https://trac.sagemath.org/ticket/11339#comment:24
<p>
We got this crash in the parent destructor, but look whats in the element destructor:
</p>
<pre class="wiki"> def __dealloc__(self):
# TODO: Warn otherwise!
# for some mysterious reason, various things may be NULL in some cases
if self._parent is not <ParentWithBase>None and (<MPolynomialRing_libsingular>self._parent)._ring != NULL and self._poly != NULL:
p_Delete(&self._poly, (<MPolynomialRing_libsingular>self._parent)._ring)
</pre>
TicketvbraunWed, 22 Jun 2011 21:48:22 GMTstatus, cc, component, description changed
https://trac.sagemath.org/ticket/11339#comment:25
https://trac.sagemath.org/ticket/11339#comment:25
<ul>
<li><strong>status</strong>
changed from <em>needs_work</em> to <em>needs_review</em>
</li>
<li><strong>cc</strong>
<em>malb</em> <em>SimonKing</em> added
</li>
<li><strong>component</strong>
changed from <em>porting</em> to <em>algebra</em>
</li>
<li><strong>description</strong>
modified (<a href="/ticket/11339?action=diff&version=25">diff</a>)
</li>
</ul>
<p>
Ok this should fix it now for good. The first patch introduces refcounting for Singular ring pointers and uses it in <code>GroebnerStrategy</code>, and the second updates <code>MPolynomialRing_libsingular</code> and <code>MPolynomial_libsingular</code>. Please give it a try with Python-2.7...
</p>
TicketfbisseyWed, 22 Jun 2011 22:56:57 GMT
https://trac.sagemath.org/ticket/11339#comment:26
https://trac.sagemath.org/ticket/11339#comment:26
<p>
I have boldly pushed it to the sage-on-gentoo tree and can report that it works fine with python-2.7.1 there on 4.7.1.alpha2. It solved the problem we had but another doctest crashed that looked completely unrelated until I looked at the backtrace:
</p>
<pre class="wiki">sage -t -long -force_lib devel/sage-main/sage/crypto/mq/sr.py # Killed/crashed
</pre><p>
and here is it says when I add -verbose
</p>
<pre class="wiki">Trying:
from sage.crypto.mq.sr import test_consistency###line 3336:_sage_ >>> from sage.crypto.mq.sr import test_consistency
Expecting nothing
ok
Trying:
test_consistency(Integer(1)) # long time (80s on sage.math, 2011)###line 3337:_sage_ >>> test_consistency(1) # long time (80s on sage.math, 2011)
Expecting:
True
/usr/lib64/libcsage.so(print_backtrace+0x24)[0x7f5259023554]
/usr/lib64/libcsage.so(sigdie+0x1d)[0x7f52590235ed]
/usr/lib64/libcsage.so(sage_signal_handler+0x131)[0x7f5259023761]
/lib64/libpthread.so.0(+0xfee0)[0x7f525ca80ee0]
/usr/lib64/libsingular.so.3(_Z7na_CopyP7snumberP9sip_sring+0x79)[0x7f523cc17d47]
/usr/lib64/libsingular.so.3(_Z6pSubstP8spolyreciS0_+0x535)[0x7f523cc41734]
/usr/lib64/python2.7/site-packages/sage/rings/polynomial/multi_polynomial_libsingular.so(+0x548e9)[0x7f523c5de8e9]
/usr/lib64/libpython2.7.so.1.0(PyCFunction_Call+0x76)[0x7f525cd0e1ab]
/usr/lib64/libpython2.7.so.1.0(PyEval_EvalFrameEx+0x53b6)[0x7f525cd68414]
/usr/lib64/libpython2.7.so.1.0(PyEval_EvalCodeEx+0x85f)[0x7f525cd69b65]
/usr/lib64/libpython2.7.so.1.0(PyEval_EvalFrameEx+0x4d3a)[0x7f525cd67d98]
/usr/lib64/libpython2.7.so.1.0(PyEval_EvalCodeEx+0x85f)[0x7f525cd69b65]
/usr/lib64/libpython2.7.so.1.0(PyEval_EvalFrameEx+0x4d3a)[0x7f525cd67d98]
/usr/lib64/libpython2.7.so.1.0(PyEval_EvalCodeEx+0x85f)[0x7f525cd69b65]
/usr/lib64/libpython2.7.so.1.0(PyEval_EvalCode+0x3b)[0x7f525cd69c23]
/usr/lib64/libpython2.7.so.1.0(PyEval_EvalFrameEx+0x2597)[0x7f525cd655f5]
/usr/lib64/libpython2.7.so.1.0(PyEval_EvalCodeEx+0x85f)[0x7f525cd69b65]
/usr/lib64/libpython2.7.so.1.0(+0x6ca97)[0x7f525ccfba97]
/usr/lib64/libpython2.7.so.1.0(PyObject_Call+0x75)[0x7f525ccd9539]
/usr/lib64/libpython2.7.so.1.0(+0x552a9)[0x7f525cce42a9]
/usr/lib64/libpython2.7.so.1.0(PyObject_Call+0x75)[0x7f525ccd9539]
/usr/lib64/libpython2.7.so.1.0(PyEval_EvalFrameEx+0x4ea0)[0x7f525cd67efe]
/usr/lib64/libpython2.7.so.1.0(PyEval_EvalCodeEx+0x85f)[0x7f525cd69b65]
/usr/lib64/libpython2.7.so.1.0(PyEval_EvalFrameEx+0x4d3a)[0x7f525cd67d98]
/usr/lib64/libpython2.7.so.1.0(PyEval_EvalCodeEx+0x85f)[0x7f525cd69b65]
/usr/lib64/libpython2.7.so.1.0(+0x6ca97)[0x7f525ccfba97]
/usr/lib64/libpython2.7.so.1.0(PyObject_Call+0x75)[0x7f525ccd9539]
/usr/lib64/libpython2.7.so.1.0(+0x552a9)[0x7f525cce42a9]
/usr/lib64/libpython2.7.so.1.0(PyObject_Call+0x75)[0x7f525ccd9539]
/usr/lib64/libpython2.7.so.1.0(PyEval_EvalFrameEx+0x4ea0)[0x7f525cd67efe]
/usr/lib64/libpython2.7.so.1.0(PyEval_EvalCodeEx+0x85f)[0x7f525cd69b65]
/usr/lib64/libpython2.7.so.1.0(PyEval_EvalFrameEx+0x4d3a)[0x7f525cd67d98]
/usr/lib64/libpython2.7.so.1.0(PyEval_EvalCodeEx+0x85f)[0x7f525cd69b65]
/usr/lib64/libpython2.7.so.1.0(+0x6ca97)[0x7f525ccfba97]
/usr/lib64/libpython2.7.so.1.0(PyObject_Call+0x75)[0x7f525ccd9539]
/usr/lib64/libpython2.7.so.1.0(+0x552a9)[0x7f525cce42a9]
/usr/lib64/libpython2.7.so.1.0(PyObject_Call+0x75)[0x7f525ccd9539]
/usr/lib64/libpython2.7.so.1.0(PyEval_EvalFrameEx+0x4ea0)[0x7f525cd67efe]
/usr/lib64/libpython2.7.so.1.0(PyEval_EvalCodeEx+0x85f)[0x7f525cd69b65]
/usr/lib64/libpython2.7.so.1.0(PyEval_EvalFrameEx+0x4d3a)[0x7f525cd67d98]
/usr/lib64/libpython2.7.so.1.0(PyEval_EvalCodeEx+0x85f)[0x7f525cd69b65]
/usr/lib64/libpython2.7.so.1.0(PyEval_EvalFrameEx+0x4d3a)[0x7f525cd67d98]
/usr/lib64/libpython2.7.so.1.0(PyEval_EvalCodeEx+0x85f)[0x7f525cd69b65]
/usr/lib64/libpython2.7.so.1.0(PyEval_EvalFrameEx+0x4d3a)[0x7f525cd67d98]
/usr/lib64/libpython2.7.so.1.0(PyEval_EvalCodeEx+0x85f)[0x7f525cd69b65]
/usr/lib64/libpython2.7.so.1.0(PyEval_EvalCode+0x3b)[0x7f525cd69c23]
/usr/lib64/libpython2.7.so.1.0(+0xf3a14)[0x7f525cd82a14]
/usr/lib64/libpython2.7.so.1.0(PyRun_FileExFlags+0xb1)[0x7f525cd83719]
/usr/lib64/libpython2.7.so.1.0(PyRun_SimpleFileExFlags+0x33c)[0x7f525cd8421a]
/usr/lib64/libpython2.7.so.1.0(PyRun_AnyFileExFlags+0x6e)[0x7f525cd84ac1]
/usr/lib64/libpython2.7.so.1.0(Py_Main+0xb92)[0x7f525cd9424a]
/usr/bin/python2.7(main+0x7f)[0x4009e3]
/lib64/libc.so.6(__libc_start_main+0xfd)[0x7f525c70acdd]
/usr/bin/python2.7[0x4008a9]
------------------------------------------------------------------------
Unhandled SIGSEGV: A segmentation fault occurred in Sage.
This probably occurred because a *compiled* component of Sage has a bug
in it and is not properly wrapped with sig_on(), sig_off(). You might
want to run Sage under gdb with 'sage -gdb' to debug this.
Sage will now terminate.
------------------------------------------------------------------------
</pre><p>
It should be double checked with a vanilla install in case it just reveals a problem with my libsingular ebuild.
</p>
TicketvbraunWed, 22 Jun 2011 23:51:50 GMTstatus changed
https://trac.sagemath.org/ticket/11339#comment:27
https://trac.sagemath.org/ticket/11339#comment:27
<ul>
<li><strong>status</strong>
changed from <em>needs_review</em> to <em>needs_info</em>
</li>
</ul>
<p>
I had similar problems, but I thought I fixed them and it did pass tests on my machine. In my experience, they always go away if we leak the ring (which is essentially what we did before) instead of cleaning up after we are done with it. I have a suspicion that, although almost all take a ring as argument, some Singular functions require <code>currRing</code> to be set. This is why I added the inlined <code>_check_ring()</code> function to each <code>MPolynomial_libsingular</code> method to make sure that we have the right <code>currRing</code>.
</p>
<p>
I've added a superfluous <code>p_Normalize</code> call to <code>MPolynomial_libsingular.__dealloc__</code>, this is likely the point where you are crashing. You'll get a more useful backtrace if you paste the offending doctest into <code>sage -gdb</code> and then use "bt".
</p>
<p>
Maybe somebody who is more familiar with the Singular api can chime in and explain precisely where you have to call <code>rChangeCurrRing</code> and where you don't need to.
</p>
<p>
</p>
TicketfbisseyWed, 22 Jun 2011 23:59:52 GMT
https://trac.sagemath.org/ticket/11339#comment:28
https://trac.sagemath.org/ticket/11339#comment:28
<p>
It is one of these annoying one which doesn't seem to happen when you run under gdb. May be I'll have to try a bigger portion of the sequence of commands tested.
</p>
TicketstrogdonThu, 23 Jun 2011 00:49:53 GMT
https://trac.sagemath.org/ticket/11339#comment:29
https://trac.sagemath.org/ticket/11339#comment:29
<p>
Replying to <a class="ticket" href="https://trac.sagemath.org/ticket/11339#comment:25" title="Comment 25">vbraun</a>:
</p>
<blockquote class="citation">
<p>
Ok this should fix it now for good. The first patch introduces refcounting for Singular ring pointers and uses it in <code>GroebnerStrategy</code>, and the second updates <code>MPolynomialRing_libsingular</code> and <code>MPolynomial_libsingular</code>. Please give it a try with Python-2.7...
</p>
</blockquote>
<p>
OK, I applied both the singular_rings and singular_polynomials patches to the 4.7.1.alpha2 that I have and built Sage as in <a class="ticket" href="https://trac.sagemath.org/ticket/11339#comment:18" title="Comment 18">comment:18</a> . As noted above this is not a pristine 4.7.1.alpha2, but has other python-2.7 related patches included; tickets <a class="closed ticket" href="https://trac.sagemath.org/ticket/11377" title="enhancement: Clean and harmonize module_list.py (closed: fixed)">#11377</a>, <a class="closed ticket" href="https://trac.sagemath.org/ticket/11244" title="defect: In python-2.7 deprecation warnings are not shown to the user by default (closed: fixed)">#11244</a>, <a class="closed ticket" href="https://trac.sagemath.org/ticket/9958" title="enhancement: Upgrade python to 2.7.x (closed: fixed)">#9958</a>, <a class="closed ticket" href="https://trac.sagemath.org/ticket/11376" title="enhancement: Remove the hardcoding of python version in setup.py and SConstruct to ... (closed: fixed)">#11376</a> and <a class="closed ticket" href="https://trac.sagemath.org/ticket/10764" title="task: Cleanup a few Cython warnings (closed: fixed)">#10764</a>. There are no segfaults. The testsuite looks like the results when the bug11339a.patch was applied. And I don't get the Killed doctest mentioned by François. Now with just the singular_rings patch I also get no segfaults or crashes. Should I get a crash? I can't see that any of the applied patches could affect things. I will build from scratch, just to make sure.
</p>
TicketfbisseyThu, 23 Jun 2011 03:34:14 GMT
https://trac.sagemath.org/ticket/11339#comment:30
https://trac.sagemath.org/ticket/11339#comment:30
<p>
OK so a proper backtrace. Note that the failing test is marked "long".
</p>
<pre class="wiki">Program received signal SIGSEGV, Segmentation fault.
0x00007fffd79c2d47 in p_Copy (p=0x1, r=0x7ffff445fc38) at pInline2.h:441
441 pInline2.h: No such file or directory.
in pInline2.h
(gdb) bt
#0 0x00007fffd79c2d47 in p_Copy (p=0x1, r=0x7ffff445fc38) at pInline2.h:441
#1 na_Copy (p=0x1, r=0x7ffff445fc38) at longalg.cc:1005
#2 0x00007fffd79ec734 in p_Head (p=<value optimized out>, n=<value optimized out>, e=0x7fffd0d832d0) at pInline1.h:152
#3 pSubst (p=<value optimized out>, n=<value optimized out>, e=0x7fffd0d832d0) at polys.cc:970
#4 0x00007fffd7387998 in __pyx_pf_4sage_5rings_10polynomial_28multi_polynomial_libsingular_23MPolynomial_libsingular_33subs (
__pyx_v_self=0x4d1b370, __pyx_args=<value optimized out>, __pyx_kwds=<value optimized out>)
at sage/rings/polynomial/multi_polynomial_libsingular.cpp:19922
#5 0x00007ffff7aac1ab in PyCFunction_Call (func=0x4ce4908, arg=0x4ea41d0, kw=<value optimized out>) at Objects/methodobject.c:85
#6 0x00007ffff7b06414 in ext_do_call (f=<value optimized out>, throwflag=<value optimized out>) at Python/ceval.c:4322
#7 PyEval_EvalFrameEx (f=<value optimized out>, throwflag=<value optimized out>) at Python/ceval.c:2704
#8 0x00007ffff7b07b65 in PyEval_EvalCodeEx (co=0x1798b30, globals=<value optimized out>, locals=<value optimized out>,
args=<value optimized out>, argcount=2, kws=0x5244750, kwcount=0, defs=0x0, defcount=0, closure=0x0) at Python/ceval.c:3252
#9 0x00007ffff7b05d98 in fast_function (f=<value optimized out>, throwflag=<value optimized out>) at Python/ceval.c:4108
#10 call_function (f=<value optimized out>, throwflag=<value optimized out>) at Python/ceval.c:4033
#11 PyEval_EvalFrameEx (f=<value optimized out>, throwflag=<value optimized out>) at Python/ceval.c:2665
#12 0x00007ffff7b07b65 in PyEval_EvalCodeEx (co=0x3cc92b0, globals=<value optimized out>, locals=<value optimized out>,
args=<value optimized out>, argcount=1, kws=0x523abe8, kwcount=0, defs=0x3ccb6a8, defcount=1, closure=0x0)
at Python/ceval.c:3252
#13 0x00007ffff7b05d98 in fast_function (f=<value optimized out>, throwflag=<value optimized out>) at Python/ceval.c:4108
#14 call_function (f=<value optimized out>, throwflag=<value optimized out>) at Python/ceval.c:4033
#15 PyEval_EvalFrameEx (f=<value optimized out>, throwflag=<value optimized out>) at Python/ceval.c:2665
#16 0x00007ffff7b07b65 in PyEval_EvalCodeEx (co=0x4e985b0, globals=<value optimized out>, locals=<value optimized out>,
args=<value optimized out>, argcount=0, kws=0x0, kwcount=0, defs=0x0, defcount=0, closure=0x0) at Python/ceval.c:3252
#17 0x00007ffff7b07c23 in PyEval_EvalCode (co=<value optimized out>, globals=<value optimized out>, locals=<value optimized out>)
at Python/ceval.c:666
#18 0x00007ffff7b035f5 in exec_statement (f=<value optimized out>, throwflag=<value optimized out>) at Python/ceval.c:4709
#19 PyEval_EvalFrameEx (f=<value optimized out>, throwflag=<value optimized out>) at Python/ceval.c:1879
#20 0x00007ffff7b07b65 in PyEval_EvalCodeEx (co=0x4bddc30, globals=<value optimized out>, locals=<value optimized out>,
args=<value optimized out>, argcount=5, kws=0x0, kwcount=0, defs=0x0, defcount=0, closure=0x0) at Python/ceval.c:3252
#21 0x00007ffff7a99a97 in function_call (func=0x4bafc08, arg=0x552fdd0, kw=0x0) at Objects/funcobject.c:526
#22 0x00007ffff7a77539 in PyObject_Call (func=0x4bafc08, arg=0x552fdd0, kw=0x0) at Objects/abstract.c:2529
#23 0x00007ffff7a822a9 in instancemethod_call (func=0x4bafc08, arg=0x552fdd0, kw=0x0) at Objects/classobject.c:2578
#24 0x00007ffff7a77539 in PyObject_Call (func=0x5450410, arg=0x552fdd0, kw=0x0) at Objects/abstract.c:2529
#25 0x00007ffff7b05efe in do_call (f=<value optimized out>, throwflag=<value optimized out>) at Python/ceval.c:4230
#26 call_function (f=<value optimized out>, throwflag=<value optimized out>) at Python/ceval.c:4035
#27 PyEval_EvalFrameEx (f=<value optimized out>, throwflag=<value optimized out>) at Python/ceval.c:2665
#28 0x00007ffff7b07b65 in PyEval_EvalCodeEx (co=0x4c38c30, globals=<value optimized out>, locals=<value optimized out>,
args=<value optimized out>, argcount=5, kws=0x52444f8, kwcount=0, defs=0x0, defcount=0, closure=0x0) at Python/ceval.c:3252
#29 0x00007ffff7b05d98 in fast_function (f=<value optimized out>, throwflag=<value optimized out>) at Python/ceval.c:4108
#30 call_function (f=<value optimized out>, throwflag=<value optimized out>) at Python/ceval.c:4033
#31 PyEval_EvalFrameEx (f=<value optimized out>, throwflag=<value optimized out>) at Python/ceval.c:2665
#32 0x00007ffff7b07b65 in PyEval_EvalCodeEx (co=0x4bddd30, globals=<value optimized out>, locals=<value optimized out>,
args=<value optimized out>, argcount=4, kws=0x0, kwcount=0, defs=0x0, defcount=0, closure=0x0) at Python/ceval.c:3252
#33 0x00007ffff7a99a97 in function_call (func=0x4bafc80, arg=0x5522050, kw=0x0) at Objects/funcobject.c:526
#34 0x00007ffff7a77539 in PyObject_Call (func=0x4bafc80, arg=0x5522050, kw=0x0) at Objects/abstract.c:2529
#35 0x00007ffff7a822a9 in instancemethod_call (func=0x4bafc80, arg=0x5522050, kw=0x0) at Objects/classobject.c:2578
#36 0x00007ffff7a77539 in PyObject_Call (func=0x5453500, arg=0x5522050, kw=0x0) at Objects/abstract.c:2529
#37 0x00007ffff7b05efe in do_call (f=<value optimized out>, throwflag=<value optimized out>) at Python/ceval.c:4230
#38 call_function (f=<value optimized out>, throwflag=<value optimized out>) at Python/ceval.c:4035
#39 PyEval_EvalFrameEx (f=<value optimized out>, throwflag=<value optimized out>) at Python/ceval.c:2665
#40 0x00007ffff7b07b65 in PyEval_EvalCodeEx (co=0x7ffff289de30, globals=<value optimized out>, locals=<value optimized out>,
args=<value optimized out>, argcount=4, kws=0x5181330, kwcount=0, defs=0x0, defcount=0, closure=0x0) at Python/ceval.c:3252
#41 0x00007ffff7b05d98 in fast_function (f=<value optimized out>, throwflag=<value optimized out>) at Python/ceval.c:4108
#42 call_function (f=<value optimized out>, throwflag=<value optimized out>) at Python/ceval.c:4033
#43 PyEval_EvalFrameEx (f=<value optimized out>, throwflag=<value optimized out>) at Python/ceval.c:2665
#44 0x00007ffff7b07b65 in PyEval_EvalCodeEx (co=0x4bddeb0, globals=<value optimized out>, locals=<value optimized out>,
args=<value optimized out>, argcount=2, kws=0x4c3b618, kwcount=3, defs=0x4bae108, defcount=3, closure=0x0)
at Python/ceval.c:3252
#45 0x00007ffff7a99a97 in function_call (func=0x4bafde8, arg=0x4b2e680, kw=0x473aa50) at Objects/funcobject.c:526
#46 0x00007ffff7a77539 in PyObject_Call (func=0x4bafde8, arg=0x4b2e680, kw=0x473aa50) at Objects/abstract.c:2529
#47 0x00007ffff7a822a9 in instancemethod_call (func=0x4bafde8, arg=0x4b2e680, kw=0x473aa50) at Objects/classobject.c:2578
#48 0x00007ffff7a77539 in PyObject_Call (func=0x37d84b0, arg=0x4b2e680, kw=0x473aa50) at Objects/abstract.c:2529
#49 0x00007ffff7b05efe in do_call (f=<value optimized out>, throwflag=<value optimized out>) at Python/ceval.c:4230
#50 call_function (f=<value optimized out>, throwflag=<value optimized out>) at Python/ceval.c:4035
#51 PyEval_EvalFrameEx (f=<value optimized out>, throwflag=<value optimized out>) at Python/ceval.c:2665
#52 0x00007ffff7b07b65 in PyEval_EvalCodeEx (co=0x7ffff7ec41b0, globals=<value optimized out>, locals=<value optimized out>,
args=<value optimized out>, argcount=2, kws=0x4c68d60, kwcount=0, defs=0x49f56a8, defcount=3, closure=0x0)
at Python/ceval.c:3252
#53 0x00007ffff7b05d98 in fast_function (f=<value optimized out>, throwflag=<value optimized out>) at Python/ceval.c:4108
#54 call_function (f=<value optimized out>, throwflag=<value optimized out>) at Python/ceval.c:4033
#55 PyEval_EvalFrameEx (f=<value optimized out>, throwflag=<value optimized out>) at Python/ceval.c:2665
#56 0x00007ffff7b07b65 in PyEval_EvalCodeEx (co=0x4bd88b0, globals=<value optimized out>, locals=<value optimized out>,
args=<value optimized out>, argcount=0, kws=0x46212b0, kwcount=10, defs=0x4bb8288, defcount=10, closure=0x0)
at Python/ceval.c:3252
#57 0x00007ffff7b05d98 in fast_function (f=<value optimized out>, throwflag=<value optimized out>) at Python/ceval.c:4108
#58 call_function (f=<value optimized out>, throwflag=<value optimized out>) at Python/ceval.c:4033
#59 PyEval_EvalFrameEx (f=<value optimized out>, throwflag=<value optimized out>) at Python/ceval.c:2665
#60 0x00007ffff7b07b65 in PyEval_EvalCodeEx (co=0x4c38ab0, globals=<value optimized out>, locals=<value optimized out>,
args=<value optimized out>, argcount=1, kws=0x6cae88, kwcount=3, defs=0x4bb8068, defcount=10, closure=0x0)
at Python/ceval.c:3252
#61 0x00007ffff7b05d98 in fast_function (f=<value optimized out>, throwflag=<value optimized out>) at Python/ceval.c:4108
#62 call_function (f=<value optimized out>, throwflag=<value optimized out>) at Python/ceval.c:4033
#63 PyEval_EvalFrameEx (f=<value optimized out>, throwflag=<value optimized out>) at Python/ceval.c:2665
#64 0x00007ffff7b07b65 in PyEval_EvalCodeEx (co=0x7ffff7eb7eb0, globals=<value optimized out>, locals=<value optimized out>,
args=<value optimized out>, argcount=0, kws=0x0, kwcount=0, defs=0x0, defcount=0, closure=0x0) at Python/ceval.c:3252
#65 0x00007ffff7b07c23 in PyEval_EvalCode (co=<value optimized out>, globals=<value optimized out>, locals=<value optimized out>)
at Python/ceval.c:666
#66 0x00007ffff7b20a14 in run_mod (mod=<value optimized out>, filename=<value optimized out>, globals=0x640f60, locals=0x640f60,
flags=<value optimized out>, arena=<value optimized out>) at Python/pythonrun.c:1346
#67 0x00007ffff7b21719 in PyRun_FileExFlags (fp=0x6a0530, filename=0x7fffffffddc1 "/home/fbissey/.sage/tmp/.doctest_sr.py",
start=257, globals=0x640f60, locals=0x640f60, closeit=1, flags=0x7fffffffd870) at Python/pythonrun.c:1332
#68 0x00007ffff7b2221a in PyRun_SimpleFileExFlags (fp=0x6a0530, filename=<value optimized out>, closeit=1, flags=0x7fffffffd870)
at Python/pythonrun.c:936
#69 0x00007ffff7b22ac1 in PyRun_AnyFileExFlags (fp=0x6a0530, filename=0x7fffffffddc1 "/home/fbissey/.sage/tmp/.doctest_sr.py",
closeit=1, flags=0x7fffffffd870) at Python/pythonrun.c:740
#70 0x00007ffff7b3224a in Py_Main (argc=<value optimized out>, argv=0x7fffffffd9b8) at Modules/main.c:606
#71 0x00000000004009e3 in main (argc=2, argv=0x7fffffffd9b8) at ./Modules/python.c:46
</pre><p>
I didn't realize you could do something like
</p>
<pre class="wiki">sage -t -long -force_lib devel/sage-main/sage/crypto/mq/sr.py -gdb
</pre><p>
handy...
</p>
TicketfbisseyThu, 23 Jun 2011 03:39:16 GMT
https://trac.sagemath.org/ticket/11339#comment:31
https://trac.sagemath.org/ticket/11339#comment:31
<p>
Since we can even add "-verbose" I should add this bit of output:
</p>
<pre class="wiki">Trying:
test_consistency(Integer(1)) # long time (80s on sage.math, 2011)###line 3337:_sage_ >>> test_consistency(1) # long time (80s on sage.math, 2011)
Expecting:
True
Program received signal SIGSEGV, Segmentation fault.
0x00007fffd79c2d47 in p_Copy (p=0x1, r=0x7ffff445fc38) at pInline2.h:441
441 pInline2.h: No such file or directory.
in pInline2.h
</pre><p>
So it looks like the segfault is after the test has completed, probably when sage is quitting as happened to Steve when he tried to run the test while disabling the garbage collection (before we had any patches what so ever).
</p>
TicketstrogdonThu, 23 Jun 2011 05:41:10 GMT
https://trac.sagemath.org/ticket/11339#comment:32
https://trac.sagemath.org/ticket/11339#comment:32
<p>
I've just completed the testsuite after building vanilla sage-4.7.1.alpha2 from scratch. The patches from tickets <a class="closed ticket" href="https://trac.sagemath.org/ticket/11377" title="enhancement: Clean and harmonize module_list.py (closed: fixed)">#11377</a>, <a class="closed ticket" href="https://trac.sagemath.org/ticket/11244" title="defect: In python-2.7 deprecation warnings are not shown to the user by default (closed: fixed)">#11244</a>, <a class="closed ticket" href="https://trac.sagemath.org/ticket/9958" title="enhancement: Upgrade python to 2.7.x (closed: fixed)">#9958</a>, <a class="closed ticket" href="https://trac.sagemath.org/ticket/11376" title="enhancement: Remove the hardcoding of python version in setup.py and SConstruct to ... (closed: fixed)">#11376</a> and <a class="closed ticket" href="https://trac.sagemath.org/ticket/10764" title="task: Cleanup a few Cython warnings (closed: fixed)">#10764</a> along with the patches of this ticket were used to create a patched sage-4.7.1.alpha2 spkg before the build. The results are identical to those reported earlier. There are no segfaults and no Killed/crashed tests.
</p>
<p>
On my sage-on-gentoo install on x86 in prefix there no segfaults; however, I have one Killed/crashed doctest which I didn't have when using the bug11339a patch.
</p>
<p>
sage -t -long -force_lib "devel/sage-main/sage/libs/singular/option.pyx" -gdb
</p>
<pre class="wiki">
Program received signal SIGSEGV, Segmentation fault.
0xb3b16d29 in _nlDelete_NoImm(snumber**) () from /storage/strogdon/gentoo/usr/lib/libsingular.so.3
(gdb) bt
#0 0xb3b16d29 in _nlDelete_NoImm(snumber**) () from /storage/strogdon/gentoo/usr/lib/libsingular.so.3
#1 0xb3bd831d in p_Delete__FieldQ_LengthGeneral_OrdGeneral () from /storage/strogdon/gentoo/usr/lib/libsingular.so.3
#2 0xb3acde01 in id_Delete(sip_sideal**, sip_sring*) () from /storage/strogdon/gentoo/usr/lib/libsingular.so.3
#3 0xb3a70736 in sleftv::CleanUp(sip_sring*) () from /storage/strogdon/gentoo/usr/lib/libsingular.so.3
#4 0xb37f490e in __pyx_f_4sage_4libs_8singular_8function_free_leftv(sleftv*) () from /storage/strogdon/gentoo/usr/lib/python2.7/site-packages/sage/libs/singular/function.so
#5 0xb3805653 in __pyx_f_4sage_4libs_8singular_8function_call_function(__pyx_obj_4sage_4libs_8singular_8function_SingularFunction*, _object*, __pyx_obj_4sage_5rings_10polynomial_28multi_polynomial_libsingular_MPolynomialRing_libsingular*, __pyx_opt_args_4sage_4libs_8singular_8function_call_function*) () from /storage/strogdon/gentoo/usr/lib/python2.7/site-packages/sage/libs/singular/function.so
#6 0xb3806843 in __pyx_pf_4sage_4libs_8singular_8function_16SingularFunction_2__call__(_object*, _object*, _object*) () from /storage/strogdon/gentoo/usr/lib/python2.7/site-packages/sage/libs/singular/function.so
#7 0xb7e9fffb in PyObject_Call () from /storage/strogdon/gentoo/usr/lib/libpython2.7.so.1.0
#8 0xb7f3a0a4 in PyEval_EvalFrameEx () from /storage/strogdon/gentoo/usr/lib/libpython2.7.so.1.0
#9 0xb7f3c8e1 in PyEval_EvalCodeEx () from /storage/strogdon/gentoo/usr/lib/libpython2.7.so.1.0
#10 0xb7f3ca34 in PyEval_EvalCode () from /storage/strogdon/gentoo/usr/lib/libpython2.7.so.1.0
#11 0xb7f3bbb2 in PyEval_EvalFrameEx () from /storage/strogdon/gentoo/usr/lib/libpython2.7.so.1.0
#12 0xb7f3c8e1 in PyEval_EvalCodeEx () from /storage/strogdon/gentoo/usr/lib/libpython2.7.so.1.0
#13 0xb7ec7c58 in function_call () from /storage/strogdon/gentoo/usr/lib/libpython2.7.so.1.0
#14 0xb7e9fffb in PyObject_Call () from /storage/strogdon/gentoo/usr/lib/libpython2.7.so.1.0
#15 0xb7eafaae in instancemethod_call () from /storage/strogdon/gentoo/usr/lib/libpython2.7.so.1.0
#16 0xb7e9fffb in PyObject_Call () from /storage/strogdon/gentoo/usr/lib/libpython2.7.so.1.0
#17 0xb7f3a0a4 in PyEval_EvalFrameEx () from /storage/strogdon/gentoo/usr/lib/libpython2.7.so.1.0
#18 0xb7f3c8e1 in PyEval_EvalCodeEx () from /storage/strogdon/gentoo/usr/lib/libpython2.7.so.1.0
#19 0xb7f3ab11 in PyEval_EvalFrameEx () from /storage/strogdon/gentoo/usr/lib/libpython2.7.so.1.0
#20 0xb7f3c8e1 in PyEval_EvalCodeEx () from /storage/strogdon/gentoo/usr/lib/libpython2.7.so.1.0
#21 0xb7ec7c58 in function_call () from /storage/strogdon/gentoo/usr/lib/libpython2.7.so.1.0
#22 0xb7e9fffb in PyObject_Call () from /storage/strogdon/gentoo/usr/lib/libpython2.7.so.1.0
#23 0xb7eafaae in instancemethod_call () from /storage/strogdon/gentoo/usr/lib/libpython2.7.so.1.0
#24 0xb7e9fffb in PyObject_Call () from /storage/strogdon/gentoo/usr/lib/libpython2.7.so.1.0
#25 0xb7f3a0a4 in PyEval_EvalFrameEx () from /storage/strogdon/gentoo/usr/lib/libpython2.7.so.1.0
#26 0xb7f3c8e1 in PyEval_EvalCodeEx () from /storage/strogdon/gentoo/usr/lib/libpython2.7.so.1.0
#27 0xb7f3ab11 in PyEval_EvalFrameEx () from /storage/strogdon/gentoo/usr/lib/libpython2.7.so.1.0
#28 0xb7f3c8e1 in PyEval_EvalCodeEx () from /storage/strogdon/gentoo/usr/lib/libpython2.7.so.1.0
#29 0xb7ec7d43 in function_call () from /storage/strogdon/gentoo/usr/lib/libpython2.7.so.1.0
#30 0xb7e9fffb in PyObject_Call () from /storage/strogdon/gentoo/usr/lib/libpython2.7.so.1.0
#31 0xb7eafaae in instancemethod_call () from /storage/strogdon/gentoo/usr/lib/libpython2.7.so.1.0
#32 0xb7e9fffb in PyObject_Call () from /storage/strogdon/gentoo/usr/lib/libpython2.7.so.1.0
#33 0xb7f3a0a4 in PyEval_EvalFrameEx () from /storage/strogdon/gentoo/usr/lib/libpython2.7.so.1.0
#34 0xb7f3c8e1 in PyEval_EvalCodeEx () from /storage/strogdon/gentoo/usr/lib/libpython2.7.so.1.0
#35 0xb7f3ab11 in PyEval_EvalFrameEx () from /storage/strogdon/gentoo/usr/lib/libpython2.7.so.1.0
#36 0xb7f3c8e1 in PyEval_EvalCodeEx () from /storage/strogdon/gentoo/usr/lib/libpython2.7.so.1.0
#37 0xb7f3ab11 in PyEval_EvalFrameEx () from /storage/strogdon/gentoo/usr/lib/libpython2.7.so.1.0
#38 0xb7f3c8e1 in PyEval_EvalCodeEx () from /storage/strogdon/gentoo/usr/lib/libpython2.7.so.1.0
#39 0xb7f3ab11 in PyEval_EvalFrameEx () from /storage/strogdon/gentoo/usr/lib/libpython2.7.so.1.0
#40 0xb7f3c8e1 in PyEval_EvalCodeEx () from /storage/strogdon/gentoo/usr/lib/libpython2.7.so.1.0
#41 0xb7f3ca34 in PyEval_EvalCode () from /storage/strogdon/gentoo/usr/lib/libpython2.7.so.1.0
#42 0xb7f5659c in run_mod () from /storage/strogdon/gentoo/usr/lib/libpython2.7.so.1.0
#43 0xb7f57483 in PyRun_FileExFlags () from /storage/strogdon/gentoo/usr/lib/libpython2.7.so.1.0
#44 0xb7f5815c in PyRun_SimpleFileExFlags () from /storage/strogdon/gentoo/usr/lib/libpython2.7.so.1.0
#45 0xb7f58cf2 in PyRun_AnyFileExFlags () from /storage/strogdon/gentoo/usr/lib/libpython2.7.so.1.0
#46 0xb7f6a35f in Py_Main () from /storage/strogdon/gentoo/usr/lib/libpython2.7.so.1.0
#47 0x0804888b in main ()
</pre>
TicketmalbThu, 23 Jun 2011 10:07:53 GMT
https://trac.sagemath.org/ticket/11339#comment:33
https://trac.sagemath.org/ticket/11339#comment:33
<p>
Replying to <a class="ticket" href="https://trac.sagemath.org/ticket/11339#comment:27" title="Comment 27">vbraun</a>:
</p>
<p>
Hi, first: thanks for cleaning up the mess that no-doubt I made.
</p>
<blockquote class="citation">
<p>
I had similar problems, but I thought I fixed them and it did pass tests on my
machine. In my experience, they always go away if we leak the ring (which is
essentially what we did before) instead of cleaning up after we are done with it.
</p>
</blockquote>
<p>
Ah, this might also explain <a class="new ticket" href="https://trac.sagemath.org/ticket/5949" title="defect: memory leak when deleting polynomial rings involving libSingular (new)">#5949</a> then.
</p>
<blockquote class="citation">
<p>
I have a suspicion that, although almost all take a ring as argument, some Singular
functions require <code>currRing</code> to be set.
</p>
</blockquote>
<p>
The API is as follows: <code>pXXX</code> does assume the <code>currRing</code> to be set, whereas <code>p_XXX</code> does not. However, sometimes there are bugs, i.e. you call <code>p_XXX</code> and it crashes unless <code>currRing</code> is set.
</p>
<blockquote class="citation">
<p>
This is why I added the inlined <code>_check_ring()</code> function to each <code>MPolynomial_libsingular</code> method to make
sure that we have the right <code>currRing</code>.
</p>
</blockquote>
<p>
TBH, I don't like this blanket approach, did you run into specific problems? If so, I'd add a check to those functions instead of hiding bugs by forcing the ring.
</p>
TicketvbraunThu, 23 Jun 2011 10:40:38 GMT
https://trac.sagemath.org/ticket/11339#comment:34
https://trac.sagemath.org/ticket/11339#comment:34
<p>
Replying to <a class="ticket" href="https://trac.sagemath.org/ticket/11339#comment:33" title="Comment 33">malb</a>:
</p>
<blockquote class="citation">
<p>
The API is as follows: <code>pXXX</code> does assume the <code>currRing</code> to be set, whereas <code>p_XXX</code> does not. However, sometimes there are bugs, i.e. you call <code>p_XXX</code> and it crashes unless <code>currRing</code> is set.
</p>
</blockquote>
<p>
I guessed that much, but a documented list of exceptions to that rule might be nice :-)
</p>
<blockquote class="citation">
<p>
TBH, I don't like this blanket approach, did you run into specific problems? If so, I'd add a check to those functions instead of hiding bugs by forcing the ring.
</p>
</blockquote>
<p>
In principle I agree, but its probably more productive to first produce a working version and then see if it still works if we remove the blanket <code>rChangeCurrRing</code>. Right now I'm not sure if that is the underlying problem. I didn't find any 100% reliable testcase but in some cases adding the extra ring switch fixed segfaults, but only to reappear in other places.
</p>
TicketvbraunThu, 23 Jun 2011 13:17:30 GMTstatus changed
https://trac.sagemath.org/ticket/11339#comment:35
https://trac.sagemath.org/ticket/11339#comment:35
<ul>
<li><strong>status</strong>
changed from <em>needs_info</em> to <em>needs_review</em>
</li>
</ul>
<p>
The updated polynomials patch fixes another place where potentially the wrong singular ring was used, which would explain the data corruption. Please give it a try!
</p>
<p>
I'm pretty sure that <code>p_Normalize</code> requires <code>currRing</code> to be set. In the polynomials destructor, I have
</p>
<pre class="wiki"> ### If you suspect that the poly data was corrupted, then this is a good way to trigger a segfault:
rChangeCurrRing(self._parent_ring)
p_Normalize(self._poly, self._parent_ring)
</pre><p>
This is useful for debugging because <code>p_Normalize</code> will touch all coefficients of the polynomial. The destructor is typically called long after the actual computations so it is very likely that the <code>currRing</code> has changed by then. If I reverse the order of the two lines, then I get segfaults all over the Sage library. However, because it relies on the finalization order, they are usually in varying places and often disappear if you just paste the doctest into Sage.
</p>
TicketfbisseyThu, 23 Jun 2011 22:30:50 GMT
https://trac.sagemath.org/ticket/11339#comment:36
https://trac.sagemath.org/ticket/11339#comment:36
<p>
It seems to have taken care of my problem. Thanks Volker. Now we should wait to see if it did something for Steve.
</p>
TicketstrogdonFri, 24 Jun 2011 03:57:57 GMT
https://trac.sagemath.org/ticket/11339#comment:37
https://trac.sagemath.org/ticket/11339#comment:37
<p>
Replying to <a class="ticket" href="https://trac.sagemath.org/ticket/11339#comment:35" title="Comment 35">vbraun</a>:
</p>
<blockquote class="citation">
<p>
The updated polynomials patch fixes another place where potentially the wrong singular ring was used, which would explain the data corruption. Please give it a try!
</p>
</blockquote>
<p>
My vanilla sage-4.7.1.alpha2 has no segfaults or Killed/crashed tests with the new patch. The patch seems to cure the doctest failure (option.pyx) I had on my sage-on-gentoo install on x86. However on amd64 (sage-on-gentoo) I have a Segmentation fault with the doctest
</p>
<pre class="wiki">sage -t -long -force_lib devel/sage-main/sage/schemes/elliptic_curves/ell_curve_isogeny.py
</pre><p>
I'll attach files of the Segmentation fault and debug/backtrace.
</p>
TicketstrogdonFri, 24 Jun 2011 04:01:12 GMTattachment set
https://trac.sagemath.org/ticket/11339
https://trac.sagemath.org/ticket/11339
<ul>
<li><strong>attachment</strong>
set to <em>ell_curve_isogeny.segfault.bz2</em>
</li>
</ul>
<p>
Segmentation fault associated with
</p>
TicketstrogdonFri, 24 Jun 2011 04:03:31 GMTattachment set
https://trac.sagemath.org/ticket/11339
https://trac.sagemath.org/ticket/11339
<ul>
<li><strong>attachment</strong>
set to <em>ell_curve_isogeny.gdb.bz2</em>
</li>
</ul>
<p>
ell_curve_isogeny.py debug/backtrace
</p>
TicketleifFri, 24 Jun 2011 18:53:27 GMTcc changed
https://trac.sagemath.org/ticket/11339#comment:38
https://trac.sagemath.org/ticket/11339#comment:38
<ul>
<li><strong>cc</strong>
<em>leif</em> added
</li>
</ul>
TicketvbraunSat, 25 Jun 2011 12:11:23 GMTstatus changed
https://trac.sagemath.org/ticket/11339#comment:39
https://trac.sagemath.org/ticket/11339#comment:39
<ul>
<li><strong>status</strong>
changed from <em>needs_review</em> to <em>needs_info</em>
</li>
</ul>
<p>
I built a sage spkg with Singular's polynomials debugging turned on (<code>PDEBUG=2</code>) and now Singular spits out tons of memory allocation errors during Sage startup (turns out Sage does some high-degree polynomial computations during startup). Can somebody who understands Singular better comment on whether those are real errors?
</p>
<p>
<a class="ext-link" href="http://www.stp.dias.ie/~vbraun/Sage/spkg/singularDEBUG-3-1-1-4.p9.spkg"><span class="icon"></span>http://www.stp.dias.ie/~vbraun/Sage/spkg/singularDEBUG-3-1-1-4.p9.spkg</a>
</p>
<p>
Note that its not as easy as turning on <code>SAGE_DEBUG</code>; the Singular spkg-install does set a configure option in that case but its not doing anything. I also had to fix up an instance where an <code>#ifdef PDEBUG</code> replaced a libSingular function by a macro.
</p>
TicketmalbSat, 25 Jun 2011 13:54:34 GMT
https://trac.sagemath.org/ticket/11339#comment:40
https://trac.sagemath.org/ticket/11339#comment:40
<p>
I sent and e-mail to [libsingular-devel], cf. <a class="ext-link" href="http://groups.google.com/group/libsingular-devel/browse_thread/thread/71fcd01208f107ca"><span class="icon"></span>http://groups.google.com/group/libsingular-devel/browse_thread/thread/71fcd01208f107ca</a>
</p>
TicketvbraunSat, 25 Jun 2011 14:00:17 GMT
https://trac.sagemath.org/ticket/11339#comment:41
https://trac.sagemath.org/ticket/11339#comment:41
<p>
The omalloc error gets triggered by fraction field conversions. If you take out some stuff from ell_curve_isogeny.py then you can start up Sage just fine. I'll attach a patch for debugging purposes.
</p>
<p>
The omalloc errors appear with or without my patches on this ticket, by the way.
</p>
TicketvbraunSat, 25 Jun 2011 14:01:02 GMTattachment set
https://trac.sagemath.org/ticket/11339
https://trac.sagemath.org/ticket/11339
<ul>
<li><strong>attachment</strong>
set to <em>remove_polys.patch</em>
</li>
</ul>
<p>
Remove some initialization form ell_curve_isogeny.py for debugging.
</p>
TicketfbisseySun, 26 Jun 2011 20:28:45 GMT
https://trac.sagemath.org/ticket/11339#comment:42
https://trac.sagemath.org/ticket/11339#comment:42
<p>
Just for the record while I am working on stuff. It seems there are no problems on amd64 all the problems seem to arise on the x86 side. So I upgraded to 4.7.1.alpha3 and ran the long tests on my 2003 x86 box. 16 hours later I have three doctests crashes that may be related (currently setting proper debugging on that box) and i seem to have lost the test.log :P - just great. Anyway I'll have a look at the extra debugging in libsingular. If there is a problem with omalloc could we switch to the system malloc? I think there is an option for that (whether it is working or not is another matter).
</p>
TicketfbisseySun, 26 Jun 2011 20:37:05 GMT
https://trac.sagemath.org/ticket/11339#comment:43
https://trac.sagemath.org/ticket/11339#comment:43
<p>
One was: sage/modular/modform/element.py, now that I have started to include debugging info it seems to behave, may be it was the load.
</p>
TicketfbisseyThu, 07 Jul 2011 23:13:15 GMT
https://trac.sagemath.org/ticket/11339#comment:44
https://trac.sagemath.org/ticket/11339#comment:44
<p>
OK back to singular problems. On my OS X (10.5.8 32bits) box I got another test crash:
</p>
<pre class="wiki">sage -t -long -force_lib devel/sage-main/sage/rings/polynomial/toy_buchberger.py
</pre><p>
and the following backtrace
</p>
<pre class="wiki">Program received signal EXC_BAD_ACCESS, Could not access memory.
Reason: KERN_PROTECTION_FAILURE at address: 0x0000001a
0x062ad4e5 in nlNormalize ()
(gdb) bt
#0 0x062ad4e5 in nlNormalize ()
#1 0x062ad78b in nlInt ()
#2 0x06cdcca6 in __pyx_f_4sage_4libs_8singular_8singular_si2sa ()
#3 0x06bb7f07 in __pyx_f_4sage_5rings_10polynomial_28multi_polynomial_libsingular_23MPolynomial_libsingular__hash_c ()
#4 0x06b5c263 in __pyx_pf_4sage_5rings_10polynomial_28multi_polynomial_libsingular_23MPolynomial_libsingular_6__hash__ ()
#5 0x00203ee4 in set_add_key ()
#6 0x00203f39 in set_add ()
#7 0x00255e2b in PyEval_EvalFrameEx ()
</pre><p>
This is with 4.7.1.alpha4. I'll try again on the linux x86 box this weekend (and not lose the logs this time). It may be the last test I run on that box for a while.
</p>
TicketstrogdonFri, 08 Jul 2011 00:26:09 GMT
https://trac.sagemath.org/ticket/11339#comment:45
https://trac.sagemath.org/ticket/11339#comment:45
<p>
Replying to <a class="ticket" href="https://trac.sagemath.org/ticket/11339#comment:44" title="Comment 44">fbissey</a>:
</p>
<blockquote class="citation">
<p>
OK back to singular problems. On my OS X (10.5.8 32bits) box I got another test crash: <code> sage -t -long -force_lib devel/sage-main/sage/rings/polynomial/toy_buchberger.py </code>
</p>
</blockquote>
<p>
I get the same failure on amd64 (vanilla sage-4.7.1.alpha4) but with a slightly different backtrace. Here is the beginning of the backtrace:
</p>
<pre class="wiki">Program received signal SIGSEGV, Segmentation fault.
nlNormalize (x=@0x7fffffffac68) at longrat.cc:1221
1221 longrat.cc: No such file or directory.
in longrat.cc
(gdb) bt
#0 nlNormalize (x=@0x7fffffffac68) at longrat.cc:1221
#1 0x00007fffdb2caafe in nlInt (i=@0x7fffffffac68, r=<value optimized out>)
at longrat.cc:494
#2 0x00007fffda13f4f1 in __pyx_f_4sage_4libs_8singular_8singular_si2sa (
__pyx_v_n=0x2, __pyx_v__ring=0x7fffdb0a3760, __pyx_v_base=0x4964000)
at sage/libs/singular/singular.cpp:5508
#3 0x00007fffdabf216a in __pyx_f_4sage_5rings_10polynomial_28multi_polynomial_libsingular_23MPolynomial_libsingular__hash_c (__pyx_v_self=<value optimized out>)
at sage/rings/polynomial/multi_polynomial_libsingular.cpp:18417
#4 0x00007fffdabdc66b in __pyx_pf_4sage_5rings_10polynomial_28multi_polynomial_libsingular_23MPolynomial_libsingular_6__hash__ (__pyx_v_self=<value optimized out>)
at sage/rings/polynomial/multi_polynomial_libsingular.cpp:14965
#5 0x00007ffff7a8dde8 in set_add_key (so=0x483b138, key=0x495b9b0)
at Objects/setobject.c:386
#6 0x00007ffff7a8de39 in set_add (so=<value optimized out>,
key=<value optimized out>) at Objects/setobject.c:1837
#7 0x00007ffff7af0fa4 in call_function (oparg=<value optimized out>,
pp_stack=0x7fffffffae50) at Python/ceval.c:4000
#8 PyEval_EvalFrameEx (f=<value optimized out>, throwflag=<value optimized out>)
at Python/ceval.c:2665
#9 0x00007ffff7af1824 in fast_function (nk=<value optimized out>,
na=<value optimized out>, n=<value optimized out>, pp_stack=0x7fffffffafc0,
func=0x152da28) at Python/ceval.c:4098
</pre><p>
I get no crashes when running the testsuite on x86.
</p>
TicketfbisseyFri, 08 Jul 2011 02:31:45 GMT
https://trac.sagemath.org/ticket/11339#comment:46
https://trac.sagemath.org/ticket/11339#comment:46
<p>
yes you have more details. Traces with gdb on OS X is just difficult. But I don't get that one on any of my two amd64 boxes. I will try that particular test on x86.
</p>
TicketfbisseySat, 09 Jul 2011 03:27:10 GMT
https://trac.sagemath.org/ticket/11339#comment:47
https://trac.sagemath.org/ticket/11339#comment:47
<p>
i get the failure in sage/schemes/elliptic_curves/ell_curve_isogeny.py on my x86 box same backtrace as <a class="ticket" href="https://trac.sagemath.org/ticket/11339#comment:35" title="Comment 35">comment:35</a> - sage/modular/modform/element.py still seem to play up, it crashes when I run sage -testall but not when I run it individually. Note that I don't parallel testing on that machine. Wait a minute it crashed after I added -long.
</p>
<pre class="wiki">sage -t -long -force_lib "devel/sage/sage/modular/modform/element.py"
The doctested process was killed by signal 8
[62.7 s]
----------------------------------------------------------------------
The following tests failed:
sage -t -long -force_lib "devel/sage/sage/modular/modform/element.py" # Killed/crashed
Total time for all tests: 62.7 seconds
</pre><p>
Unfortunately it disappear again when in gdb:
</p>
<pre class="wiki">francois@vrooom ~ $ sage -t -long -force_lib "devel/sage/sage/modular/modform/element.py" -gdb
sage -t -long -force_lib -gdb "devel/sage/sage/modular/modform/element.py"
********************************************************************************
Type r at the (gdb) prompt to run the doctests.
Type bt if there is a crash to see a traceback.
********************************************************************************
GNU gdb (Gentoo 7.2 p1) 7.2
Copyright (C) 2010 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/gpl.html>
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law. Type "show copying"
and "show warranty" for details.
This GDB was configured as "i686-pc-linux-gnu".
For bug reporting instructions, please see:
<http://bugs.gentoo.org/>...
Reading symbols from /usr/bin/python...(no debugging symbols found)...done.
(gdb) run
Starting program: /usr/bin/python /home/francois/.sage/tmp/.doctest_element.py
process 27984 is executing new program: /usr/bin/python2.7
[Thread debugging using libthread_db enabled]
Traceback (most recent call last):
File "/usr/share/gdb/auto-load/usr/lib/gcc/i686-pc-linux-gnu/4.5.2/libstdc++.so.6.0.14-gdb.py", line 59, in <module>
from libstdcxx.v6.printers import register_libstdcxx_printers
ImportError: No module named libstdcxx.v6.printers
Program exited normally.
</pre>
TicketfbisseySat, 09 Jul 2011 03:31:11 GMT
https://trac.sagemath.org/ticket/11339#comment:48
https://trac.sagemath.org/ticket/11339#comment:48
<p>
Disregard sage/modular/modform/element.py. Our old friend ATLAS-3.9.xx is responsible for that one. With -verbose:
</p>
<pre class="wiki">Trying:
f = ModularForms(Gamma1(Integer(3)), Integer(7)).gen(0)###line 1016:_sage_ >>> f = ModularForms(Gamma1(3), 7).0
Expecting nothing
ok
Trying:
f*f###line 1017:_sage_ >>> f*f
Expecting:
q^2 - 54*q^4 + 128*q^5 + O(q^6)
/usr/lib/libcsage.so(print_backtrace+0x40)[0xb6e35acf]
/usr/lib/libcsage.so(sigdie+0x22)[0xb6e35b92]
/usr/lib/libcsage.so(sage_signal_handler+0x1a3)[0xb6e35d84]
[0xb77cc400]
/usr/lib/libgmp.so.3(__gmpz_set_d+0x49)[0xb689a2b9]
/usr/lib/libiml.so.0(ChineseRemainder+0x1af)[0xb3055b1f]
------------------------------------------------------------------------
Unhandled SIGFPE: An unhandled floating point exception occurred in Sage.
This probably occurred because a *compiled* component of Sage has a bug
in it and is not properly wrapped with sig_on(), sig_off(). You might
want to run Sage under gdb with 'sage -gdb' to debug this.
Sage will now terminate.
------------------------------------------------------------------------
The doctested process was killed by signal 8
</pre>
TicketvbraunSat, 09 Jul 2011 20:01:22 GMT
https://trac.sagemath.org/ticket/11339#comment:49
https://trac.sagemath.org/ticket/11339#comment:49
<p>
Something is wrong with atlas-3.9.x and linbox.
</p>
<p>
I built libSingular with debugging turned on, but that shows lots and lots of errors. I'm not sure if all of them are actual bugs, but I think its likely that they are the origin of the segfaults. See <a class="ext-link" href="https://groups.google.com/d/msg/libsingular-devel/cfzQEgjxB8o/dvb2Efc-7pIJ"><span class="icon"></span>https://groups.google.com/d/msg/libsingular-devel/cfzQEgjxB8o/dvb2Efc-7pIJ</a>
</p>
TicketfbisseySun, 10 Jul 2011 02:25:47 GMT
https://trac.sagemath.org/ticket/11339#comment:50
https://trac.sagemath.org/ticket/11339#comment:50
<p>
Replying to <a class="ticket" href="https://trac.sagemath.org/ticket/11339#comment:49" title="Comment 49">vbraun</a>:
</p>
<blockquote class="citation">
<p>
Something is wrong with atlas-3.9.x and linbox.
</p>
</blockquote>
<p>
I know about that. I have known about a similar problem with iml for longer <a class="ext-link" href="https://github.com/cschwan/sage-on-gentoo/issues/3"><span class="icon"></span>https://github.com/cschwan/sage-on-gentoo/issues/3</a>. Both iml and linbox fail after calling a routine called (or including the words) <a class="missing wiki">ChineseRemainder?</a> which uses results from calls to cblas_dgemv and cblas_dgemm but this comment really belongs to <a class="closed ticket" href="https://trac.sagemath.org/ticket/10508" title="enhancement: Update ATLAS to stable version 3.10.1 (closed: fixed)">#10508</a>.
</p>
<blockquote class="citation">
<p>
I built libSingular with debugging turned on, but that shows lots and lots of errors. I'm not sure if all of them are actual bugs, but I think its likely that they are the origin of the segfaults. See <a class="ext-link" href="https://groups.google.com/d/msg/libsingular-devel/cfzQEgjxB8o/dvb2Efc-7pIJ"><span class="icon"></span>https://groups.google.com/d/msg/libsingular-devel/cfzQEgjxB8o/dvb2Efc-7pIJ</a>
</p>
</blockquote>
<p>
I know this is a slow time of the year in the northern emisphere (starting semester two tomorrow down under) but nothing since June 27th? May be the thread should be bumped or something.
</p>
TicketfbisseyMon, 08 Aug 2011 23:29:27 GMT
https://trac.sagemath.org/ticket/11339#comment:51
https://trac.sagemath.org/ticket/11339#comment:51
<p>
Still got the failure schemes/elliptic_curves/ell_curve_isogeny.py on amd64 with 4.7.2_alpha0. That's the only killed doctest so far on this set up.
</p>
TicketstrogdonMon, 22 Aug 2011 04:48:39 GMT
https://trac.sagemath.org/ticket/11339#comment:52
https://trac.sagemath.org/ticket/11339#comment:52
<p>
Here's an update since 4.7.2.alpha1 has been released. refcount_singular_polynomials.patch applies just fine but there is fuzz with refcount_singular_rings.patch
</p>
<pre class="wiki">
applying /storage/sage/patches/trac_11339_refcount_singular_rings.patch
patching file sage/libs/singular/ring.pyx
Hunk #1 succeeded at 57 with fuzz 2 (offset 5 lines).
</pre><p>
I get the following failures (killed/crashed):
</p>
<p>
x86:
</p>
<p>
sage -t -long -force_lib devel/sage-main/sage/crypto/mq/mpolynomialsystem.py
</p>
<p>
amd64:
</p>
<p>
sage -t -long -force_lib devel/sage-main/sage/schemes/elliptic_curves/ell_number_field.py
</p>
<p>
sage -t -long -force_lib devel/sage-main/sage/crypto/mq/mpolynomialsystem.py
</p>
<p>
sage -t -long -force_lib devel/sage-main/sage/crypto/mq/sr.py
</p>
TicketfbisseyMon, 22 Aug 2011 05:03:45 GMT
https://trac.sagemath.org/ticket/11339#comment:53
https://trac.sagemath.org/ticket/11339#comment:53
<p>
Replying to <a class="ticket" href="https://trac.sagemath.org/ticket/11339#comment:52" title="Comment 52">strogdon</a>:
</p>
<blockquote class="citation">
<p>
Here's an update since 4.7.2.alpha1 has been released. refcount_singular_polynomials.patch applies just fine but there is fuzz with refcount_singular_rings.patch
</p>
<pre class="wiki">
applying /storage/sage/patches/trac_11339_refcount_singular_rings.patch
patching file sage/libs/singular/ring.pyx
Hunk #1 succeeded at 57 with fuzz 2 (offset 5 lines).
</pre><p>
I get the following failures (killed/crashed):
</p>
<p>
x86:
</p>
<p>
sage -t -long -force_lib devel/sage-main/sage/crypto/mq/mpolynomialsystem.py
</p>
<p>
amd64:
</p>
<p>
sage -t -long -force_lib devel/sage-main/sage/schemes/elliptic_curves/ell_number_field.py
</p>
<p>
sage -t -long -force_lib devel/sage-main/sage/crypto/mq/mpolynomialsystem.py
</p>
<p>
sage -t -long -force_lib devel/sage-main/sage/crypto/mq/sr.py
</p>
</blockquote>
<p>
Vanilla or sage-on-gentoo (sog) variety? So far for sog I still only have the sage/schemes/elliptic_curves/ell_curve_isogeny.py crash but nothing else on amd64.
</p>
<p>
My linux-x86 box is "decommissioned", I'll look on x86 OS X next.
</p>
<p>
Haven't had time to try vanilla.
</p>
TicketstrogdonMon, 22 Aug 2011 05:11:45 GMT
https://trac.sagemath.org/ticket/11339#comment:54
https://trac.sagemath.org/ticket/11339#comment:54
<p>
Replying to <a class="ticket" href="https://trac.sagemath.org/ticket/11339#comment:53" title="Comment 53">fbissey</a>:
</p>
<blockquote class="citation">
<p>
Replying to <a class="ticket" href="https://trac.sagemath.org/ticket/11339#comment:52" title="Comment 52">strogdon</a>:
</p>
<blockquote class="citation">
<p>
Here's an update since 4.7.2.alpha1 has been released. refcount_singular_polynomials.patch applies just fine but there is fuzz with refcount_singular_rings.patch <code> applying /storage/sage/patches/trac_11339_refcount_singular_rings.patch patching file sage/libs/singular/ring.pyx Hunk #1 succeeded at 57 with fuzz 2 (offset 5 lines). </code> I get the following failures (killed/crashed): x86: sage -t -long -force_lib devel/sage-main/sage/crypto/mq/mpolynomialsystem.py amd64: sage -t -long -force_lib devel/sage-main/sage/schemes/elliptic_curves/ell_number_field.py sage -t -long -force_lib devel/sage-main/sage/crypto/mq/mpolynomialsystem.py sage -t -long -force_lib devel/sage-main/sage/crypto/mq/sr.py
</p>
</blockquote>
<p>
Vanilla or sage-on-gentoo (sog) variety? So far for sog I still only have the sage/schemes/elliptic_curves/ell_curve_isogeny.py crash but nothing else on amd64. My linux-x86 box is "decommissioned", I'll look on x86 OS X next. Haven't had time to try vanilla.
</p>
</blockquote>
<p>
This is for vanilla Sage. I've just started on sage-on-gentoo builds.
</p>
TicketfbisseyWed, 24 Aug 2011 23:56:59 GMT
https://trac.sagemath.org/ticket/11339#comment:55
https://trac.sagemath.org/ticket/11339#comment:55
<p>
trac_11339_refcount_singular_polynomials.patch doesn't apply on top of 4.7.2.alpha2, I believe the conflict is with <a class="closed ticket" href="https://trac.sagemath.org/ticket/7654" title="defect: Conversion bug in MPolynomialRing_libsingular (closed: fixed)">#7654</a> but I could be wrong.
</p>
TicketleifMon, 29 Aug 2011 07:11:23 GMTstatus changed; work_issues set
https://trac.sagemath.org/ticket/11339#comment:56
https://trac.sagemath.org/ticket/11339#comment:56
<ul>
<li><strong>status</strong>
changed from <em>needs_info</em> to <em>needs_review</em>
</li>
<li><strong>work_issues</strong>
set to <em>Rebase on Sage 4.7.2.alpha2.</em>
</li>
</ul>
<pre class="wiki">leif@californication:~/Sage/sage-4.7.2.alpha2-gcc-4.5.1/devel/sage-9958-11339$ ../../sage -hg import -v ~/Sage/patches/trac_11339_refcount_singular_polynomials.patch
applying /home/leif/Sage/patches/trac_11339_refcount_singular_polynomials.patch
patching file sage/rings/polynomial/multi_polynomial_libsingular.pxd
patching file sage/rings/polynomial/multi_polynomial_libsingular.pyx
Hunk #13 FAILED at 727
Hunk #14 FAILED at 741
Hunk #15 FAILED at 763
Hunk #16 FAILED at 773
Hunk #17 FAILED at 825
Hunk #18 succeeded at 910 with fuzz 2 (offset 72 lines).
Hunk #19 FAILED at 875
Hunk #20 succeeded at 961 (offset 75 lines).
Hunk #21 succeeded at 980 (offset 75 lines).
Hunk #22 succeeded at 1006 (offset 75 lines).
...
</pre><p>
(The first patch still applies, with offsets.)
</p>
<p>
I'm not going to fix that...
</p>
TicketleifMon, 29 Aug 2011 07:12:34 GMTstatus changed
https://trac.sagemath.org/ticket/11339#comment:57
https://trac.sagemath.org/ticket/11339#comment:57
<ul>
<li><strong>status</strong>
changed from <em>needs_review</em> to <em>needs_work</em>
</li>
</ul>
<p>
Trac, why can't I switch from "needs info" to "needs work"?!?
</p>
TicketleifMon, 29 Aug 2011 07:33:47 GMT
https://trac.sagemath.org/ticket/11339#comment:58
https://trac.sagemath.org/ticket/11339#comment:58
<p>
Replying to <a class="ticket" href="https://trac.sagemath.org/ticket/11339#comment:56" title="Comment 56">leif</a>:
</p>
<blockquote class="citation">
</blockquote>
<pre class="wiki">leif@californication:~/Sage/sage-4.7.2.alpha2-gcc-4.5.1/devel/sage-9958-11339$ ../../sage -hg import -v ~/Sage/patches/trac_11339_refcount_singular_polynomials.patch
applying /home/leif/Sage/patches/trac_11339_refcount_singular_polynomials.patch
patching file sage/rings/polynomial/multi_polynomial_libsingular.pxd
patching file sage/rings/polynomial/multi_polynomial_libsingular.pyx
Hunk #13 FAILED at 727
Hunk #14 FAILED at 741
Hunk #15 FAILED at 763
Hunk #16 FAILED at 773
Hunk #17 FAILED at 825
Hunk #18 succeeded at 910 with fuzz 2 (offset 72 lines).
Hunk #19 FAILED at 875
...
</pre><p>
That's due to <a class="closed ticket" href="https://trac.sagemath.org/ticket/7654" title="defect: Conversion bug in MPolynomialRing_libsingular (closed: fixed)">#7654</a>. I just wonder why, according to trac, Martin attached (or updated) the patch 11 days ago, but:
</p>
<pre class="wiki">leif@californication:~/Sage/sage-4.7.2.alpha2-gcc-4.5.1/devel/sage-9958-11339$ ../../sage -hg log sage/rings/polynomial/multi_polynomial_libsingular.pyx
changeset: 16029:f8df02b7396c
user: Martin Albrecht <martinralbrecht@googlemail.com>
date: Sat Jun 25 15:51:22 2011 +0100
summary: Trac #7654: #7654 fix MPolynomial_libsingular.__call__ to accept more inputs
and fail gracefully
</pre>
TicketleifMon, 29 Aug 2011 07:53:19 GMT
https://trac.sagemath.org/ticket/11339#comment:59
https://trac.sagemath.org/ticket/11339#comment:59
<p>
I've verified that (except for the meta data, including the dates, and one line number) the patch attached to <a class="closed ticket" href="https://trac.sagemath.org/ticket/7654" title="defect: Conversion bug in MPolynomialRing_libsingular (closed: fixed)">#7654</a> and the one Jeroen merged into Sage 4.7.2.alpha2 are the same. Still weird...
</p>
TicketfbisseyMon, 29 Aug 2011 12:39:21 GMT
https://trac.sagemath.org/ticket/11339#comment:60
https://trac.sagemath.org/ticket/11339#comment:60
<p>
Replying to <a class="ticket" href="https://trac.sagemath.org/ticket/11339#comment:59" title="Comment 59">leif</a>:
</p>
<blockquote class="citation">
<p>
I've verified that (except for the meta data, including the dates, and one line number) the patch attached to <a class="closed ticket" href="https://trac.sagemath.org/ticket/7654" title="defect: Conversion bug in MPolynomialRing_libsingular (closed: fixed)">#7654</a> and the one Jeroen merged into Sage 4.7.2.alpha2 are the same. Still weird...
</p>
</blockquote>
<p>
The line number is weird, otherwise doesn't Jeroen merge script add stuff to make sure there is proper metadata in the patch?
</p>
<p>
Note also that we are playing a "wack a mole" game here. You fix things in one place and suddenly you get a new failure in another. So refreshing Volker's patch is just the beginning....
</p>
TicketvbraunMon, 26 Sep 2011 19:21:32 GMTattachment set
https://trac.sagemath.org/ticket/11339
https://trac.sagemath.org/ticket/11339
<ul>
<li><strong>attachment</strong>
set to <em>trac_11339_refcount_singular_rings.patch</em>
</li>
</ul>
<p>
Updated patch
</p>
TicketvbraunMon, 26 Sep 2011 19:21:43 GMTattachment set
https://trac.sagemath.org/ticket/11339
https://trac.sagemath.org/ticket/11339
<ul>
<li><strong>attachment</strong>
set to <em>trac_11339_refcount_singular_polynomials.patch</em>
</li>
</ul>
<p>
Updated patch
</p>
TicketvbraunMon, 26 Sep 2011 19:22:48 GMT
https://trac.sagemath.org/ticket/11339#comment:61
https://trac.sagemath.org/ticket/11339#comment:61
<p>
I've rebased the patches on top of sage-4.7.2.alpha2. There are still a few segfaults from deleting rings, but at least we can reproduce them with the patches ;-)
</p>
TicketleifTue, 27 Sep 2011 15:01:58 GMTpriority changed
https://trac.sagemath.org/ticket/11339#comment:62
https://trac.sagemath.org/ticket/11339#comment:62
<ul>
<li><strong>priority</strong>
changed from <em>major</em> to <em>critical</em>
</li>
</ul>
<p>
Something for SD34? :P
</p>
TicketstrogdonTue, 27 Sep 2011 19:20:17 GMT
https://trac.sagemath.org/ticket/11339#comment:63
https://trac.sagemath.org/ticket/11339#comment:63
<p>
Aside from the segfaults, with the new patches I get the following additional failurers. The failures "seem" to be associated with the patches in that I don't get them when I use Martin's patches.
</p>
<p>
amd64:
</p>
<pre class="wiki">sage -t -long -force_lib devel/sage-trans_16037.16051/sage/misc/sageinspect.py
sage -t -long -force_lib devel/sage-trans_16037.16051/sage/schemes/plane_conics/con_field.py
sage -t -long -force_lib devel/sage-trans_16037.16051/sage/schemes/hyperelliptic_curves/hyperelliptic_finite_field.py
</pre><p>
x86:
</p>
<pre class="wiki">sage -t -long -force_lib devel/sage-trans_16037.16051/sage/misc/sageinspect.py
sage -t -long -force_lib devel/sage-trans_16037.16051/sage/schemes/plane_conics/con_field.py
</pre><p>
Here is a brief summary of the failures.
</p>
<p>
sageinspect.py (partial output given):
</p>
<pre class="wiki">Expected:
(['cdef class MPolynomialRing_libsingular(MPolynomialRing_generic):\n',
" def __init__(self, base_ring, n, names, order='degrevlex'):\n",
...
' M.append(new_MP(self, p_Copy(tempvector,_ring)))\n',
' return M\n'], ...)
Got:
(['cdef class MPolynomialRing_libsingular(MPolynomialRing_generic):\n', '\n', ' def
__cinit__(self):\n', '
</pre><p>
con_field.py:
</p>
<pre class="wiki">File "/storage/sage/sage-4.7.2.alpha2/devel/sage-trans_16037.16051/sage/schemes/plane_conics/con_field.py", line 234:
sage: C.is_smooth()
Expected:
True
Got:
False
</pre><p>
hyperelliptic_curves/hyperelliptic_finite_field.py:
</p>
<pre class="wiki">File "/storage/sage/sage-4.7.2.alpha2/devel/sage-trans_16037.16051/sage/schemes/hyperelliptic_curves/hyperelliptic_finite_field.py", line 269:
sage: set(C._points_cache_sqrt()) == set(C._points_cache_sqrt(brute_force=True))
Exception raised:
Traceback (most recent call last):
File "/storage/sage/sage-4.7.2.alpha2/local/bin/ncadoctest.py", line 1231, in run_one_test
self.run_one_example(test, example, filename, compileflags)
File "/storage/sage/sage-4.7.2.alpha2/local/bin/sagedoctest.py", line 38, in run_one_example
OrigDocTestRunner.run_one_example(self, test, example, filename, compileflags)
File "/storage/sage/sage-4.7.2.alpha2/local/bin/ncadoctest.py", line 1172, in run_one_example
compileflags, 1) in test.globs
File "<doctest __main__.example_5[5]>", line 1, in <module>
set(C._points_cache_sqrt()) == set(C._points_cache_sqrt(brute_force=True))###line 269:
sage: set(C._points_cache_sqrt()) == set(C._points_cache_sqrt(brute_force=True))
File "/storage/sage/sage-4.7.2.alpha2/local/lib/python/site-packages/sage/schemes/hyperelliptic_curves/hyperelliptic_finite_field.py", line 296, in _points_cache_sqrt
points.append(self.point([x, -y, one], check=True))
File "/storage/sage/sage-4.7.2.alpha2/local/lib/python/site-packages/sage/schemes/generic/scheme.py", line 256, in point
return self._point_class(self, v, check=check)
File "/storage/sage/sage-4.7.2.alpha2/local/lib/python/site-packages/sage/schemes/generic/algebraic_scheme.py", line 528, in _point_class
return self.__A._point_class(*args, **kwds)
File "/storage/sage/sage-4.7.2.alpha2/local/lib/python/site-packages/sage/schemes/generic/projective_space.py", line 561, in _point_class
return morphism.SchemeMorphism_projective_coordinates_field(*args, **kwds)
File "/storage/sage/sage-4.7.2.alpha2/local/lib/python/site-packages/sage/schemes/generic/morphism.py", line 676, in __init__
X.codomain()._check_satisfies_equations(v)
File "/storage/sage/sage-4.7.2.alpha2/local/lib/python/site-packages/sage/schemes/generic/algebraic_scheme.py", line 902, in _check_satisfies_equations
raise TypeError, "Coordinates %s do not define a point on %s"%(coords,self)
TypeError: Coordinates [2, 2, 1] do not define a point on Hyperelliptic Curve over Finite Field of size 7 defined by y^2 = x^3 + x^2 + 6
</pre>
TicketfbisseyTue, 27 Sep 2011 21:33:15 GMT
https://trac.sagemath.org/ticket/11339#comment:64
https://trac.sagemath.org/ticket/11339#comment:64
<p>
I have seen the error on sageinspect.py before. Did you send it to me privately? I cannot seem to find where it was mentioned in inbox or my logs. You get cython code as output while the test is expecting c++ code to be returned.
</p>
TicketfbisseyTue, 27 Sep 2011 22:44:13 GMT
https://trac.sagemath.org/ticket/11339#comment:65
https://trac.sagemath.org/ticket/11339#comment:65
<p>
Still about sageinspect.py, this is stuff added in <a class="closed ticket" href="https://trac.sagemath.org/ticket/11298" title="defect: Extend the capabilities of Sage's introspection (closed: fixed)">#11298</a>, did you apply <a class="closed ticket" href="https://trac.sagemath.org/ticket/11734" title="defect: sage_wraps should only read the sources of wrapped functions when needed. (closed: fixed)">#11734</a> to your branch?
</p>
<p>
My own list of stuff that seem singular related is:
</p>
<pre class="wiki"> sage -t -long -force_lib devel/sage-main/sage/crypto/mq/sr.py # Killed/crashed
sage -t -long -force_lib devel/sage-main/sage/schemes/elliptic_curves/ell_curve_isogeny.py # Killed/crashed
sage -t -long -force_lib devel/sage-main/sage/schemes/elliptic_curves/ell_generic.py # Killed/crashed
sage -t -long -force_lib devel/sage-main/sage/rings/polynomial/multi_polynomial_ideal.py # Killed/crashed
sage -t -long -force_lib devel/sage-main/sage/schemes/generic/algebraic_scheme.py # Killed/crashed
sage -t -long -force_lib devel/sage-main/sage/schemes/plane_conics/con_field.py # 1 doctests failed
</pre>
TicketfbisseyTue, 27 Sep 2011 22:44:47 GMT
https://trac.sagemath.org/ticket/11339#comment:66
https://trac.sagemath.org/ticket/11339#comment:66
<p>
Forgot
</p>
<pre class="wiki"> sage -t -long -force_lib devel/sage-main/sage/schemes/plane_conics/con_finite_field.py # Killed/crashed
</pre>
TicketstrogdonTue, 27 Sep 2011 23:40:19 GMT
https://trac.sagemath.org/ticket/11339#comment:67
https://trac.sagemath.org/ticket/11339#comment:67
<p>
Replying to <a class="ticket" href="https://trac.sagemath.org/ticket/11339#comment:65" title="Comment 65">fbissey</a>:
</p>
<blockquote class="citation">
<p>
Still about sageinspect.py, this is stuff added in <a class="closed ticket" href="https://trac.sagemath.org/ticket/11298" title="defect: Extend the capabilities of Sage's introspection (closed: fixed)">#11298</a>, did you apply <a class="closed ticket" href="https://trac.sagemath.org/ticket/11734" title="defect: sage_wraps should only read the sources of wrapped functions when needed. (closed: fixed)">#11734</a> to your branch? My own list of stuff that seem singular related is:
</p>
</blockquote>
<p>
No I hadn't applied that patch to my branch. However, after doing so sageinspect.py fails the same way on both x86 and amd64. Now here on sage-on-gentoo, where <a class="closed ticket" href="https://trac.sagemath.org/ticket/11734" title="defect: sage_wraps should only read the sources of wrapped functions when needed. (closed: fixed)">#11734</a> has been applied, sageinspect.py fails on amd64 but passed on x86 with the new refcount patches. This probably doesn't belong with this ticket even though there appears to be some connection.
</p>
TicketstrogdonWed, 28 Sep 2011 00:22:53 GMT
https://trac.sagemath.org/ticket/11339#comment:68
https://trac.sagemath.org/ticket/11339#comment:68
<p>
Replying to <a class="ticket" href="https://trac.sagemath.org/ticket/11339#comment:67" title="Comment 67">strogdon</a>:
</p>
<blockquote class="citation">
<p>
Replying to <a class="ticket" href="https://trac.sagemath.org/ticket/11339#comment:65" title="Comment 65">fbissey</a>:
</p>
<blockquote class="citation">
<p>
Still about sageinspect.py, this is stuff added in <a class="closed ticket" href="https://trac.sagemath.org/ticket/11298" title="defect: Extend the capabilities of Sage's introspection (closed: fixed)">#11298</a>, did you apply <a class="closed ticket" href="https://trac.sagemath.org/ticket/11734" title="defect: sage_wraps should only read the sources of wrapped functions when needed. (closed: fixed)">#11734</a> to your branch? My own list of stuff that seem singular related is:
</p>
</blockquote>
<p>
No I hadn't applied that patch to my branch. However, after doing so sageinspect.py fails the same way on both x86 and amd64. Now here on sage-on-gentoo, where <a class="closed ticket" href="https://trac.sagemath.org/ticket/11734" title="defect: sage_wraps should only read the sources of wrapped functions when needed. (closed: fixed)">#11734</a> has been applied, sageinspect.py fails on amd64 but passed on x86 with the new refcount patches. This probably doesn't belong with this ticket even though there appears to be some connection.
</p>
</blockquote>
<p>
I was mistaken, sageinspect.py also fails here on x86 [sage-on-gentoo] with the new refcount patches and the patch from <a class="closed ticket" href="https://trac.sagemath.org/ticket/11734" title="defect: sage_wraps should only read the sources of wrapped functions when needed. (closed: fixed)">#11734</a>.
</p>
TicketfbisseyWed, 28 Sep 2011 00:34:06 GMT
https://trac.sagemath.org/ticket/11339#comment:69
https://trac.sagemath.org/ticket/11339#comment:69
<p>
I pushed Volker's latest patches for 4.7.2.alpha2 only 2 hours ago, before that I had reverted to Martin's initial patch. So mistake was easy.
</p>
TicketmalbThu, 29 Sep 2011 14:36:56 GMT
https://trac.sagemath.org/ticket/11339#comment:70
https://trac.sagemath.org/ticket/11339#comment:70
<p>
I fixed (most?) of the issues discussed here over at <a class="closed ticket" href="https://trac.sagemath.org/ticket/10903" title="defect: Update Singular to 3-1-3-3 (closed: fixed)">#10903</a>. Unfortunately, I mixed my fixes up with the general update to Singular 3-1-4 (not yet released). In any case, the two tickets are effectively merged. My bad!
</p>
TicketmalbThu, 29 Sep 2011 15:11:29 GMT
https://trac.sagemath.org/ticket/11339#comment:71
https://trac.sagemath.org/ticket/11339#comment:71
<p>
Patches look good though, so I'll give this a positive review once we fixed all the bugs uncovered by them in <a class="closed ticket" href="https://trac.sagemath.org/ticket/10902" title="defect: proof=False unnecessary in factor() (closed: fixed)">#10902</a>.
</p>
TicketmalbThu, 29 Sep 2011 15:11:51 GMT
https://trac.sagemath.org/ticket/11339#comment:72
https://trac.sagemath.org/ticket/11339#comment:72
<p>
Replying to <a class="ticket" href="https://trac.sagemath.org/ticket/11339#comment:71" title="Comment 71">malb</a>:
</p>
<blockquote class="citation">
<p>
Patches look good though, so I'll give this a positive review once we fixed all the bugs uncovered by them in <a class="closed ticket" href="https://trac.sagemath.org/ticket/10902" title="defect: proof=False unnecessary in factor() (closed: fixed)">#10902</a>.
</p>
</blockquote>
<p>
<a class="closed ticket" href="https://trac.sagemath.org/ticket/10903" title="defect: Update Singular to 3-1-3-3 (closed: fixed)">#10903</a>!
</p>
TicketstrogdonThu, 29 Sep 2011 20:28:00 GMT
https://trac.sagemath.org/ticket/11339#comment:73
https://trac.sagemath.org/ticket/11339#comment:73
<p>
Replying to <a class="ticket" href="https://trac.sagemath.org/ticket/11339#comment:72" title="Comment 72">malb</a>:
</p>
<blockquote class="citation">
<p>
Replying to <a class="ticket" href="https://trac.sagemath.org/ticket/11339#comment:71" title="Comment 71">malb</a>:
</p>
<blockquote class="citation">
<p>
Patches look good though, so I'll give this a positive review once we fixed all the bugs uncovered by them in <a class="closed ticket" href="https://trac.sagemath.org/ticket/10902" title="defect: proof=False unnecessary in factor() (closed: fixed)">#10902</a>.
</p>
</blockquote>
<p>
<a class="closed ticket" href="https://trac.sagemath.org/ticket/10903" title="defect: Update Singular to 3-1-3-3 (closed: fixed)">#10903</a>!
</p>
</blockquote>
<p>
With the singular SPKG and the patches (both of them) from <a class="closed ticket" href="https://trac.sagemath.org/ticket/10903" title="defect: Update Singular to 3-1-3-3 (closed: fixed)">#10903</a> I get no segfaults for the long tests on both x86 and amd64. However, there is one test on x86 that usually takes a very long time that now fails. It may be singular-related.
</p>
<pre class="wiki">sage -t -long -force_lib devel/sage-singular.16054/sage/schemes/elliptic_curves/ell_rational_field.py
*** Warning: new stack size = 1003360 (0.957 Mbytes).
*** Warning: new stack size = 1003360 (0.957 Mbytes).
Saturation index bound = 265
WARNING: saturation at primes p > 97 will not be done;
points may be unsaturated at primes between 97 and index bound
Failed to saturate MW basis at primes [ ]
Saturation index bound = 265
WARNING: saturation at primes p > 199 will not be done;
points may be unsaturated at primes between 199 and index bound
Failed to saturate MW basis at primes [ ]
Saturation index bound = 265
WARNING: saturation at primes p > 97 will not be done;
points may be unsaturated at primes between 97 and index bound
Failed to saturate MW basis at primes [ ]
Saturation index bound = 265
WARNING: saturation at primes p > 199 will not be done;
points may be unsaturated at primes between 199 and index bound
Failed to saturate MW basis at primes [ ]
After 10 attempts at enlargement, giving up!
--points not proved 2-saturated,
2-saturation failed!
Failed to saturate MW basis at primes [ 2 ]
2 After 10 attempts at enlargement, giving up!
--points not proved 2-saturated,
2-saturation failed!
Failed to saturate MW basis at primes [ 2 ]
2 **********************************************************************
File "/storage/sage/sage-4.7.2.alpha2/devel/sage-singular.16054/sage/schemes/elliptic_curves/ell_rational_field.py", line 3884:
sage: E1.isogeny_class(algorithm="sage")
Exception raised:
Traceback (most recent call last):
File "/storage/sage/sage-4.7.2.alpha2/local/bin/ncadoctest.py", line 1231, in run_one_test
self.run_one_example(test, example, filename, compileflags)
File "/storage/sage/sage-4.7.2.alpha2/local/bin/sagedoctest.py", line 38, in run_one_example
OrigDocTestRunner.run_one_example(self, test, example, filename, compileflags)
File "/storage/sage/sage-4.7.2.alpha2/local/bin/ncadoctest.py", line 1172, in run_one_example
compileflags, 1) in test.globs
File "<doctest __main__.example_80[16]>", line 1, in <module>
E1.isogeny_class(algorithm="sage")###line 3884:
sage: E1.isogeny_class(algorithm="sage")
File "/storage/sage/sage-4.7.2.alpha2/local/lib/python/site-packages/sage/schemes/elliptic_curves/ell_rational_field.py", line 3954, in isogeny_class
isogs = E.isogenies_prime_degree(l_list)
File "/storage/sage/sage-4.7.2.alpha2/local/lib/python/site-packages/sage/schemes/elliptic_curves/ell_rational_field.py", line 4054, in isogenies_prime_degree
return isogenies_sporadic_Q(self)
File "/storage/sage/sage-4.7.2.alpha2/local/lib/python/site-packages/sage/schemes/elliptic_curves/ell_curve_isogeny.py", line 4179, in isogenies_sporadic_Q
return isogenies_sporadic_Q(E, Integer(163))
File "/storage/sage/sage-4.7.2.alpha2/local/lib/python/site-packages/sage/schemes/elliptic_curves/ell_curve_isogeny.py", line 4162, in isogenies_sporadic_Q
isog = Ew.isogeny(kernel=ker, degree=l, model="minimal", check=False)
File "/storage/sage/sage-4.7.2.alpha2/local/lib/python/site-packages/sage/schemes/elliptic_curves/ell_field.py", line 806, in isogeny
return EllipticCurveIsogeny(self, kernel, codomain, degree, model, check=check)
File "/storage/sage/sage-4.7.2.alpha2/local/lib/python/site-packages/sage/schemes/elliptic_curves/ell_curve_isogeny.py", line 914, in __init__
self.__init_from_kernel_polynomial(kernel, degree)
File "/storage/sage/sage-4.7.2.alpha2/local/lib/python/site-packages/sage/schemes/elliptic_curves/ell_curve_isogeny.py", line 2069, in __init_from_kernel_polynomial
(phi, omega, v, w, n, d) = self.__init_odd_kernel_polynomial(E, psi)
File "/storage/sage/sage-4.7.2.alpha2/local/lib/python/site-packages/sage/schemes/elliptic_curves/ell_curve_isogeny.py", line 2257, in __init_odd_kernel_polynomial
psi_coeffs = psi.univariate_polynomial().list()
File "multi_polynomial_libsingular.pyx", line 3369, in sage.rings.polynomial.multi_polynomial_libsingular.MPolynomial_libsingular.univariate_polynomial (sage/rings/polynomial/multi_polynomial_libsingular.cpp:22055)
IndexError: list assignment index out of range
</pre>
TicketmalbThu, 29 Sep 2011 21:09:43 GMT
https://trac.sagemath.org/ticket/11339#comment:74
https://trac.sagemath.org/ticket/11339#comment:74
<p>
It looks singular related but it doesn't immediately ring a bell. I'd guess some strategically placed <code>rChangeCurrRing</code> would fix the issue, but the problem is to find where to put it.
</p>
TicketvbraunSat, 01 Oct 2011 21:34:09 GMTstatus, description, summary changed
https://trac.sagemath.org/ticket/11339#comment:75
https://trac.sagemath.org/ticket/11339#comment:75
<ul>
<li><strong>status</strong>
changed from <em>needs_work</em> to <em>needs_review</em>
</li>
<li><strong>description</strong>
modified (<a href="/ticket/11339?action=diff&version=75">diff</a>)
</li>
<li><strong>summary</strong>
changed from <em>Illegal use of __deallocate__ in cython (pyx) code</em> to <em>Refcounting for Cython rings</em>
</li>
</ul>
<p>
I am setting this bug to Needs Review. The two patches here will correctly refcount the Singular rings, and the reviewer should focus on that aspect. They also make Sage crash because of issues in the libSingular interface. The latter will be dealt with in <a class="closed ticket" href="https://trac.sagemath.org/ticket/10903" title="defect: Update Singular to 3-1-3-3 (closed: fixed)">#10903</a>. Please report any crashes in Sage on <a class="closed ticket" href="https://trac.sagemath.org/ticket/10903" title="defect: Update Singular to 3-1-3-3 (closed: fixed)">#10903</a>, and not here.
</p>
TicketvbraunSat, 01 Oct 2011 21:34:55 GMTsummary changed
https://trac.sagemath.org/ticket/11339#comment:76
https://trac.sagemath.org/ticket/11339#comment:76
<ul>
<li><strong>summary</strong>
changed from <em>Refcounting for Cython rings</em> to <em>Refcounting for Singular rings</em>
</li>
</ul>
TicketmalbMon, 03 Oct 2011 14:49:48 GMTstatus, reviewer changed
https://trac.sagemath.org/ticket/11339#comment:77
https://trac.sagemath.org/ticket/11339#comment:77
<ul>
<li><strong>status</strong>
changed from <em>needs_review</em> to <em>positive_review</em>
</li>
<li><strong>reviewer</strong>
changed from <em>François Bissey, Steven Trogdon</em> to <em>François Bissey, Steven Trogdon, Martin Albrecht</em>
</li>
</ul>
<p>
I read the patch and we're reasonably certain we caught all bugs these patches uncovered (not introduced!), so: positive review.
</p>
TicketjdemeyerTue, 04 Oct 2011 08:50:54 GMTstatus, work_issues changed
https://trac.sagemath.org/ticket/11339#comment:78
https://trac.sagemath.org/ticket/11339#comment:78
<ul>
<li><strong>status</strong>
changed from <em>positive_review</em> to <em>needs_work</em>
</li>
<li><strong>work_issues</strong>
changed from <em>Rebase on Sage 4.7.2.alpha2.</em> to <em>Conflict with #11856</em>
</li>
</ul>
<p>
This seems to conflict with <a class="closed ticket" href="https://trac.sagemath.org/ticket/11856" title="defect: Raise an overflow error if the exponent of a multivariate polynomial ... (closed: fixed)">#11856</a>.
</p>
TicketSimonKingTue, 04 Oct 2011 08:59:21 GMTstatus changed
https://trac.sagemath.org/ticket/11339#comment:79
https://trac.sagemath.org/ticket/11339#comment:79
<ul>
<li><strong>status</strong>
changed from <em>needs_work</em> to <em>positive_review</em>
</li>
</ul>
<p>
It seems that it will be easier to rebase my patch from <a class="new ticket" href="https://trac.sagemath.org/ticket/11892" title="defect: Extend singular_function to non-commutative polynomial rings by ... (new)">#11892</a>. So, I reinstate the positive review and will change <a class="new ticket" href="https://trac.sagemath.org/ticket/11892" title="defect: Extend singular_function to non-commutative polynomial rings by ... (new)">#11892</a>.
</p>
TicketSimonKingTue, 04 Oct 2011 08:59:55 GMT
https://trac.sagemath.org/ticket/11339#comment:80
https://trac.sagemath.org/ticket/11339#comment:80
<p>
Replying to <a class="ticket" href="https://trac.sagemath.org/ticket/11339#comment:79" title="Comment 79">SimonKing</a>:
</p>
<blockquote class="citation">
<p>
It seems that it will be easier to rebase my patch from <a class="new ticket" href="https://trac.sagemath.org/ticket/11892" title="defect: Extend singular_function to non-commutative polynomial rings by ... (new)">#11892</a>. So, I reinstate the positive review and will change <a class="new ticket" href="https://trac.sagemath.org/ticket/11892" title="defect: Extend singular_function to non-commutative polynomial rings by ... (new)">#11892</a>.
</p>
</blockquote>
<p>
Sorry, I meant to change <a class="closed ticket" href="https://trac.sagemath.org/ticket/11856" title="defect: Raise an overflow error if the exponent of a multivariate polynomial ... (closed: fixed)">#11856</a>...
</p>
TicketjdemeyerTue, 04 Oct 2011 09:12:58 GMTwork_issues deleted
https://trac.sagemath.org/ticket/11339#comment:81
https://trac.sagemath.org/ticket/11339#comment:81
<ul>
<li><strong>work_issues</strong>
<em>Conflict with #11856</em> deleted
</li>
</ul>
TicketSimonKingTue, 04 Oct 2011 09:24:15 GMT
https://trac.sagemath.org/ticket/11339#comment:82
https://trac.sagemath.org/ticket/11339#comment:82
<p>
For the record: The conflicts with <a class="closed ticket" href="https://trac.sagemath.org/ticket/11856" title="defect: Raise an overflow error if the exponent of a multivariate polynomial ... (closed: fixed)">#11856</a> and also another conflict with <a class="closed ticket" href="https://trac.sagemath.org/ticket/11068" title="enhancement: Basic implementation of one- and twosided ideals of non-commutative ... (closed: fixed)">#11068</a> were caused by cosmetic changes introduced by the first patch. Both are resolved now.
</p>
TicketSimonKingTue, 04 Oct 2011 11:32:14 GMT
https://trac.sagemath.org/ticket/11339#comment:83
https://trac.sagemath.org/ticket/11339#comment:83
<p>
It is amazing how many patches of mine fail for trivial reasons because of this ticket. E.g., introspection: One of my examples for introspection of code fails, because <code>__cinint__</code> was introduced. So, in addition to <a class="closed ticket" href="https://trac.sagemath.org/ticket/11856" title="defect: Raise an overflow error if the exponent of a multivariate polynomial ... (closed: fixed)">#11856</a> and <a class="closed ticket" href="https://trac.sagemath.org/ticket/11068" title="enhancement: Basic implementation of one- and twosided ideals of non-commutative ... (closed: fixed)">#11068</a>, I'll have to change at least a third patch as well.
</p>
TicketSimonKingTue, 04 Oct 2011 11:47:57 GMTstatus changed
https://trac.sagemath.org/ticket/11339#comment:84
https://trac.sagemath.org/ticket/11339#comment:84
<ul>
<li><strong>status</strong>
changed from <em>positive_review</em> to <em>needs_work</em>
</li>
</ul>
<p>
You should run the tests with your patches applied on top of sage-4.7.2.alpha3. At least with the alpha3-prerelease, I get some doctest errors, for example <code>sage -t "devel/sage-main/sage/misc/sageinspect.py"</code>.
</p>
<p>
So, it seems it would have been better to change this patch, not <a class="closed ticket" href="https://trac.sagemath.org/ticket/11856" title="defect: Raise an overflow error if the exponent of a multivariate polynomial ... (closed: fixed)">#11856</a> and <a class="closed ticket" href="https://trac.sagemath.org/ticket/11068" title="enhancement: Basic implementation of one- and twosided ideals of non-commutative ... (closed: fixed)">#11068</a>. Too bad.
</p>
TicketvbraunTue, 04 Oct 2011 12:35:24 GMTstatus changed
https://trac.sagemath.org/ticket/11339#comment:85
https://trac.sagemath.org/ticket/11339#comment:85
<ul>
<li><strong>status</strong>
changed from <em>needs_work</em> to <em>needs_review</em>
</li>
</ul>
<p>
The doctest failure in sage/misc/sageinspect (would have been nice if it would have used its own module as a doctest example btw) is fixed in <a class="closed ticket" href="https://trac.sagemath.org/ticket/10903" title="defect: Update Singular to 3-1-3-3 (closed: fixed)">#10903</a>. There are no doctest failures if you use sage-4.7.2.alpha3 + <a class="closed ticket" href="https://trac.sagemath.org/ticket/11339" title="defect: Refcounting for Singular rings (closed: fixed)">#11339</a> + <a class="closed ticket" href="https://trac.sagemath.org/ticket/10903" title="defect: Update Singular to 3-1-3-3 (closed: fixed)">#10903</a>. Really the two tickets should be one but thats not how it panned out historically.
</p>
TicketleifTue, 04 Oct 2011 12:40:49 GMT
https://trac.sagemath.org/ticket/11339#comment:86
https://trac.sagemath.org/ticket/11339#comment:86
<p>
Replying to <a class="ticket" href="https://trac.sagemath.org/ticket/11339#comment:85" title="Comment 85">vbraun</a>:
</p>
<blockquote class="citation">
<p>
The doctest failure in sage/misc/sageinspect (would have been nice if it would have used its own module as a doctest example btw) is fixed in <a class="closed ticket" href="https://trac.sagemath.org/ticket/10903" title="defect: Update Singular to 3-1-3-3 (closed: fixed)">#10903</a>. There are no doctest failures if you use sage-4.7.2.alpha3 + <a class="closed ticket" href="https://trac.sagemath.org/ticket/11339" title="defect: Refcounting for Singular rings (closed: fixed)">#11339</a> + <a class="closed ticket" href="https://trac.sagemath.org/ticket/10903" title="defect: Update Singular to 3-1-3-3 (closed: fixed)">#10903</a>. Really the two tickets should be one but thats not how it panned out historically.
</p>
</blockquote>
<p>
So we have a cyclic dependency now...
</p>
<p>
Somehow matches the ticket's title.
</p>
TicketSimonKingTue, 04 Oct 2011 12:45:06 GMT
https://trac.sagemath.org/ticket/11339#comment:87
https://trac.sagemath.org/ticket/11339#comment:87
<p>
Question to the release manager: How are the odds that both <a class="closed ticket" href="https://trac.sagemath.org/ticket/11339" title="defect: Refcounting for Singular rings (closed: fixed)">#11339</a>/<a class="closed ticket" href="https://trac.sagemath.org/ticket/10903" title="defect: Update Singular to 3-1-3-3 (closed: fixed)">#10903</a> and <a class="closed ticket" href="https://trac.sagemath.org/ticket/11856" title="defect: Raise an overflow error if the exponent of a multivariate polynomial ... (closed: fixed)">#11856</a> (which both fix critical bugs) will be merged into sage-4.7.2?
</p>
<p>
If <a class="closed ticket" href="https://trac.sagemath.org/ticket/11339" title="defect: Refcounting for Singular rings (closed: fixed)">#11339</a>/<a class="closed ticket" href="https://trac.sagemath.org/ticket/10903" title="defect: Update Singular to 3-1-3-3 (closed: fixed)">#10903</a> are ready to be merged then I guess one can easily modify <a class="closed ticket" href="https://trac.sagemath.org/ticket/11856" title="defect: Raise an overflow error if the exponent of a multivariate polynomial ... (closed: fixed)">#11856</a> so that it matches (it is just a different line break in one hunk). And <a class="closed ticket" href="https://trac.sagemath.org/ticket/11068" title="enhancement: Basic implementation of one- and twosided ideals of non-commutative ... (closed: fixed)">#11068</a> was shifted to sage-4.7.3 anyway, so, it can wait.
</p>
TicketSimonKingTue, 04 Oct 2011 12:47:20 GMT
https://trac.sagemath.org/ticket/11339#comment:88
https://trac.sagemath.org/ticket/11339#comment:88
<p>
Replying to <a class="ticket" href="https://trac.sagemath.org/ticket/11339#comment:85" title="Comment 85">vbraun</a>:
</p>
<blockquote class="citation">
<p>
The doctest failure in sage/misc/sageinspect (would have been nice if it would have used its own module as a doctest example btw) ...
</p>
</blockquote>
<p>
The point was to have a cdef class, but sageinspect is pure Python, so it wouldn't have been a good example.
</p>
TicketvbraunTue, 04 Oct 2011 12:55:36 GMT
https://trac.sagemath.org/ticket/11339#comment:89
https://trac.sagemath.org/ticket/11339#comment:89
<p>
Jeroen said that Singular will go into sage-4.7.2 on sage-release. This should be <a class="closed ticket" href="https://trac.sagemath.org/ticket/11339" title="defect: Refcounting for Singular rings (closed: fixed)">#11339</a> + <a class="closed ticket" href="https://trac.sagemath.org/ticket/10903" title="defect: Update Singular to 3-1-3-3 (closed: fixed)">#10903</a> + <a class="closed ticket" href="https://trac.sagemath.org/ticket/11856" title="defect: Raise an overflow error if the exponent of a multivariate polynomial ... (closed: fixed)">#11856</a>, preferably in that order.
</p>
TicketjdemeyerTue, 04 Oct 2011 12:57:45 GMT
https://trac.sagemath.org/ticket/11339#comment:90
https://trac.sagemath.org/ticket/11339#comment:90
<p>
Replying to <a class="ticket" href="https://trac.sagemath.org/ticket/11339#comment:89" title="Comment 89">vbraun</a>:
</p>
<blockquote class="citation">
<p>
Jeroen said that Singular will go into sage-4.7.2 on sage-release. This should be <a class="closed ticket" href="https://trac.sagemath.org/ticket/11339" title="defect: Refcounting for Singular rings (closed: fixed)">#11339</a> + <a class="closed ticket" href="https://trac.sagemath.org/ticket/10903" title="defect: Update Singular to 3-1-3-3 (closed: fixed)">#10903</a> + <a class="closed ticket" href="https://trac.sagemath.org/ticket/11856" title="defect: Raise an overflow error if the exponent of a multivariate polynomial ... (closed: fixed)">#11856</a>, preferably in that order.
</p>
</blockquote>
<p>
Exactly. Just make sure you clearly state the order in which patches have to be applied. The "cyclic" dependency is not really a problem as these tickets will be merged together anyway.
</p>
TicketleifTue, 04 Oct 2011 13:04:53 GMT
https://trac.sagemath.org/ticket/11339#comment:91
https://trac.sagemath.org/ticket/11339#comment:91
<p>
Replying to <a class="ticket" href="https://trac.sagemath.org/ticket/11339#comment:90" title="Comment 90">jdemeyer</a>:
</p>
<blockquote class="citation">
<p>
The "cyclic" dependency is not really a problem as these tickets will be merged together anyway.
</p>
</blockquote>
<p>
I'll implement merging strongly connected components... ;-)
</p>
TicketSimonKingTue, 04 Oct 2011 13:09:51 GMTstatus changed
https://trac.sagemath.org/ticket/11339#comment:92
https://trac.sagemath.org/ticket/11339#comment:92
<ul>
<li><strong>status</strong>
changed from <em>needs_review</em> to <em>positive_review</em>
</li>
</ul>
<p>
Great, <a class="closed ticket" href="https://trac.sagemath.org/ticket/11339" title="defect: Refcounting for Singular rings (closed: fixed)">#11339</a> together with <a class="closed ticket" href="https://trac.sagemath.org/ticket/10903" title="defect: Update Singular to 3-1-3-3 (closed: fixed)">#10903</a> really seem to fix it. So, let it be a positive review, then. I will rebase <a class="closed ticket" href="https://trac.sagemath.org/ticket/11856" title="defect: Raise an overflow error if the exponent of a multivariate polynomial ... (closed: fixed)">#11856</a> now, and <a class="closed ticket" href="https://trac.sagemath.org/ticket/11068" title="enhancement: Basic implementation of one- and twosided ideals of non-commutative ... (closed: fixed)">#11068</a> can wait a little.
</p>
TicketSimonKingTue, 04 Oct 2011 13:17:33 GMT
https://trac.sagemath.org/ticket/11339#comment:93
https://trac.sagemath.org/ticket/11339#comment:93
<p>
For the record: I made <a class="closed ticket" href="https://trac.sagemath.org/ticket/11856" title="defect: Raise an overflow error if the exponent of a multivariate polynomial ... (closed: fixed)">#11856</a> depend on <a class="closed ticket" href="https://trac.sagemath.org/ticket/10903" title="defect: Update Singular to 3-1-3-3 (closed: fixed)">#10903</a>. So, it should all be good now...
</p>
TicketjdemeyerTue, 04 Oct 2011 21:14:52 GMTdependencies set
https://trac.sagemath.org/ticket/11339#comment:94
https://trac.sagemath.org/ticket/11339#comment:94
<ul>
<li><strong>dependencies</strong>
set to <em>#10903 (for doctests)</em>
</li>
</ul>
TicketjdemeyerFri, 07 Oct 2011 19:11:39 GMTstatus changed; resolution, merged set
https://trac.sagemath.org/ticket/11339#comment:95
https://trac.sagemath.org/ticket/11339#comment:95
<ul>
<li><strong>status</strong>
changed from <em>positive_review</em> to <em>closed</em>
</li>
<li><strong>resolution</strong>
set to <em>fixed</em>
</li>
<li><strong>merged</strong>
set to <em>sage-4.7.2.alpha4</em>
</li>
</ul>
Ticket