SIGSEGV in 3-1-1-3
Martin Albrecht
I tried to update Singular to 3-1-1-3 for Sage but I get segmentation faults
like these:
1)
0x00007fbf13bc5b69 in omTakeOutBinPage (page=0x2046000, bin=0x240bf10) at
om_Alloc.c:84
84 page->next->prev = page->prev;
(gdb) bt
#0 0x00007fbf13bc5b69 in omTakeOutBinPage (page=0x2046000, bin=0x240bf10) at
om_Alloc.c:84
#1 0x00007fbf13bc5a4f in omFreeToPageFault (page=0x2046000, addr=0x2046ad0)
at om_Alloc.c:200
#2 0x00007fbf139cc6a9 in _nlDelete_NoImm (a=0x7fbf2b84b560) at
longrat.cc:1566
#3 0x00007fbf13a99dd4 in nlDelete (a=0x7fbf2b84b560, r=0x7fbf2b845030) at
longrat.cc:2307
#4 0x00007fbf13aa88cc in p_Delete__FieldQ_LengthGeneral_OrdGeneral
(pp=0x7fff6831cf18,
r=0x7fbf2b845030) at p_Delete__T.cc:18
#5 0x00007fbf13f066a1 in
__pyx_pf_4sage_5rings_10polynomial_28multi_polynomial_libsingular_23MPolynomial_libsingular_factor
(__pyx_v_self=0x61ffef0, __pyx_args=<value optimized out>,
__pyx_kwds=<value optimized out>)
2)
#0 0x00007fab00000001 in ?? ()
#1 0x00007fab4b7286ae in ~CanonicalForm (this=0x7fff9d97ae50) at
cf_inline.cc:255
#2 0x00007fab4b70beff in extgcd (f=@0x7fff9d97b310, g=@0x7fff9d97b300,
a=@0x7fff9d97b2f0,
b=@0x7fff9d97b2e0) at cf_gcd.cc:236
#3 0x00007fab4b78aa12 in InternalPoly::invert (this=0x7fab4b33db70) at
int_poly.cc:249
#4 0x00007fab4b78c11e in InternalPoly::dividecoeff (this=0x7fab4b33db70,
cc=0x6, invert=true)
at int_poly.cc:943
#5 0x00007fab4b78b27b in InternalPoly::divremcoefft (this=0x7fab4b33db70,
cc=0x6,
quot=@0x7fff9d97b520, rem=@0x7fff9d97b518, invert=true) at
int_poly.cc:1215
#6 0x00007fab4b6f583d in divremt (f=@0x7fab4b3603e0, g=@0x7fff9d97b5d0,
q=@0x7fff9d97b5c0,
r=@0x7fff9d97b5b0) at canonicalform.cc:915
#7 0x00007fab4b78d221 in InternalPoly::divremsamet (this=0x7fab4b33d850,
acoeff=0x7fab4b33d738,
quot=@0x7fff9d97b690, rem=@0x7fff9d97b688) at int_poly.cc:642
#8 0x00007fab4b6f5947 in divremt (f=@0x7fff9d97b920, g=@0x7fff9d97b910,
q=@0x7fff9d97b710,
r=@0x7fff9d97b720) at canonicalform.cc:920
#9 0x00007fab4b6f9183 in fdivides (f=@0x7fff9d97b910, g=@0x7fff9d97b920) at
cf_algorithm.cc:367
#10 0x00007fab4b709fb9 in gcd (f=@0x7fff9d97b910, g=@0x7fff9d97b920) at
cf_gcd.cc:855
#11 0x00007fab4b714a81 in cf_content (f=@0x7fff9d97bbe0, g=@0x7fff9d97bbd0) at
cf_gcd.cc:702
#12 0x00007fab4b70835c in gcd_poly (f=@0x7fff9d97bfc0, g=@0x7fff9d97bfd0) at
cf_gcd.cc:551
#13 0x00007fab4b70a05d in gcd (f=@0x7fff9d97bfc0, g=@0x7fff9d97bfd0) at
cf_gcd.cc:863
#14 0x00007fab4b54a98d in singclap_gcd_r (f=0x7fab4b33d620, g=0x7fab4b33d800,
r=0x7fab4b347e90)
at clapsing.cc:71
#15 0x00007fab4b54ac52 in singclap_gcd (f=0x7fab4b33d620, g=0x7fab4b33d800) at
clapsing.cc:109
#16 0x00007fab4baebc1b in
__pyx_pf_4sage_5rings_10polynomial_28multi_polynomial_libsingular_23MPolynomial_libsingular_gcd
(__pyx_v_self=0x44a8560, __pyx_args=<value optimized out>,
__pyx_kwds=<value optimized out>)
at sage/rings/polynomial/multi_polynomial_libsingular.cpp:24554
3)
0x00007fc882c664c4 in nlGetNumerator (n=@0x7fff86f98a18, r=0x7fc8829f1030) at
longrat.cc:1445
1445 if (n->s==0)
Current language: auto; currently c++
(gdb) up
#1 0x00007fc881f4c9d2 in __pyx_f_4sage_4libs_8singular_8singular_si2sa_QQ
(__pyx_v_n=0x0,
__pyx_v__ring=0x7fc8829f1030) at sage/libs/singular/singular.cpp:2873
2873 __pyx_v_nom = nlGetNumerator(__pyx_v_n, __pyx_v__ring);
(gdb) bt
#0 0x00007fc882c664c4 in nlGetNumerator (n=@0x7fff86f98a18, r=0x7fc8829f1030)
at longrat.cc:1445
#1 0x00007fc881f4c9d2 in __pyx_f_4sage_4libs_8singular_8singular_si2sa_QQ
(__pyx_v_n=0x0,
__pyx_v__ring=0x7fc8829f1030) at sage/libs/singular/singular.cpp:2873
#2 0x00007fc881f528de in __pyx_f_4sage_4libs_8singular_8singular_si2sa
(__pyx_v_n=0x0,
__pyx_v__ring=0x7fc8829f1030, __pyx_v_base=0x14cc440) at
sage/libs/singular/singular.cpp:5457
#3 0x00007fc88315d315 in
__pyx_pf_4sage_5rings_10polynomial_28multi_polynomial_libsingular_23MPolynomial_libsingular_dict
(__pyx_v_self=0x49ebc68, unused=<value optimized out>)
at sage/rings/polynomial/multi_polynomial_libsingular.cpp:16736
#4 0x00007fc89b659f48 in PyObject_Call (func=0x447f518, arg=0x7fc89bb92050,
kw=0x0)
Also, in other cases I seem to get infinite loops. So in summary, something
seems really off with Singular 3-1-1-3 and Sage. Any ideas?
Martin
--
name: Martin Albrecht
_pgp: http://pgp.mit.edu:11371/pks/lookup?op=get&search=0x8EF0DC99
_otr: 47F43D1A 5D68C36F 468BAEBA 640E8856 D7951CCF
_www: http://www.informatik.uni-bremen.de/~malb
_jab: martinr...@jabber.ccc.de
Martin Albrecht
> Also, in other cases I seem to get infinite loops. So in summary, something
> seems really off with Singular 3-1-1-3 and Sage. Any ideas?
Hi,
two comments by David Kirkby at
http://trac.sagemath.org/sage_trac/ticket/8059
1)
>Is it possible you could request the upstream developers distribute the
>source code so the files generated by tools like autoconf, flex, actually
>have later modification times of the generated file newer than the file they
>are generated from?
>
>Currently libparse.cc, which is the output from 'flex' has exactly the same
>modification time (to the ns) as the file it was supposedly generated from
>(libparse.l). I doubt 'flex' actually run in < 1 ns!
>
>-rw-r----- 1 drkirkby staff 109422 2010-02-03 13:58:03.000000000 +0000
src/Singular/libparse.cc
>-rw-r----- 1 drkirkby staff 30875 2010-02-03 13:58:03.000000000 +0000
src/Singular/libparse.l
>
>Likewise for these files. Clearly autoconf did not run in under a ns.
>
>-rwxr-x--- 1 drkirkby staff 85614 2010-03-03 11:36:23.000000000 +0000
src/factory/configure
>-rw-r----- 1 drkirkby staff 13992 2010-03-03 11:36:23.000000000 +0000
src/factory/configure.in
>
>This will save us having to 'touch' the files.
2)
>do you see this warning message about warning: returning reference to
>temporary? I got that warnings when building on OpenSolaris - see below.
>g++ -m64 -O2 -g -m64 -fPIC -pipe -fno-implicit-templates -I. -I../kernel -
I/export/home/drkirkby/sage-4.5.alpha4/local/include -
I/export/home/drkirkby/sage-4.5.alpha4/local/include -
I/export/home/drkirkby/sage-4.5.alpha4/local/include -O2 -g -m64 -DNDEBUG -
DOM_NDEBUG -Dix86_SunOS -DHAVE_CONFIG_H -c iparith.cc
>In file included from ../kernel/ring.h:13,
> from subexpr.h:16,
> from ipid.h:13,
> from iparith.cc:20:
>../kernel/polys-impl.h:177:1: warning: "pPolyAssumeReturn" redefined
>../kernel/polys-impl.h:176:1: warning: this is the location of the previous
>definition
>In file included from ../kernel/walkMain.h:5,
> from ../kernel/walkProc.h:3,
> from iparith.cc:56:
>../kernel/int64vec.h: In member function 'const int& int64vec::operator[]
(int) const':
>../kernel/int64vec.h:51: warning: returning reference to temporary
>
>That sounds the sort of error which could result in segfaults.
Cheers,
Hans Schoenemann
> Hi,
>
> I tried to update Singular to 3-1-1-3 for Sage but I get segmentation faults
That seems to be a memory corruption:
- 3-1-1-1 (beside other things) fixed some meory leaks:
for example:
in some case factorize delete its arguments, in some cases not:
now:
ideal singclap_factorize ( poly f, intvec ** v , int with_exps)
destroys f always
- 3-1-1-2 introduced a new factorization and gcd for polynomials over
alg. extensions of Z/p - which may have bugs in it
(see Singular/ChangeLog)
So which was the last version which worked ?
Can you provide the examples which triggered these segfaults ?
The other thing reported on this list is simply a typo:
change line 43 of kernel/int64vec.h:
- inline const int& operator[](int i) const
+ inline const int64& operator[](int i) const
Hans
Martin Albrecht
> On Sat, Jul 10, 2010 at 03:06:27PM +0100, Martin Albrecht wrote:
> > Hi,
> >
> > I tried to update Singular to 3-1-1-3 for Sage but I get segmentation
> > faults ....
>
> That seems to be a memory corruption:
> - 3-1-1-1 (beside other things) fixed some meory leaks:
> for example:
> in some case factorize delete its arguments, in some cases not:
> now:
> ideal singclap_factorize ( poly f, intvec ** v , int with_exps)
> destroys f always
> - 3-1-1-2 introduced a new factorization and gcd for polynomials over
> alg. extensions of Z/p - which may have bugs in it
> (see Singular/ChangeLog)
> So which was the last version which worked ?
3-1-1-0 definitely worked. I'll try 3-1-1-1 and 3-1-1-2 to see where it
breaks.
> Can you provide the examples which triggered these segfaults ?
I tracked one down to:
I = singclap_factorize ( ptemp, &iv , 0)
...
p_Delete(&ptemp,_ring)
i.e. we delete ptemp which is deleted by sinclap_factorize in the new version
already.
What about?
ret = singclap_pdivide(prod , gcd )
p_Delete(&prod, _ring)
p_Delete(&gcd, _ring)
and
singclap_isSqrFree()
singclap_resultant()
Is it correct to assume that they all kill their inputs now?
> The other thing reported on this list is simply a typo:
> change line 43 of kernel/int64vec.h:
> - inline const int& operator[](int i) const
> + inline const int64& operator[](int i) const
i fixed this in our SPKG.
Cheers,
Martin Albrecht
inputs it seems I get rid of most of the the SIGSEGVs.
Here's a remaining one:
SINGULAR / Development
A Computer Algebra System for Polynomial Computations / version 3-1-1
0<
by: G.-M. Greuel, G. Pfister, H. Schoenemann \ Feb 2010
FB Mathematik der Universitaet, D-67653 Kaiserslautern \
> ring sage6=(complex,15,0,I),(x, y),dp;
> poly f = y*x^2 + x + 1;
> division(f,x);
Singular : signal 11 (v: 3113/2010071215):
current line:>>division(f,x);<<
Segment fault/Bus error occurred at 7f0689d3bc30 because of 10206
(r:1278946529)
please inform the authors
...
debug (method=0) at cntrlc.cc:472
472 while (si_stop_stack_trace_x) ;
(gdb) up
#1 0x000000000057b25e in sigsegv_handler (sig=11, s=...) at cntrlc.cc:198
198 if (sig!=SIGINT) debug(INTERACTIVE);
(gdb) up
#2 <signal handler called>
Current language: auto
The current source language is "auto; currently c".
(gdb) up
#3 0x00007f068938c8c6 in __gmpf_set () from /usr/local/sage-4.4.4-
singular/local/lib/libgmp.so.3
(gdb) up
#4 0x000000000062013d in gmp_float::operator= (this=0x7f0689d3bc30, a=...) at
mpr_complex.h:71
71 mpf_set( t, a.t );
Current language: auto
The current source language is "auto; currently c++".
(gdb) up
#5 0x00000000006aa054 in gmp_complex (this=0x7f0689d3bc30, v=...) at
mpr_complex.h:195
195 r= v.r;
(gdb) up
#6 0x00000000008902ce in ngcCopy (a=0x0) at gnumpc.cc:154
154 gmp_complex* b= new gmp_complex( *(gmp_complex*)a );
Hans Schoenemann
> Operating under the assumption that all singclap_* functions destroy their
> inputs it seems I get rid of most of the the SIGSEGVs.
>
> Here's a remaining one:
>
> SINGULAR / Development
> A Computer Algebra System for Polynomial Computations / version 3-1-1
> 0<
> by: G.-M. Greuel, G. Pfister, H. Schoenemann \ Feb 2010
> FB Mathematik der Universitaet, D-67653 Kaiserslautern \
> > ring sage6=(complex,15,0,I),(x, y),dp;
> > poly f = y*x^2 + x + 1;
> > division(f,x);
> Singular : signal 11 (v: 3113/2010071215):
> current line:>>division(f,x);<<
> Segment fault/Bus error occurred at 7f0689d3bc30 because of 10206
> (r:1278946529)
> please inform the authors
>
> ...
>
> 154 gmp_complex* b= new gmp_complex( *(gmp_complex*)a );
while now it should always be a pointer to gmp_complex.
To fix this: kernel/ring.cc, line 1610:
- res->minpoly=nCopy(r->minpoly);
+ if (r->minpoly!=NULL) res->minpoly=nCopy(r->minpoly);
Hans
Hans Schoenemann
> I tracked one down to:
>
> I = singclap_factorize ( ptemp, &iv , 0)
> ...
> p_Delete(&ptemp,_ring)
>
> i.e. we delete ptemp which is deleted by sinclap_factorize in the new version
> already.
>
> What about?
>
> ret = singclap_pdivide(prod , gcd )
> p_Delete(&prod, _ring)
> p_Delete(&gcd, _ring)
>
> and
>
> singclap_isSqrFree()
does not change the poly
> singclap_resultant()
does not change the polys
>
> Is it correct to assume that they all kill their inputs now?
>
>
Hans
Martin Albrecht
following Hans' suggestions I'm down to one remaining issue:
Singular 3-1-1-3 gives a wrong output for the reduction over the integers:
---------------------------------------------------------------
SINGULAR / Development
A Computer Algebra System for Polynomial Computations / version 3-1-1
0<
by: G.-M. Greuel, G. Pfister, H. Schoenemann \ Feb 2010
FB Mathematik der Universitaet, D-67653 Kaiserslautern \
> ring r = integer,(a,b,c),dp;
// ** You are using coefficient rings which are not fields.
// ** Please note that only limited functionality is available
// ** for these coefficients.
// **
// ** The following commands are meant to work:
// ** - basic polynomial arithmetic
// ** - std
// ** - syz
// ** - lift
// ** - reduce
> poly p = b*c + 1;
> ideal i = -12*a*b - 3*b^2 + 6*a, a^2 + 13*b^2 - 2*c^2 - 97*c, -b + 2*c;
> reduce(p,std(i));
2c2-1
---------------------------------------------------------------
The last output is wrong, it should read 2c2+1 since
2c2 + 1 =