Opened 3 years ago

Last modified 3 years ago

#21624 needs_work defect

Better debug mode for singular 4

Reported by: jpflori Owned by:
Priority: major Milestone: sage-duplicate/invalid/wontfix
Component: packages: standard Keywords:
Cc: embray Merged in:
Authors: Reviewers:
Report Upstream: N/A Work issues:
Branch: Commit:
Dependencies: Stopgaps:

Description (last modified by jpflori)

This is a follow up to #17254 which upgraded to singular 4:

  • debug (with xalloc) build on OS X (om_Info gets undefined (U) in Singular, note that it is ok on linux (B), maybe depends on ocmpiler, linker vesions)
  • failing test in debug mode

Change History (30)

comment:1 Changed 3 years ago by jpflori

  • Description modified (diff)

comment:2 follow-up: Changed 3 years ago by vbraun

24524sage -t --long src/sage/algebras/free_algebra.py  # 4 doctests failed
24525sage -t --long src/sage/algebras/letterplace/free_algebra_element_letterplace.pyx  # 6 doctests failed
24526sage -t --long src/sage/algebras/letterplace/free_algebra_letterplace.pyx  # 2 doctests failed
24527sage -t --long src/sage/algebras/letterplace/letterplace_ideal.pyx  # 10 doctests failed
24528sage -t --long src/sage/rings/quotient_ring.py  # 18 doctests failed
24529sage -t --long src/sage/rings/quotient_ring_element.py  # 1 doctest failed
24530sage -t --long src/sage/schemes/curves/constructor.py  # 1 doctest failed

comment:3 Changed 3 years ago by jdemeyer

  • Priority changed from major to blocker
  • Type changed from enhancement to defect

comment:4 in reply to: ↑ 2 ; follow-up: Changed 3 years ago by jpflori

All of these errors look like:

    // ***dPolyReportError: NULL coef 
     occurred at
     occurred for poly: o*x*y*x_1*y_1*x_2
    // ***dPolyReportError: NULL coef 
     occurred at
     occurred for poly: o*y*x_1*y_1*x_2
    // ***dError: S_2_R[2]=1 != T[1].i_r=0
    -y*z*x - y*z*y - y*z*z

except for the last one:

File "src/sage/schemes/curves/constructor.py", line 108, in sage.schemes.curves.constructor.Curve
Failed example:
    C.genus()
Expected:
    13
Got:
    // ** no minpoly allowed if there are local objects belonging to the basering: 
    number((a2+a+1))
    // ** killing a local object due to minpoly change: p
    // ** no minpoly allowed if there are local objects belonging to the basering: 
    number((a2-a+1))
    // ** killing a local object due to minpoly change: p
    13

24528sage -t --long src/sage/rings/quotient_ring.py # 18 doctests failed 24529sage -t --long src/sage/rings/quotient_ring_element.py # 1 doctest failed 24530sage -t --long src/sage/schemes/curves/constructor.py # 1 doctest failed }}}

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

With #21631 there are now also many

 // ***dError: assume violation at numbers.cc:426 condition: n->cfCoeffName!=ndCoeffName

warnings, though no crashes.

comment:8 Changed 3 years ago by jpflori

Can you tell in which file it is?

comment:9 Changed 3 years ago by jpflori

Ok, got it.

comment:10 Changed 3 years ago by jpflori

See ##21865 for new errors occurring only in debug mode in:

  • sage/rings/cfinite_sequence.py
  • sage/matrix/matrix_modn_dense_template.pxi
Last edited 3 years ago by jpflori (previous) (diff)

comment:11 in reply to: ↑ 4 ; follow-up: Changed 3 years ago by jakobkroeker

the last issue ( "no minpoly allowed..") can be fixed with

https://github.com/Singular/Sources/pull/814 (avoids intermediate object between ring declaration and minpoly definition in 'normal.lib')

Did you get answers from Hans for the other issues? Or, could you track them down?

Replying to jpflori:

All of these errors look like:

    // ***dPolyReportError: NULL coef 
     occurred at
     occurred for poly: o*x*y*x_1*y_1*x_2
    // ***dPolyReportError: NULL coef 
     occurred at
     occurred for poly: o*y*x_1*y_1*x_2
    // ***dError: S_2_R[2]=1 != T[1].i_r=0
    -y*z*x - y*z*y - y*z*z

except for the last one:

File "src/sage/schemes/curves/constructor.py", line 108, in sage.schemes.curves.constructor.Curve
Failed example:
    C.genus()
Expected:
    13
Got:
    // ** no minpoly allowed if there are local objects belonging to the basering: 
    number((a2+a+1))
    // ** killing a local object due to minpoly change: p
    // ** no minpoly allowed if there are local objects belonging to the basering: 
    number((a2-a+1))
    // ** killing a local object due to minpoly change: p
    13

24528sage -t --long src/sage/rings/quotient_ring.py # 18 doctests failed 24529sage -t --long src/sage/rings/quotient_ring_element.py # 1 doctest failed 24530sage -t --long src/sage/schemes/curves/constructor.py # 1 doctest failed }}}

comment:12 in reply to: ↑ 7 ; follow-up: Changed 3 years ago by jakobkroeker

Replying to vbraun:

With #21631 there are now also many

 // ***dError: assume violation at numbers.cc:426 condition: n->cfCoeffName!=ndCoeffName

warnings, though no crashes.

so changes in #21631 introduced a new issue? Could someone track it down?

comment:13 in reply to: ↑ 12 Changed 3 years ago by jpflori

Replying to jakobkroeker:

Replying to vbraun:

With #21631 there are now also many

 // ***dError: assume violation at numbers.cc:426 condition: n->cfCoeffName!=ndCoeffName

warnings, though no crashes.

so changes in #21631 introduced a new issue? Could someone track it down?

This has been fixed in Singular git version.

comment:14 in reply to: ↑ 11 ; follow-ups: Changed 3 years ago by jpflori

Replying to jakobkroeker:

the last issue ( "no minpoly allowed..") can be fixed with

https://github.com/Singular/Sources/pull/814 (avoids intermediate object between ring declaration and minpoly definition in 'normal.lib')

Good! It's even in Singular's git version now.

Did you get answers from Hans for the other issues? Or, could you track them down?

Replying to jpflori:

All of these errors look like:

     occurred at
     occurred for poly: o*y*x_1*y_1*x_2
    // ***dError: S_2_R[2]=1 != T[1].i_r=0
    -y*z*x - y*z*y - y*z*z

Those like this were still present last time I checked and those about stuff not being where it belongs through kTest_L and kTest_TS as mentioned here:

No feedback from Hans and I had no time to look at it.

comment:15 in reply to: ↑ 14 Changed 3 years ago by jakobkroeker

I just reminded Hans kindly to look at that issue since it is a blocker ticket for sage.

https://groups.google.com/forum/#!msg/libsingular-devel/TPZNlvZXei0/CptSq0fdAgAJ

Let's see if something happens.

Replying to jpflori:

Replying to jakobkroeker:

the last issue ( "no minpoly allowed..") can be fixed with

https://github.com/Singular/Sources/pull/814 (avoids intermediate object between ring declaration and minpoly definition in 'normal.lib')

Good! It's even in Singular's git version now.

Did you get answers from Hans for the other issues? Or, could you track them down?

Replying to jpflori:

All of these errors look like:

     occurred at
     occurred for poly: o*y*x_1*y_1*x_2
    // ***dError: S_2_R[2]=1 != T[1].i_r=0
    -y*z*x - y*z*y - y*z*z

Those like this were still present last time I checked and those about stuff not being where it belongs through kTest_L and kTest_TS as mentioned here:

No feedback from Hans and I had no time to look at it.

comment:16 follow-up: Changed 3 years ago by jpflori

With the latest tarball for 4-1-0p2, debug mode should be clean:

comment:17 in reply to: ↑ 16 Changed 3 years ago by jakobkroeker

comment:18 in reply to: ↑ 14 Changed 3 years ago by jakobkroeker

Replying to jpflori:

Replying to jakobkroeker:

the last issue ( "no minpoly allowed..") can be fixed with

https://github.com/Singular/Sources/pull/814 (avoids intermediate object between ring declaration and minpoly definition in 'normal.lib')

Good! It's even in Singular's git version now.

There are much more issues in Singular LIBs where the minpoly is not immediately defined (and lead to debug output) which are probably not hit by current sage tests, but in the long term they have all to be fixed: https://github.com/jakobkroeker/test_singular/issues/243

Last edited 3 years ago by jakobkroeker (previous) (diff)

comment:19 Changed 3 years ago by embray

  • Cc embray added
  • Milestone sage-7.4 deleted
  • Priority changed from blocker to major

I think I'm seeing this too. I almost always compile with SAGE_DEBUG=yes on Cygwin since I have to debug things so often, and I'm seeing lots of failures like this since the switch to Singular 4. Going to recompile Singular in non-debug mode to confirm that it goes away.

(Also obviously this isn't a blocker or it'd be fixed by now :)

comment:20 Changed 3 years ago by embray

Confirmed that rebuilding Singular and its dependents with SAGE_DEBUG=no fixed these failures for me.

comment:21 Changed 3 years ago by jpflori

@eric: does #22425 fixed the errors you saw? I think we can close this one now #22425 is merged.

comment:22 Changed 3 years ago by embray

I don't think I've tried yet. I'll test it and see. Are you saying it should be fixed even with SAGE_DEBUG=yes?

comment:23 Changed 3 years ago by jpflori

All error messages specific to singular built in debug mode should not appear anymore.

comment:24 Changed 3 years ago by jpflori

  • Milestone set to sage-duplicate/invalid/wontfix
  • Status changed from new to needs_review

Should be ok since the latest singular upgrade.

comment:25 Changed 3 years ago by vbraun

  • Status changed from needs_review to needs_work

I'm still getting this one

sage -t --long src/sage/interfaces/singular.py
**********************************************************************
File "src/sage/interfaces/singular.py", line 1523, in sage.interfaces.singular.SingularElement.sage_global_ring
Failed example:
    singular.eval('ring r5 = (complex,15,j),(a,b,c),dp')
Expected:
    ''
Got:
    '\n// ***dError: assume violation at numbers.cc:434 condition: n->cfCoeffName!=ndCoeffName'
**********************************************************************
1 item had failures:
   1 of  22 in sage.interfaces.singular.SingularElement.sage_global_ring
    [390 tests, 1 failure, 10.81 s]

comment:26 Changed 3 years ago by jpflori

Maybe #22868. Did not check debug mode there.

comment:27 Changed 3 years ago by jpflori

Unfortunately the failing test it is still here with 4.1.0p3.

comment:28 Changed 3 years ago by jpflori

Should be fixed in git version:

@volker: do you see any other failures?

comment:29 Changed 3 years ago by vbraun

These look a bit like they might be from Singular, haven't investigated further:

sage -t --long src/sage/rings/polynomial/multi_polynomial_ideal.py
**********************************************************************
File "src/sage/rings/polynomial/multi_polynomial_ideal.py", line 1761, in sage.rings.polynomial.multi_polynomial_ideal.?.interreduced_basis
Failed example:
    Ideal(P(0)).interreduced_basis()
Expected:
    [0]
Got:
    wrong mod p number 140727535500960 at modulop.cc,158
    [0]
**********************************************************************
1 item had failures:
   1 of  13 in sage.rings.polynomial.multi_polynomial_ideal.?.interreduced_basis
    [722 tests, 1 failure, 75.81 s]
sage -t --long src/sage/rings/polynomial/multi_polynomial_sequence.py
**********************************************************************
File "src/sage/rings/polynomial/multi_polynomial_sequence.py", line 1022, in sage.rings.polynomial.multi_polynomial_sequence.PolynomialSequence_generic.reduced
Failed example:
    Sequence([P(0)]).reduced()
Expected:
    [0]
Got:
    wrong mod p number 140727535505680 at modulop.cc,158
    [0]
**********************************************************************
1 item had failures:
   1 of  17 in sage.rings.polynomial.multi_polynomial_sequence.PolynomialSequence_generic.reduced
    [235 tests, 1 failure, 14.47 s]

comment:30 Changed 3 years ago by jpflori

Error messages definitely from Singular, though it might be from bad input on Sage's side.

Note: See TracTickets for help on using tickets.