Segfault when computing a Groebner basis over the integers

[Jean-Pierre Flori]

Hi Hans,

Since 4-1-0, I get the following

                     SINGULAR                                 /  Development
 A Computer Algebra System for Polynomial Computations       /   version 4.1.0
                                                           0<
 by: W. Decker, G.-M. Greuel, G. Pfister, H. Schoenemann     \   Nov 2016
FB Mathematik der Universitaet, D-67653 Kaiserslautern        \
> ring r = integer,(x,y,z),lp;
> r;
// coefficients: ZZ
// number of vars : 3
//        block   1 : ordering lp
//                  : names    x y z
//        block   2 : ordering C
> ideal i = -y^2 - 3*y + z^2 + 3, -2*y*z + z^2 + 2*z + 1,x*z + y*z + z^2, -3*x*y + 2*y*z + 6*z^2;
> i;
i[1]=-y2-3y+z2+3
i[2]=-2yz+z2+2z+1
i[3]=xz+yz+z2
i[4]=-3xy+2yz+6z2
> groebner(i);

// ***dError: assume violation at prCopy.cc:195 condition: src_r->cf==dest_r->cf
// ***dError: assume violation at prCopy.cc:179 condition: src_r->cf==dest_r->cf!!longrat:debug:1 in pDebug.cc:253

// ***dPolyReportError: coeff err
 occurred at
 occurred for poly: !!longrat:im int 2 in longrat.cc:1387
#############################################

No issues with 4-0-3:
                     SINGULAR                                 /  Development
 A Computer Algebra System for Polynomial Computations       /   version 4.0.3
                                                           0<
 by: W. Decker, G.-M. Greuel, G. Pfister, H. Schoenemann     \   Jan 2016
FB Mathematik der Universitaet, D-67653 Kaiserslautern        \
> ring r = integer,(x,y,z),lp;
> deal i = -y^2 - 3*y + z^2 + 3, -2*y*z + z^2 + 2*z + 1,x*z + y*z + z^2, -3*x*y + 2*y*z + 6*z^2;
   ? `deal` is undefined
   ? error occurred in or before STDIN line 2: `3*y + z^2 + 3, -2*y*z + z^2 + 2*z + 1,x*z + y*z + z^2, -3*x*y + 2*y*z + 6*z^2;`
> ideal i = -y^2 - 3*y + z^2 + 3, -2*y*z + z^2 + 2*z + 1,x*z + y*z + z^2, -3*x*y + 2*y*z + 6*z^2;
> groebner(i);
_[1]=164878
_[2]=2z+41856
_[3]=z2-81962z-57679
_[4]=2y-3z3+10z2+5z+8
_[5]=yz+5y+72z4-259z3-120z2-231z
_[6]=y2+3y-z2-3
_[7]=x+2y2z+yz2-2yz-z3-2z2
>
###########################################

The dError stuff comes from:
* https://github.com/Singular/Sources/blob/spielwiese/Singular/iparith.cc#L5784
Indeed the coefficients are explicitly changed to n_Q.
I did not investigate this further yet.

Best,
JPF

[Jean-Pierre Flori]

For some reason the "s" field is "33" in the coeffs rather than "3" to tell only "z" is used to represent integers:
(gdb) p *id->m[10]->coef
$27 = {
  z = {{
      _mp_alloc = 1,
      _mp_size = 1,
      _mp_d = 0x11c895f0
    }},
  n = {{
      _mp_alloc = -1543472123,
      _mp_size = 6881280,
      _mp_d = 0x6b020072c500780f
    }},
  debug = 0,
  s = 33
}
(gdb) p *id->m[10]->coef->z->_mp_d
$28 = 164878
(gdb)

But as you can see, somehow the seeked for integer is there...

[Jean-Pierre Flori]

Initialization of integers seem to have changed bw 4-0-x and 4-1-x.
In 4-0-x:

ring r = integer,(x,y,z),lp;

> ideal i = -y^2 - 3*y + z^2 + 3, -2*y*z + z^2 + 2*z + 1,x*z + y*z + z^2, -3*x*y + 2*y*z + 6*z^2;
> groebner(i);

Breakpoint 1, iiExprArithM (res=0x3fffffffcc68, a=0x3fffffff9f50, op=40)
    at iparith.cc:8582
8582    iparith.cc: No such file or directory.
(gdb) p *((ideal) a->next->Data())->m[0]->coef
$1 = {z = {{_mp_alloc = 2, _mp_size = -1, _mp_d = 0x3fffb6af49e0}}, n = {{
      _mp_alloc = 0, _mp_size = 1, _mp_d = 0x0}}, s = 2}


And in 4-1-x:
(gdb) p *((ideal) a->next->Data())->m[0]->coef
$41 = {z = {{_mp_alloc = 2, _mp_size = -1, _mp_d = 0x10891ee8}}, n = {{
      _mp_alloc = 0, _mp_size = 33, _mp_d = 0x18}}, debug = 0, s = 1}

Oops.

[Jean-Pierre Flori]

It seems the change comes from here:
* https://github.com/Singular/Sources/blob/spielwiese/Singular/LIB/standard.lib#L884

"charstr" now returns "ZZ"... and a different path is taken.

[han...@mathematik.uni-kl.de]

Thanks, that was the reason, fixed with commit
589e8eab0d5415b844ad43ec150a72e4004e1114

But on the other side, a segfault should not occur,
that means there is something more...

Hans
> --
> You received this message because you are subscribed to the Google Groups
> "libsingular-devel" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to libsingular-de...@googlegroups.com.
> To post to this group, send email to libsingu...@googlegroups.com.
> Visit this group at https://groups.google.com/group/libsingular-devel.
> For more options, visit https://groups.google.com/d/optout.

[Jean-Pierre Flori]

On Wednesday, December 21, 2016 at 7:04:32 PM UTC+1, han...@mathematik.uni-kl.de wrote:

On Tue, Dec 20, 2016 at 09:49:06AM -0800, Jean-Pierre Flori wrote:
>    It seems the change comes from here:
>    *
>    https://github.com/Singular/Sources/blob/spielwiese/Singular/LIB/standard.lib#L884
>
>    "charstr" now returns "ZZ"... and a different path is taken.
>
Thanks, that was the reason, fixed with commit
589e8eab0d5415b844ad43ec150a72e4004e1114

But on the other side, a segfault should not occur,
that means there is something more...

Yes the reason for the segfault is surely that the idCopyR at
* https://github.com/Singular/Sources/blob/spielwiese/Singular/iparith.cc#L5794
copies the coef as rationals but they are just integers (and in debug mode Singular rants about this discrepancy :

// ***dError: assume violation at prCopy.cc:195 condition: src_r->cf==dest_r->cf
// ***dError: assume violation at prCopy.cc:179 condition: src_r->cf==dest_r->cf!!longrat:debug:1 in pDebug.cc:253

.

So you end up with crap in the newly created coeffs:

 (gdb) p *((ideal) a->next->Data())->m[0]->coef
$41 = {z = {{_mp_alloc = 2, _mp_size = -1, _mp_d = 0x10891ee8}}, n = {{
      _mp_alloc = 0, _mp_size = 33, _mp_d = 0x18}}, debug = 0, s = 1}

Look at the _mp_alloc = 0, _mp_size = 33, _mp_d = 0x18.
When it gets deallocated, it just booms.

Best,
JPF