> While working on getting sage to work with python-2.7.1 I encountered a
> segfault in sage which seems to come from libsingular.
> In fact the backtrace points to line 127 of kernel/ideals.cc in the
> singular source code:
> Program received signal SIGSEGV, Segmentation fault.
> id_Delete (h=0x509b078, r=0x0) at ideals.cc:127
> 127 p_Delete(&((*h)->m[--j]), r);
> (gdb) bt
> #0 id_Delete (h=0x509b078, r=0x0) at ideals.cc:127
> #1 0x00007fffb9a3db49 in
> __pyx_pf_4sage_4libs_8singular_17groebner_strategy_16GroebnerStrategy_1__de
> alloc__ (
>
> It seems to bark up at the function p_Delete, this function is used in a
> lot of places but seem to be defined in a "template"
> kernel/p_Delete__T.cc. This template generate a number of version of
> p_Delete (p_Delete_procxxx and so on) but p_Delete itself seem to never be
> linked anywhere in the code and with ideals.cc in particular. The function
> containing it in this particular instance is id_Delete called from
> sage/libs/singular/groebner_strategy.pyx.
>
> Does anyone know if this could be a bug in singular or old code that is to
> be removed (and in that case groebner_strategy.pyx should be updated).
>
Thanks to Martin Albretch for forwarding this to people on libsingular-devel.
Alexandre Dreyer pointed out that the ring passed to id_Delete was a NULL
pointer in the first place which lead to the failure.
After looking at the backtrace a bit more I saw that the python garbage
collection module had been called earlier. So I repeated the sequence of
command leading to the fault preceding by
sage: import gc
sage: gc.disable()
And then the problem disappeared. Or so I thought. There are 3 of us working
and testing sage on python-2.7.1. Apart from myself there is Steve Trogdon and
Martin von Gagern.
Steve and I had the same failures and he found a sequence of command producing
the fault and I could repeat it on my systems. Martin however didn't see any
faults.
After some more tests with the gc.disable() trick Steve got a new fault. The
sequence of command executes fine but sage crashes when he quits...
sage: loads(dumps(phi)) == phi
True
sage: quit
Exiting Sage (CPU time 0m0.12s, Wall time 1m30.94s).
Program received signal SIGSEGV, Segmentation fault.
id_Delete (h=0x4809da8, r=0x0) at ideals.cc:127
127 ideals.cc: No such file or directory.
in ideals.cc
(gdb) bt
#0 id_Delete (h=0x4809da8, r=0x0) at ideals.cc:127
#1 0x00007fffc805ab56 in
__pyx_pf_4sage_4libs_8singular_17groebner_strategy_16GroebnerStrategy_1__dealloc__
(o=0x46b3c80) at sage/libs/singular/groebner_strategy.cpp:2570
Still the same libraries involved. After some research he found the following
statement in sage's code:
in MPolynomialRing_libsingular class in
sage/rings/polynomial/multi_polynomial_libsingular.pyx:
def __dealloc__(self):
r"""
Carefully deallocate the ring, without changing "currRing"
(since this method can be at unpredictable times due to garbage
collection).
which eventually calls singular_ring_delete from
sage/libs/singular/ring.pyx. And again there
cdef void singular_ring_delete(ring *doomed):
"""
Carefully deallocate the ring, without changing "currRing" (since
this method can be called at unpredictable times due to garbage
collection).
So I think with python-2.7.1 we are again victim garbage collection and
it has more painful consequences even when you are careful.
Francois
This email may be confidential and subject to legal privilege, it may
not reflect the views of the University of Canterbury, and it is not
guaranteed to be virus free. If you are not an intended recipient,
please notify the sender immediately and erase all copies of the message
and any attachments.
Please refer to http://www.canterbury.ac.nz/emaildisclaimer for more
information.
--
To post to this group, send an email to sage-devel@googlegroups.com
To unsubscribe from this group, send an email to
sage-devel+unsubscr...@googlegroups.com
For more options, visit this group at http://groups.google.com/group/sage-devel
URL: http://www.sagemath.org
