Re: bug in PARI/GP (Segmentation Fault), please report.

[Karim Belabas <Karim.Belabas@math.u-bordeaux.fr>]

* Bill Allombert [2014-05-26 11:19]:
> > n=2;while(ln(prime(n))>ln(prime(n+1))/exp(1/(n))&&n<pl,n++);print(n)
> >   ***   at top-level: ...=2;while(ln(prime(n))>ln(prime(n+1))/exp(1/(n
> >   ***                                             ^--------------------
> >   *** prime: bug in PARI/GP (Segmentation Fault), please report.
> >   ***   Break loop: type 'break' to go back to GP prompt
> > break> n
> > 23163299
> > break> 
> > 
> > Is this a bug on my machine, or can it be reproduced by others? Has this been reported before?
> 
> We managed to reproduce it:
> ./gp  -f -p1000000000
> ? n=23163299;N = n + 1;while(log(prime(n))>log(prime(n+1))/exp(1/(n))&&n<N,n++);
>   ***   at top-level: ...;while(log(prime(n))>log(prime(n+1))/exp(1/(n
>   ***                                             ^--------------------
>   *** prime: bug in PARI/GP (Segmentation Fault), please report.
>   ***   Break loop: type 'break' to go back to GP prompt
> 
> 
> However, using -p1000000000 is not needed anyore with PARI 2.7, thus you can omit
> it to avoid this bug.

Even simpler

  ./gp -f -p1000000000
  ? prime(23163299+1)  ==> SEGV


Needed primes are now produced dynamically (very fast up to the *square*
of primelimit) and there is no need to precompute huge lists of primes.
In fact, the internal table is limited to p <= 436273009, the 23163299-th prime
(default p <= 499979, i.e. fast primes up to ~2.5Ε11)

There was a bug while restricting the requested 1000000000 to this limit
(a kind of off-by-1 error), creating an incorrect prime table with a
discrepancy between the largest prime it actually contained (436273009)
and the one reported by maxprime (436273291). "Overflowing" the table
and starting to generate primes dynamically would then cause a crash in
certain situations.

As Bill said, abstaining from (uselessly) trying to generate a large table
of primes, also prevents the problem [ don't use -p, and look for primelimit=...
in your gprc ]. The bug is now fixed in 'master'.

Thanks for your report !

Cheers,

    K.B.
--
Karim Belabas, IMB (UMR 5251)  Tel: (+33) (0)5 40 00 26 17
Universite Bordeaux 1          Fax: (+33) (0)5 40 00 69 50
351, cours de la Liberation    http://www.math.u-bordeaux1.fr/~kbelabas/
F-33405 Talence (France)       http://pari.math.u-bordeaux1.fr/  [PARI/GP]
`