Opened 10 years ago

Closed 9 years ago

Last modified 9 years ago

#6113 closed defect (duplicate)

segfault in division_points and factoring torsion_polynomial

Reported by: ncalexan Owned by:
Priority: major Milestone: sage-duplicate/invalid/wontfix
Component: elliptic curves Keywords: segfault division points torsion polynomial
Cc: jcremona Merged in:
Authors: Reviewers:
Report Upstream: N/A Work issues:
Branch: Commit:
Dependencies: Stopgaps:

Description

John Cremona reports:

In 4.0.alpha0, this causes a segmentation fault:

----------------------------------------------------------------------
| Sage Version 4.0.alpha0, Release Date: 2009-05-15                  |
| Type notebook() for the GUI, and license() for information.        |
----------------------------------------------------------------------
sage: K.<a>=NumberField(x^2-x+22)
sage: w=-13*a-14
sage: E=EllipticCurve([0,0,0,0,-1728*w])
sage: P1 = E.lift_x(-3*a-66)
sage: P2 = E.lift_x((-21*a-93)/4)
sage: P2.division_points(19)

It works fine to do

sage: g = P2.division_points(19, poly_only=True)

which defines a polynomial of degree 361 over Q(sqrt(-87)), but then g.roots() goes Boom.

ncalexan verified this on Mac OS X; it looks like the crash is in an NTL function:

(gdb) bt
#0  0x01293247 in modii ()
#1  0x014278bc in FpX_red ()

Attachments (2)

ProblematicPari.txt (35.1 KB) - added by stankewicz 10 years ago.
A run of identical jobs, one in gp which succeeds and one in sage which results in a SegFault?
nffactorsegfault.txt (10.6 KB) - added by stankewicz 10 years ago.

Download all attachments as: .zip

Change History (14)

comment:1 follow-up: Changed 10 years ago by cremona

Nick, do you know what the roots function is actually doing in this case (univariate poly over a number field)? I think it is calling factor(), but NTL has no support for polynomials over number fields so I thought it must be calling pari after that.

comment:2 in reply to: ↑ 1 Changed 10 years ago by stankewicz

Replying to cremona:

Nick, do you know what the roots function is actually doing in this case (univariate poly over a number field)? I think it is calling factor(), but NTL has no support for polynomials over number fields so I thought it must be calling pari after that.

I recently ran into a similar problem trying to factor over the field generated by the hilbert class polynomial over QQ. For small degree (< 50 or so) it's okay but for larger degree polynomials it gives a segmentation fault with PARI. If there's a way I can help here and get a patch up for this I want to know about it!

comment:3 follow-up: Changed 10 years ago by cremona

If we can come up with an example which fails in gp then it would be easy to send a bug report to the pari developers. It is harder if we can only get the error using the pari library, since then they might want a C program in the report. I think (quite reasonably) that the pari developers cannot be expected to debug things which can only be demonstrated in a Sage run -- even if the use of pari in Sage has increased the number of pari users worldwide by a lot!

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

Replying to cremona:

If we can come up with an example which fails in gp then it would be easy to send a bug report to the pari developers. It is harder if we can only get the error using the pari library, since then they might want a C program in the report. I think (quite reasonably) that the pari developers cannot be expected to debug things which can only be demonstrated in a Sage run -- even if the use of pari in Sage has increased the number of pari users worldwide by a lot!

Well, I ran it on gp and it worked just fine. The results are included in the text file I've attached along with the same example failing in sage. When I -gdb it I get pointed to /usr/local/sage/local/LIB/libpari-gmp.so.2

That in addition to the fact that the code for factoring a univariate polynomial over a number field appears to essentially consist of "make PARI do it" is why it appeared that PARI was causing the SegFault?.

Changed 10 years ago by stankewicz

A run of identical jobs, one in gp which succeeds and one in sage which results in a SegFault?

Changed 10 years ago by stankewicz

comment:5 in reply to: ↑ 4 ; follow-up: Changed 10 years ago by stankewicz

Replying to stankewicz:

Ah ha!. The problem is nonexistent with factornf, but that uses a different algorithm than nffactor, which is the pari command that sage uses for factoring. This is indeed a problem with Pari and will be reported.

Would it be possible to call factornf through gp and pull the factorization back to sage?

comment:6 in reply to: ↑ 5 Changed 10 years ago by stankewicz

http://pari.math.u-bordeaux.fr/cgi-bin/bugreport.cgi?bug=979

At the next upgrade of PARI this problem should be fixed(it's already fixed in the unstable version).

comment:7 Changed 10 years ago by davidloeffler

  • Component changed from number theory to elliptic curves
  • Owner changed from was to davidloeffler

comment:8 Changed 10 years ago by davidloeffler

  • Owner changed from davidloeffler to (none)

comment:9 follow-up: Changed 10 years ago by cremona

  • Report Upstream set to N/A

This probably has the same cause as #7097: see the comments there. I am going to check if the patch I put up there works here too.

comment:10 in reply to: ↑ 9 Changed 10 years ago by cremona

Replying to cremona:

This probably has the same cause as #7097: see the comments there. I am going to check if the patch I put up there works here too.

It does not...

comment:11 Changed 9 years ago by cremona

  • Resolution set to fixed
  • Status changed from new to closed

In 4.6.alpha1:

sage: K.<a>=NumberField(x^2-x+22)
sage: sage: w=-13*a-14
sage: sage: E=EllipticCurve([0,0,0,0,-1728*w])
sage: sage: P1 = E.lift_x(-3*a-66)
sage: sage: P2 = E.lift_x((-21*a-93)/4)
sage: sage: P2.division_points(19)
[]
sage: g = P2.division_points(19, poly_only=True)
sage: g.roots()
[]

so this can be closed as fixed.

comment:12 Changed 9 years ago by mpatel

  • Milestone changed from sage-4.6 to sage-duplicate/invalid/wontfix
  • Resolution changed from fixed to duplicate
Note: See TracTickets for help on using tickets.