p_Delete in libsingular

6 views
Skip to first unread message

Francois Bissey

unread,
Apr 19, 2011, 8:07:01 PM4/19/11
to sage-...@googlegroups.com

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__dealloc__
(

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).

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.

Francois Bissey

unread,
Apr 23, 2011, 5:31:41 AM4/23/11
to sage-...@googlegroups.com

> 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

Reply all
Reply to author
Forward
0 new messages