6 views

Skip to first unread message

Jul 10, 2010, 10:06:27 AM7/10/10

to libsingu...@googlegroups.com

Hi,

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

Jul 11, 2010, 8:56:22 AM7/11/10

to libsingu...@googlegroups.com

On Saturday 10 July 2010, you wrote:

> 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?

> 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,

Jul 12, 2010, 5:42:12 AM7/12/10

to libsingu...@googlegroups.com

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

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

Jul 12, 2010, 10:38:37 AM7/12/10

to libsingu...@googlegroups.com

On Monday 12 July 2010, Hans Schoenemann wrote:

> 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 ?

> 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,

Jul 12, 2010, 10:58:09 AM7/12/10

to libsingu...@googlegroups.com

Operating under the assumption that all singclap_* functions destroy their

inputs it seems I get rid of most of the the SIGSEGVs.

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

Jul 12, 2010, 12:51:12 PM7/12/10

to libsingu...@googlegroups.com

On Mon, Jul 12, 2010 at 03:58:09PM +0100, Martin Albrecht wrote:

> 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

>

> ...

>

> 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

>

> ...

>

> #6 0x00000000008902ce in ngcCopy (a=0x0) at gnumpc.cc:154

> 154 gmp_complex* b= new gmp_complex( *(gmp_complex*)a );

Oh yes, 0x0 was a valid represention of 0,> 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

Jul 12, 2010, 1:01:27 PM7/12/10

to libsingu...@googlegroups.com

>

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

Yes, the p_Delete should be removed here.> 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

Jul 13, 2010, 10:19:01 AM7/13/10

to libsingu...@googlegroups.com

Hi everyone,

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 =

Reply all

Reply to author

Forward

0 new messages

Search

Clear search

Close search

Google apps

Main menu