Your message dated Tue, 20 Oct 2020 17:01:51 +0200
with message-id <20201020150151.GA28280@yellowpig>
and subject line Re: Bug#948475: GP stuck when parisize is too high on armel
and a few others
has caused the Debian Bug report #948475,
regarding GP stuck when parisize is too high on armel and a few others
to be marked as done.
This means that you claim that the problem has been dealt with.
If this is not the case it is now your responsibility to reopen the
Bug report if necessary, and/or fix the problem forthwith.
(NB: If you are a system administrator and have no idea what this
message is talking about, this may indicate a serious mail system
misconfiguration somewhere. Please contact [email protected]
immediately.)
--
948475: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=948475
Debian Bug Tracking System
Contact [email protected] with problems
--- Begin Message ---
Package: pari-gp
Version: 2.11.2-1
When starting with a big parisize on armel (and armhf, mipsel and
powerpc, if I remember well), gp can get stuck on simple computations :
parisize = 1000000000, primelimit = 500000, nbthreads = 4
? isprime(293911884200387681576093)
*** isprime: Warning: not enough memory, new thread stack 500002816
*** isprime: Warning: not enough memory, new thread stack 250003456
*** isprime: Warning: not enough memory, new thread stack 125001728
*** isprime: Warning: not enough memory, new thread stack 500002816
*** isprime: Warning: not enough memory, new thread stack 250003456
*** isprime: Warning: not enough memory, new thread stack 125001728
*** isprime: Warning: not enough memory, new thread stack 62500864
*** isprime: Warning: not enough memory, new thread stack 31252480
*** isprime: Warning: not enough memory, new thread stack 15626240
(and there you have to kill gp or it never ends)
where the default gives :
parisize = 4000000, primelimit = 500000, nbthreads = 4
? isprime(293911884200387681576093)
%1 = 1
Of course, the problem arised in eclib and that's where it will be
patched, but the fact that pari broke on some arches is - as far as I
can tell - still an indication something isn't correct in the code : it
used to work, and doesn't anymore.
Happy new year,
JP
--- End Message ---
--- Begin Message ---
On Tue, Jan 14, 2020 at 06:18:11PM +0100, Bill Allombert wrote:
> On Fri, Jan 10, 2020 at 04:55:54PM +0100, Julien Puydt wrote:
> > Le jeudi 09 janvier 2020 à 12:17 +0100, Bill Allombert a écrit :
> > > Maybe the problem is just that the number of cores has increased.
> > >
> > > PARI require that parisizemax + threadsizemax * nbthreads fit in the
> > > virtual memory.
> > >
> > > On 32bit system, there is about 3G of virtual memory,
> > > so if you want to set a large threadsizemax, you need to limit the
> > > number of threads.
> > >
> >
> > Yes, but my point is that if there's a memory problem, there should be
> > a proper crash, not an infinite wait.
>
> What you should do is disable parallelism on 32bit plateforms or
> compute a suitable value for threadsizemax instead of relying on
> PARI recovery code.
>
> The PARI/GP virtual memory allocator manages to allocate nearly all the
> available virtual memory.
> At this point the pthread library start to misbehave and wait for
> some virtual memory to be freed, which will never happen.
>
> If you do in GP
>
> default(threadsizemax, "100M")
> isprime(293911884200387681576093)
> default(threadsizemax, "1G")
> isprime(293911884200387681576093)
>
> Then it works, because the pthread library gets a chance to allocate
> some vm memory for itself before PARI grabs the rest.
>
> Since PARI allocates virtual memory to threads in order,
> If the system has a bit less than 2GB of free vm and threadsizemax
> is set to 1GB, then
> - thread 1 get 1GB
> - thread 2 get only 512MB
> - thread 3 get only 256MB
> - thread 4 get only 128MB
> etc.
> which converge rather quickly to 2GB of use.
Accordingly I close this bug report.
Cheers,
--
Bill. <[email protected]>
Imagine a large red swirl here.
--- End Message ---
