Opened 7 years ago

Closed 7 years ago

Last modified 7 years ago

#13883 closed defect (fixed)

Fix an assertion in polybori

Reported by: SimonKing Owned by: malb
Priority: major Milestone: sage-5.6
Component: commutative algebra Keywords: polybori FGLMStrategy debug
Cc: AlexanderDreyer, PolyBoRi Merged in: sage-5.6.beta3
Authors: Alexander Dreyer Reviewers: Jean-Pierre Flori
Report Upstream: Reported upstream. No feedback yet. Work issues:
Branch: Commit:
Dependencies: Stopgaps:

Description (last modified by AlexanderDreyer)

The following crash occurs in Sage's debug version of #13864:

sage: from polybori import *                                  
sage: B.<x,y,z> = BooleanPolynomialRing()
sage: x > y > z                                               
True                                                          
sage: old_ring  = B
sage: B._change_ordering(dp_asc)                                 
sage: x > y > z                           
False                                           
sage: z > y > x
True
sage: new_ring = B.clone(ordering=lp) 
sage: ideal = BooleanPolynomialVector([x+z, y+z])
sage: FGLMStrategy(old_ring, new_ring, ideal)
python: groebner/include/polybori/groebner/PolyEntryVector.h:74: virtual void polybori::groebner::PolyEntryVector::append(const polybori::groebner::PolyEntry&): Assertion `m_indices.checked(back().lead) == (size_type)-1' failed.

The gdb backtrace is as follows:

#0  0x00007ffff6d95d95 in raise () from /lib64/libc.so.6
#1  0x00007ffff6d972ab in abort () from /lib64/libc.so.6
#2  0x00007ffff6d8e8fe in __assert_fail_base () from /lib64/libc.so.6
#3  0x00007ffff6d8e9a2 in __assert_fail () from /lib64/libc.so.6
#4  0x00007fffd0bfa073 in polybori::groebner::PolyEntryVector::append(polybori::groebner::PolyEntry const&) [clone .part.506] ()
   from /home/simon/SAGE/debug/sage-5.6.beta1/local/lib/libpolybori_groebner-0.8.2.so.0
#5  0x00007fffd0c165b9 in polybori::groebner::FGLMStrategy::FGLMStrategy(polybori::BoolePolyRing const&, polybori::BoolePolyRing const&, std::vector<polybori::BoolePolynomial, std::allocator<polybori::BoolePolynomial> > const&) () from /home/simon/SAGE/debug/sage-5.6.beta1/local/lib/libpolybori_groebner-0.8.2.so.0
#6  0x00007fffd15378b7 in WrappedPtr<polybori::groebner::FGLMStrategy>::WrappedPtr<polybori::BoolePolyRing, polybori::BoolePolyRing, std::vector<polybori::BoolePolynomial> > (this=0x7fffffffa740, 
    arg1=..., arg2=..., arg3=...) at /home/simon/SAGE/debug/sage-5.6.beta1/local/include/csage/pb_wrap.h:197
#7  0x00007fffd14dbc5e in __pyx_pf_4sage_5rings_10polynomial_5pbori_12FGLMStrategy___init__ (__pyx_v_self=0x7fffc270dee8, __pyx_v_from_ring=0x2f412b0, __pyx_v_to_ring=0x2f69200, 
    __pyx_v_vec=0x7fffc26f7760) at sage/rings/polynomial/pbori.cpp:39777
#8  0x00007fffd14dae26 in __pyx_pw_4sage_5rings_10polynomial_5pbori_12FGLMStrategy_1__init__ (__pyx_v_self=0x7fffc270dee8, __pyx_args=0x7ffff237bb60, __pyx_kwds=0x0)
    at sage/rings/polynomial/pbori.cpp:39568
#9  0x00007ffff7a4c0dd in type_call (type=0x7fffd17b8c20 <__pyx_type_4sage_5rings_10polynomial_5pbori_FGLMStrategy>, args=0x7ffff237bb60, kwds=0x0) at Objects/typeobject.c:737
#10 0x00007ffff79be33e in PyObject_Call (func=0x7fffd17b8c20 <__pyx_type_4sage_5rings_10polynomial_5pbori_FGLMStrategy>, arg=0x7ffff237bb60, kw=0x0) at Objects/abstract.c:2529
#11 0x00007ffff7ac7a58 in do_call (func=0x7fffd17b8c20 <__pyx_type_4sage_5rings_10polynomial_5pbori_FGLMStrategy>, pp_stack=0x7fffffffaaa0, na=3, nk=0) at Python/ceval.c:4239
#12 0x00007ffff7ac6d92 in call_function (pp_stack=0x7fffffffaaa0, oparg=3) at Python/ceval.c:4044
#13 0x00007ffff7ac16ba in PyEval_EvalFrameEx (f=0x2f6d0f0, throwflag=0) at Python/ceval.c:2666
#14 0x00007ffff7ac40aa in PyEval_EvalCodeEx (co=0x7fffc2747930, globals=0x9b0080, locals=0x9b0080, args=0x0, argcount=0, kws=0x0, kwcount=0, defs=0x0, defcount=0, closure=0x0) at Python/ceval.c:3253
#15 0x00007ffff7ab9a88 in PyEval_EvalCode (co=0x7fffc2747930, globals=0x9b0080, locals=0x9b0080) at Python/ceval.c:667
#16 0x00007ffff7ac9693 in exec_statement (f=0x297f250, prog=0x7fffc2747930, globals=0x9b0080, locals=0x9b0080) at Python/ceval.c:4718
#17 0x00007ffff7abde26 in PyEval_EvalFrameEx (f=0x297f250, throwflag=0) at Python/ceval.c:1880
#18 0x00007ffff7ac40aa in PyEval_EvalCodeEx (co=0x7ffff280c720, globals=0x909bf0, locals=0x0, args=0x297eae0, argcount=2, kws=0x297eaf0, kwcount=0, defs=0x0, defcount=0, closure=0x0)
    at Python/ceval.c:3253
#19 0x00007ffff7ac71b5 in fast_function (func=0x7ffff235b450, pp_stack=0x7fffffffb420, n=2, na=2, nk=0) at Python/ceval.c:4117
#20 0x00007ffff7ac6d76 in call_function (pp_stack=0x7fffffffb420, oparg=1) at Python/ceval.c:4042
#21 0x00007ffff7ac16ba in PyEval_EvalFrameEx (f=0x297e930, throwflag=0) at Python/ceval.c:2666
#22 0x00007ffff7ac40aa in PyEval_EvalCodeEx (co=0x7ffff280c5c0, globals=0x909bf0, locals=0x0, args=0x2f06e38, argcount=3, kws=0x2f06e50, kwcount=0, defs=0x7ffff2354f10, defcount=2, closure=0x0)
    at Python/ceval.c:3253
#23 0x00007ffff7ac71b5 in fast_function (func=0x7ffff235b3a8, pp_stack=0x7fffffffb910, n=3, na=3, nk=0) at Python/ceval.c:4117
#24 0x00007ffff7ac6d76 in call_function (pp_stack=0x7fffffffb910, oparg=2) at Python/ceval.c:4042
#25 0x00007ffff7ac16ba in PyEval_EvalFrameEx (f=0x2f06c90, throwflag=0) at Python/ceval.c:2666
#26 0x00007ffff7ac708a in fast_function (func=0x7ffff235b4f8, pp_stack=0x7fffffffbc90, n=2, na=2, nk=0) at Python/ceval.c:4107
#27 0x00007ffff7ac6d76 in call_function (pp_stack=0x7fffffffbc90, oparg=1) at Python/ceval.c:4042
#28 0x00007ffff7ac16ba in PyEval_EvalFrameEx (f=0x9c6fb0, throwflag=0) at Python/ceval.c:2666
#29 0x00007ffff7ac40aa in PyEval_EvalCodeEx (co=0x7ffff280a9e0, globals=0x909bf0, locals=0x0, args=0x9bd3b8, argcount=2, kws=0x9bd3c8, kwcount=0, defs=0x7ffff235a1d8, defcount=1, closure=0x0)
    at Python/ceval.c:3253
#30 0x00007ffff7ac71b5 in fast_function (func=0x7ffff2359e28, pp_stack=0x7fffffffc180, n=2, na=2, nk=0) at Python/ceval.c:4117
#31 0x00007ffff7ac6d76 in call_function (pp_stack=0x7fffffffc180, oparg=1) at Python/ceval.c:4042
#32 0x00007ffff7ac16ba in PyEval_EvalFrameEx (f=0x9bd220, throwflag=0) at Python/ceval.c:2666
#33 0x00007ffff7ac40aa in PyEval_EvalCodeEx (co=0x7ffff2806f60, globals=0x909bf0, locals=0x0, args=0x9cc360, argcount=2, kws=0x9cc370, kwcount=0, defs=0x7ffff235a168, defcount=1, closure=0x0)
    at Python/ceval.c:3253
#34 0x00007ffff7ac71b5 in fast_function (func=0x7ffff2359a38, pp_stack=0x7fffffffc670, n=2, na=2, nk=0) at Python/ceval.c:4117
#35 0x00007ffff7ac6d76 in call_function (pp_stack=0x7fffffffc670, oparg=1) at Python/ceval.c:4042
#36 0x00007ffff7ac16ba in PyEval_EvalFrameEx (f=0x9cc1c0, throwflag=0) at Python/ceval.c:2666
#37 0x00007ffff7ac40aa in PyEval_EvalCodeEx (co=0x7ffff6a9b510, globals=0x707970, locals=0x0, args=0x6f6f58, argcount=1, kws=0x6f6f60, kwcount=2, defs=0x7ffff2ea5b50, defcount=2, closure=0x0)
    at Python/ceval.c:3253
#38 0x00007ffff7ac71b5 in fast_function (func=0x7ffff2367450, pp_stack=0x7fffffffcb60, n=5, na=1, nk=2) at Python/ceval.c:4117
#39 0x00007ffff7ac6d76 in call_function (pp_stack=0x7fffffffcb60, oparg=512) at Python/ceval.c:4042
#40 0x00007ffff7ac16ba in PyEval_EvalFrameEx (f=0x6f6dd0, throwflag=0) at Python/ceval.c:2666
#41 0x00007ffff7ac40aa in PyEval_EvalCodeEx (co=0x7ffff7e2f1a0, globals=0x644f50, locals=0x644f50, args=0x0, argcount=0, kws=0x0, kwcount=0, defs=0x0, defcount=0, closure=0x0) at Python/ceval.c:3253
#42 0x00007ffff7ab9a88 in PyEval_EvalCode (co=0x7ffff7e2f1a0, globals=0x644f50, locals=0x644f50) at Python/ceval.c:667
#43 0x00007ffff7af836d in run_mod (mod=0x6e8c18, filename=0x7fffffffd88f "/home/simon/SAGE/debug/sage-5.6.beta1/local/bin/sage-ipython", globals=0x644f50, locals=0x644f50, flags=0x7fffffffd090, 
    arena=0x62d530) at Python/pythonrun.c:1347
#44 0x00007ffff7af82f3 in PyRun_FileExFlags (fp=0x6451e0, filename=0x7fffffffd88f "/home/simon/SAGE/debug/sage-5.6.beta1/local/bin/sage-ipython", start=257, globals=0x644f50, locals=0x644f50, 
    closeit=1, flags=0x7fffffffd090) at Python/pythonrun.c:1333
#45 0x00007ffff7af6aa0 in PyRun_SimpleFileExFlags (fp=0x6451e0, filename=0x7fffffffd88f "/home/simon/SAGE/debug/sage-5.6.beta1/local/bin/sage-ipython", closeit=1, flags=0x7fffffffd090)
    at Python/pythonrun.c:937
#46 0x00007ffff7af6092 in PyRun_AnyFileExFlags (fp=0x6451e0, filename=0x7fffffffd88f "/home/simon/SAGE/debug/sage-5.6.beta1/local/bin/sage-ipython", closeit=1, flags=0x7fffffffd090)
    at Python/pythonrun.c:741
#47 0x00007ffff7b12536 in Py_Main (argc=3, argv=0x7fffffffd218) at Modules/main.c:639
#48 0x00000000004007b4 in main (argc=3, argv=0x7fffffffd218) at ./Modules/python.c:23

Apply FGLMStrategy_sigon.patch

Install http://boxen.math.washington.edu/home/dreyer/spkg/polybori-0.8.2.p0.spkg

Attachments (1)

FGLMStrategy_sigon.patch (2.0 KB) - added by AlexanderDreyer 7 years ago.
patch for pbori.pyx

Download all attachments as: .zip

Change History (30)

comment:1 Changed 7 years ago by fbissey

Very strange I don't remember seeing anything like it in sage on gentoo or lmnd. I am not convinced that it is just from python debugging unless we collaterally fixed this along with singular and linbox. Of course now I realise that it may be the result from a doctest so it may have been dormant on us all along.

comment:2 Changed 7 years ago by fbissey

Could not reproduce in sage-on-gentoo but we don't have "--with-pydebug" by default (can still build python with debugging symbols for gdb but not the stuff from pydebug). Investigating further.

comment:3 follow-up: Changed 7 years ago by AlexanderDreyer

PolyEntryVector::append contains an assertion, which does not apply when compiled without Debug-Options. The actual problem is probably the ._change_ordering, which never was a user command. It will yield inconsistencies (we should remove it) , so please use the ordering option of BooleanPolynomialRing (DegNegLex is dp_asc). Perhaps that already fixed the problem.

comment:4 in reply to: ↑ 3 Changed 7 years ago by SimonKing

Replying to AlexanderDreyer:

PolyEntryVector::append contains an assertion, which does not apply when compiled without Debug-Options. The actual problem is probably the ._change_ordering, which never was a user command. It will yield inconsistencies (we should remove it) , so please use the ordering option of BooleanPolynomialRing (DegNegLex is dp_asc). Perhaps that already fixed the problem.

So, you say I should rewrite the test, so that ._change_ordering is not used?

comment:5 Changed 7 years ago by jpflori

Do you mean doing something like:

sage: from polybori import *
sage: B.<x,y,z> = BooleanPolynomialRing(order='lex')
sage: C.<x,y,z> = BooleanPolynomialRing(order='degneglex')
sage: ideal = BooleanPolynomialVector([x+z, y+z])
sage: sage: FGLMStrategy(B, C, ideal)

because it bangs as well with

terminate called after throwing an instance of 'std::runtime_error'
  what():  Operands come from different manager.
/home/jp/boulot/sage/sage-5.6.beta2/local/lib/libcsage.so(print_backtrace+0x31)[0x7ffcdf8aed7d]
/home/jp/boulot/sage/sage-5.6.beta2/local/lib/libcsage.so(sigdie+0x14)[0x7ffcdf8aedaf]
/home/jp/boulot/sage/sage-5.6.beta2/local/lib/libcsage.so(sage_signal_handler+0x1da)[0x7ffcdf8ae95b]
/lib/x86_64-linux-gnu/libpthread.so.0(+0xf310)[0x7ffce464a310]
/lib/x86_64-linux-gnu/libc.so.6(gsignal+0x35)[0x7ffce3bc6dd5]
/lib/x86_64-linux-gnu/libc.so.6(abort+0x17b)[0x7ffce3bc9efb]
/usr/lib/x86_64-linux-gnu/libstdc++.so.6(_ZN9__gnu_cxx27__verbose_terminate_handlerEv+0x11d)[0x7ffcdf5dc89d]
/usr/lib/x86_64-linux-gnu/libstdc++.so.6(+0x63996)[0x7ffcdf5da996]
/usr/lib/x86_64-linux-gnu/libstdc++.so.6(+0x639c3)[0x7ffcdf5da9c3]
/usr/lib/x86_64-linux-gnu/libstdc++.so.6(+0x63bee)[0x7ffcdf5dabee]
/home/jp/boulot/sage/sage-5.6.beta2/local/lib/python2.7/site-packages/sage/rings/polynomial/pbori.so(_ZNK8polybori16CApplyNodeFacadeINS_8BooleSetEP6DdNodeE16checkSameManagerERKS1_+0xc0)[0x7ffcbf85e9ba]
/home/jp/boulot/sage/sage-5.6.beta2/local/lib/python2.7/site-packages/sage/rings/polynomial/pbori.so(_ZNK8polybori16CApplyNodeFacadeINS_8BooleSetEP6DdNodeE5applyIP15pbori_DdManagerEES1_PFS3_T_S3_S3_ERKS1_+0x2e)[0x7ffcbf8578a4]
/home/jp/boulot/sage/sage-5.6.beta2/local/lib/libpolybori_groebner-0.8.2.so.0(_ZN8polybori8groebner19MinimalLeadingTerms7cleanupERKNS_13BooleMonomialE+0x69)[0x7ffcbef58319]
/home/jp/boulot/sage/sage-5.6.beta2/local/lib/libpolybori_groebner-0.8.2.so.0(_ZN8polybori8groebner19MinimalLeadingTerms6updateERKNS_13BooleMonomialE+0x47)[0x7ffcbef58677]
/home/jp/boulot/sage/sage-5.6.beta2/local/lib/libpolybori_groebner-0.8.2.so.0(_ZN8polybori8groebner17ReductionStrategy19setupSetsForElementERKNS0_9PolyEntryE+0x61)[0x7ffcbef57031]
/home/jp/boulot/sage/sage-5.6.beta2/local/lib/libpolybori_groebner-0.8.2.so.0(_ZN8polybori8groebner12FGLMStrategyC2ERKNS_13BoolePolyRingES4_RKSt6vectorINS_15BoolePolynomialESaIS6_EE+0x513)[0x7ffcbef20a03]
/home/jp/boulot/sage/sage-5.6.beta2/local/lib/python2.7/site-packages/sage/rings/polynomial/pbori.so(_ZN10WrappedPtrIN8polybori8groebner12FGLMStrategyEEC1INS0_13BoolePolyRingES5_St6vectorINS0_15BoolePolynomialESaIS7_EEEERKT_RKT0_RKT1_+0x3f)[0x7ffcbf85665d]
/home/jp/boulot/sage/sage-5.6.beta2/local/lib/python2.7/site-packages/sage/rings/polynomial/pbori.so(+0x11c33e)[0x7ffcbf7fa33e]
/home/jp/boulot/sage/sage-5.6.beta2/local/lib/python2.7/site-packages/sage/rings/polynomial/pbori.so(+0x11b4fc)[0x7ffcbf7f94fc]
/home/jp/boulot/sage/sage-5.6.beta2/local/lib/libpython2.7.so.1.0(+0xe0657)[0x7ffce4937657]
/home/jp/boulot/sage/sage-5.6.beta2/local/lib/libpython2.7.so.1.0(PyObject_Call+0x7f)[0x7ffce48a92c1]
/home/jp/boulot/sage/sage-5.6.beta2/local/lib/libpython2.7.so.1.0(+0x15b7ad)[0x7ffce49b27ad]
/home/jp/boulot/sage/sage-5.6.beta2/local/lib/libpython2.7.so.1.0(+0x15aae5)[0x7ffce49b1ae5]
/home/jp/boulot/sage/sage-5.6.beta2/local/lib/libpython2.7.so.1.0(PyEval_EvalFrameEx+0x7c67)[0x7ffce49ac3cc]
/home/jp/boulot/sage/sage-5.6.beta2/local/lib/libpython2.7.so.1.0(PyEval_EvalCodeEx+0x111c)[0x7ffce49aee02]
/home/jp/boulot/sage/sage-5.6.beta2/local/lib/libpython2.7.so.1.0(PyEval_EvalCode+0x5a)[0x7ffce49a4744]
/home/jp/boulot/sage/sage-5.6.beta2/local/lib/libpython2.7.so.1.0(+0x15d3e6)[0x7ffce49b43e6]
/home/jp/boulot/sage/sage-5.6.beta2/local/lib/libpython2.7.so.1.0(PyEval_EvalFrameEx+0x43c0)[0x7ffce49a8b25]
/home/jp/boulot/sage/sage-5.6.beta2/local/lib/libpython2.7.so.1.0(PyEval_EvalCodeEx+0x111c)[0x7ffce49aee02]
/home/jp/boulot/sage/sage-5.6.beta2/local/lib/libpython2.7.so.1.0(+0x15af0e)[0x7ffce49b1f0e]
/home/jp/boulot/sage/sage-5.6.beta2/local/lib/libpython2.7.so.1.0(+0x15aac9)[0x7ffce49b1ac9]
/home/jp/boulot/sage/sage-5.6.beta2/local/lib/libpython2.7.so.1.0(PyEval_EvalFrameEx+0x7c67)[0x7ffce49ac3cc]
/home/jp/boulot/sage/sage-5.6.beta2/local/lib/libpython2.7.so.1.0(PyEval_EvalCodeEx+0x111c)[0x7ffce49aee02]
/home/jp/boulot/sage/sage-5.6.beta2/local/lib/libpython2.7.so.1.0(+0x15af0e)[0x7ffce49b1f0e]
/home/jp/boulot/sage/sage-5.6.beta2/local/lib/libpython2.7.so.1.0(+0x15aac9)[0x7ffce49b1ac9]
/home/jp/boulot/sage/sage-5.6.beta2/local/lib/libpython2.7.so.1.0(PyEval_EvalFrameEx+0x7c67)[0x7ffce49ac3cc]
/home/jp/boulot/sage/sage-5.6.beta2/local/lib/libpython2.7.so.1.0(+0x15ade3)[0x7ffce49b1de3]
/home/jp/boulot/sage/sage-5.6.beta2/local/lib/libpython2.7.so.1.0(+0x15aac9)[0x7ffce49b1ac9]
/home/jp/boulot/sage/sage-5.6.beta2/local/lib/libpython2.7.so.1.0(PyEval_EvalFrameEx+0x7c67)[0x7ffce49ac3cc]
/home/jp/boulot/sage/sage-5.6.beta2/local/lib/libpython2.7.so.1.0(PyEval_EvalCodeEx+0x111c)[0x7ffce49aee02]
/home/jp/boulot/sage/sage-5.6.beta2/local/lib/libpython2.7.so.1.0(+0x15af0e)[0x7ffce49b1f0e]
/home/jp/boulot/sage/sage-5.6.beta2/local/lib/libpython2.7.so.1.0(+0x15aac9)[0x7ffce49b1ac9]
/home/jp/boulot/sage/sage-5.6.beta2/local/lib/libpython2.7.so.1.0(PyEval_EvalFrameEx+0x7c67)[0x7ffce49ac3cc]
/home/jp/boulot/sage/sage-5.6.beta2/local/lib/libpython2.7.so.1.0(PyEval_EvalCodeEx+0x111c)[0x7ffce49aee02]
/home/jp/boulot/sage/sage-5.6.beta2/local/lib/libpython2.7.so.1.0(+0x15af0e)[0x7ffce49b1f0e]
/home/jp/boulot/sage/sage-5.6.beta2/local/lib/libpython2.7.so.1.0(+0x15aac9)[0x7ffce49b1ac9]
/home/jp/boulot/sage/sage-5.6.beta2/local/lib/libpython2.7.so.1.0(PyEval_EvalFrameEx+0x7c67)[0x7ffce49ac3cc]
/home/jp/boulot/sage/sage-5.6.beta2/local/lib/libpython2.7.so.1.0(PyEval_EvalCodeEx+0x111c)[0x7ffce49aee02]
/home/jp/boulot/sage/sage-5.6.beta2/local/lib/libpython2.7.so.1.0(+0x15af0e)[0x7ffce49b1f0e]
/home/jp/boulot/sage/sage-5.6.beta2/local/lib/libpython2.7.so.1.0(+0x15aac9)[0x7ffce49b1ac9]
/home/jp/boulot/sage/sage-5.6.beta2/local/lib/libpython2.7.so.1.0(PyEval_EvalFrameEx+0x7c67)[0x7ffce49ac3cc]
/home/jp/boulot/sage/sage-5.6.beta2/local/lib/libpython2.7.so.1.0(PyEval_EvalCodeEx+0x111c)[0x7ffce49aee02]
/home/jp/boulot/sage/sage-5.6.beta2/local/lib/libpython2.7.so.1.0(PyEval_EvalCode+0x5a)[0x7ffce49a4744]
/home/jp/boulot/sage/sage-5.6.beta2/local/lib/libpython2.7.so.1.0(+0x18bd81)[0x7ffce49e2d81]
/home/jp/boulot/sage/sage-5.6.beta2/local/lib/libpython2.7.so.1.0(PyRun_FileExFlags+0xbf)[0x7ffce49e2d07]
/home/jp/boulot/sage/sage-5.6.beta2/local/lib/libpython2.7.so.1.0(PyRun_SimpleFileExFlags+0x2be)[0x7ffce49e1504]
/home/jp/boulot/sage/sage-5.6.beta2/local/lib/libpython2.7.so.1.0(PyRun_AnyFileExFlags+0x88)[0x7ffce49e0b62]
/home/jp/boulot/sage/sage-5.6.beta2/local/lib/libpython2.7.so.1.0(Py_Main+0xd29)[0x7ffce49fcb76]
python(main+0x20)[0x40085c]
/lib/x86_64-linux-gnu/libc.so.6(__libc_start_main+0xed)[0x7ffce3bb36ad]
python[0x400779]

------------------------------------------------------------------------
Unhandled SIGABRT: An abort() occurred in Sage.
This probably occurred because a *compiled* component of Sage has a bug
in it and is not properly wrapped with sig_on(), sig_off(). You might
want to run Sage under gdb with 'sage -gdb' to debug this.
Sage will now terminate.
------------------------------------------------------------------------
/home/jp/boulot/sage/sage-5.6.beta2/spkg/bin/sage : ligne 310 : 29842 Abandon                 sage-ipython "$@" -i

wich seems better but should be caught properly if needed.

I'm not really aware of what the above code should do, so my attempt may be completely senseless (although I feel Sage should not crash in this case neither).

comment:6 follow-up: Changed 7 years ago by jpflori

But the following which looks a little better seems to work:

sage: sage: from polybori import *
sage: sage: B.<x,y,z> = BooleanPolynomialRing(order='lex')
sage: C = B.clone(ordering=dp_asc)
sage: sage: ideal = BooleanPolynomialVector([x+z, y+z])
sage: sage: sage: FGLMStrategy(B, C, ideal)
<sage.rings.polynomial.pbori.FGLMStrategy object at 0x7379ab0>

comment:7 in reply to: ↑ 6 Changed 7 years ago by SimonKing

We want that old_ring is in degneglex ordering. Shouldn't the following work

sage: from polybori import *
sage: target_ring = BooleanPolynomialRing(names=['x','y','z'])
sage: source_ring.<x,y,z> = BooleanPolynomialRing(order="DegNegLex")
sage: ideal = BooleanPolynomialVector([x+z, y+z])
sage: z > y > x
True
sage: FGLMStrategy(source_ring, target_ring, ideal)

However, it still crashes!

Replying to jpflori:

But the following which looks a little better seems to work:

sage: sage: from polybori import *
sage: sage: B.<x,y,z> = BooleanPolynomialRing(order='lex')
sage: C = B.clone(ordering=dp_asc)
sage: sage: ideal = BooleanPolynomialVector([x+z, y+z])
sage: sage: sage: FGLMStrategy(B, C, ideal)
<sage.rings.polynomial.pbori.FGLMStrategy object at 0x7379ab0>

I can confirm that this works. However, big surprise:

The following very similar attempt still crashes:

sage: from polybori import *
sage: target_ring = BooleanPolynomialRing(3,names=['x','y','z'])
sage: source_ring = target_ring.clone(ordering=dp_asc)
sage: x,y,z = source_ring.gens()
sage: z > y > x
True
sage: ideal = BooleanPolynomialVector([x+z, y+z])
sage: FGLMStrategy(source_ring, target_ring, ideal)
python: groebner/include/polybori/groebner/PolyEntryVector.h:74: virtual void polybori::groebner::PolyEntryVector::append(const polybori::groebner::PolyEntry&): Assertion `m_indices.checked(back().lead) == (size_type)-1' failed.

So, Alexander, it seems that a misuse of ._change_ordering is not the problem. There is a bug, that ought to be fixed.

comment:8 Changed 7 years ago by SimonKing

The difference between my crashing example and Jean-Pierre's non-crashing example is that I test z > y > x. No idea what that means.

comment:9 follow-up: Changed 7 years ago by AlexanderDreyer

I was able to reproduce Simon's example now with plain polybori. The problem is that the input ideal must be a reduced Gröbner basis (fglm does not compute a Groebner basis itself, it just converts). This is what the assertion complains about. But since a user can trigger this, an assertion is probably not the best idea.

I could patch polybori to throw an exception here. What do you think?

comment:10 Changed 7 years ago by AlexanderDreyer

I suggest to

Apply FGLMStrategy_sigon.patch

and use the patched spkg here: http://boxen.math.washington.edu/home/dreyer/spkg/polybori-0.8.2.p0.spkg

comment:11 Changed 7 years ago by AlexanderDreyer

The spkg just applies the following patch:

  • groebner/include/polybori/groebner/PolyEntryVector.h

    a b  
    7171  virtual void append(const PolyEntry& element) {
    7272    m_data.push_back(element);
    7373
    74     PBORI_ASSERT(m_indices.checked(back().lead) == (size_type)-1);
     74#ifndef PBORI_NDEBUG   
     75    if(m_indices.checked(back().lead) != (size_type)-1)
     76      throw std::runtime_error("leading terms not unique when appending to PolyEntryVector");
     77#endif
    7578    m_indices.insert(back(), size() - 1);
    7679  }
    7780

comment:12 Changed 7 years ago by AlexanderDreyer

  • Status changed from new to needs_review

comment:13 Changed 7 years ago by AlexanderDreyer

  • Authors set to AlexanderDreyer

comment:14 in reply to: ↑ 9 ; follow-up: Changed 7 years ago by jpflori

Replying to AlexanderDreyer:

I was able to reproduce Simon's example now with plain polybori. The problem is that the input ideal must be a reduced Gröbner basis (fglm does not compute a Groebner basis itself, it just converts). This is what the assertion complains about. But since a user can trigger this, an assertion is probably not the best idea.

I could patch polybori to throw an exception here. What do you think?

Good idea! Now we have just to make sure that Sage catch the exception (which it did not seem to do in my example at least).

comment:15 in reply to: ↑ 14 Changed 7 years ago by AlexanderDreyer

Replying to jpflori:

I could patch polybori to throw an exception here. What do you think?

Good idea! Now we have just to make sure that Sage catch the exception (which it did not seem to do in my example at least).

Did apply the Sage-library patch, I mentioned above? (And rebuild?)

comment:16 Changed 7 years ago by AlexanderDreyer

Also, perhaps the exception is not thrown at all. This is the case if PBORI_NDEBUG is still set when building polybori. Did you re-install polybori with SAGE_DEBUG=yes in the environment?

Changed 7 years ago by AlexanderDreyer

patch for pbori.pyx

comment:17 Changed 7 years ago by AlexanderDreyer

  • Description modified (diff)

Ah, and of course, we have to fix the broken doctest. So please apply the recent FGLMStrategy_sigon.patch. I've also added an optional - debug doctest for the case above.

Apply FGLMStrategy_sigon.patch

comment:18 Changed 7 years ago by AlexanderDreyer

  • Description modified (diff)

comment:19 Changed 7 years ago by jpflori

Everything looks fine to me except for a spurious .orig file in the patches dir of the spkg.

comment:20 Changed 7 years ago by AlexanderDreyer

Ah, sorry! I fixed that and replaced the spkg above.

comment:21 Changed 7 years ago by jpflori

  • Reviewers set to Jean-Pierre Flori
  • Status changed from needs_review to positive_review

It's fine now.

I think we should also open a follow up ticket to deprecate _change_ordering in Sage.

comment:22 follow-up: Changed 7 years ago by malb

{{{_change_ordering}}} is a private method, i.e., it starts with an underscore. We don't need to deprecate it, we can simply remove it.

comment:23 in reply to: ↑ 22 Changed 7 years ago by AlexanderDreyer

Replying to malb:

{{{_change_ordering}}} is a private method, i.e., it starts with an underscore. We don't need to deprecate it, we can simply remove it.

Should I update the patch, or do we need another ticket?

comment:24 follow-up: Changed 7 years ago by jpflori

I'd say let's do this in another ticket. The issues are related because the bug was discovered in a doctest involving this method, but the fact that method should not be used is different.

But if you prefer to do it here, please do.

comment:25 in reply to: ↑ 24 ; follow-up: Changed 7 years ago by AlexanderDreyer

Replying to jpflori:

But if you prefer to do it here, please do.

No problem, I'd prefer a new ticket, too.

comment:26 in reply to: ↑ 25 Changed 7 years ago by AlexanderDreyer

Replying to AlexanderDreyer:.

No problem, I'd prefer a new ticket, too.

I created #13900 for this purpose.

comment:27 Changed 7 years ago by AlexanderDreyer

Indeed, _change_ordering can simply be removed now (see #13900).

Last edited 7 years ago by AlexanderDreyer (previous) (diff)

comment:28 Changed 7 years ago by jdemeyer

  • Merged in set to sage-5.6.beta3
  • Resolution set to fixed
  • Status changed from positive_review to closed

comment:29 Changed 7 years ago by jdemeyer

  • Authors changed from AlexanderDreyer to Alexander Dreyer
Note: See TracTickets for help on using tickets.