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

Thanks for the answer so far. But now this leads to another issue. What is the best thing to do for programs which use default(primelimit) without the primelimit being set in .gprc? After commenting the line "primelimit = 1G", I get for:

default(primelimit)
500000

Which in turn causes the programs which depend on higher values of primelimit to have good output to end up failing.

Maybe setting primelimit to 436273009? Or, maybe setting what is currently pl=default(primelimit) to pl = 436273009? But then, I wonder what I would need to do if I need to have prime values like prime(10^10) or greater as to make it where it don't take over 5 minutes to calculate one prime?

John W. Nicholson

On Monday, May 26, 2014 5:09 AM, Karim Belabas <Karim.Belabas@math.u-bordeaux.fr> wrote:

* 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]

`