LLR development version 3.8.7 is available!

[rogue]

Originally Posted by Thomas11

The source code of LLR 3.8.7 still uses gwnum 26.5.
There are other people around who (successfully?) replaced the gwnums by version 27.2, but I just compiled the source without any modifications.

I could probably find it and provide a fix the Jean or I can give him the memory leak code so that he can find all memory leaks in llr.

[Jean Penné]

Hello,

I fixed this bug today (indeed, it was due to missing frees)
and updated the four binaries and the source in my Development directory accordingly.

Thank you for your help and Best Regards,
Jean

[Thomas11]

Sorry, Jean, but this problem seems to persist - at least for the Linux binaries (32 and 64 bits):
After about 15 hours the memory utilization has increased from 12MB to 250MB per core.
I also double-checked that I actually used the new (fixed) binary.

Note, that I'm testing Generalized Cullen/Woodall numbers, e.g. non-base-2 tests. Maybe this is a different code path.

[Jean Penné]

Originally Posted by Thomas11

Sorry, Jean, but this problem seems to persist - at least for the Linux binaries (32 and 64 bits):
After about 15 hours the memory utilization has increased from 12MB to 250MB per core.
I also double-checked that I actually used the new (fixed) binary.

Note, that I'm testing Generalized Cullen/Woodall numbers, e.g. non-base-2 tests. Maybe this is a different code path.

That is surprising : I am presently testing on a 32 bit Linux system, whith a file
containing all archived Generalized Fermat primes, so varied non-two bases, and the memory usage remains stable (I am looking at with top)...
Yes, the bug concerned only non base two tests!
Are you absolutely sure you are now using the fixed binaries?
Regards,
Jean

[Thomas11]

Originally Posted by Jean Penné

Are you absolutely sure you are now using the fixed binaries?

Yes, file size and date of the 32bit binary is:
26477210 2012-02-11 18:51

Here is some part of a typical input file I'm using:

ABC $a*$b^$c$d   // base 209
12002 209 12002 -1
12032 209 12032 -1
12054 209 12054 -1
12080 209 12080 -1
12128 209 12128 -1

[Thomas11]

Meanwhile I tested the Windows binary (32bit) and it shows the same behavior, e.g. for the input file given above the memory usage increases as: 2.8MB -> 3.6MB -> 4.4MB -> 5.4MB -> 6.5MB.

Added: file size and time stamp are: 26390528 02-11-12 18:15 LLR.exe

[Jean Penné]

Originally Posted by Thomas11

Meanwhile I tested the Windows binary (32bit) and it shows the same behavior, e.g. for the input file given above the memory usage increases as: 2.8MB -> 3.6MB -> 4.4MB -> 5.4MB -> 6.5MB.

Added: file size and time stamp are: 26390528 02-11-12 18:15 LLR.exe

You are right, Thomas, there was a second missing of free! It affected only non-prime candidates! I think it is now fixed, but I think also that previous versions of LLR have this problem for non base two tests...

Thank you for your help and best regards,
Jean

[Thomas11]

Thanks, Jean, for spending your Sunday on this problem!
I'm already testing the 32bit binary and it seems to work fine now.

Regarding older versions of LLR:
I used LLR 3.8.6 for about 3 months on Generalized Cullen/Woodall numbers, and some clients were running for weeks without interruption. But there was never any indication of memory leakage.

Kind regards,

Thomas

[Jean Penné]

Originally Posted by Thomas11

Thanks, Jean, for spending your Sunday on this problem!
I'm already testing the 32bit binary and it seems to work fine now.

Regarding older versions of LLR:
I used LLR 3.8.6 for about 3 months on Generalized Cullen/Woodall numbers, and some clients were running for weeks without interruption. But there was never any indication of memory leakage.

Kind regards,

Thomas

Hi Thomas,
I did not spend all my Sunday on that, fortunately!
You are right, the V3.8.6 has not the bug, but the V3.8.6dev seems to have the bug! But it is now obsolete, so I left it unchanged...
Thank you for all your help, and best regards,
Jean

[AG5BPilot]

Jean,

I built a 64 bit Windows version, but one user is getting the following error on both the 32 and 64 bit versions:

Tested the 64 bit version with Win7 on an E350 processor.

llr Test>cllr -q"3117*2^314958+1" -d
Fatal error at setup : Number sent to gwsetup is too large for the FFTs to handle.

side note: the llr version supplied with the prpclient 5.0.5 produces the same error.

That's from the PrimeGrid boards.

He subsequently stated he also has the problem with the 3.8.6 (32 bit) build, but that the AVX build does work. What's most interesting about this is that his CPU doesn't have AVX.

[Jean Penné]

Originally Posted by AG5BPilot

Jean,

I built a 64 bit Windows version, but one user is getting the following error on both the 32 and 64 bit versions:



That's from the PrimeGrid boards.

He subsequently stated he also has the problem with the 3.8.6 (32 bit) build, but that the AVX build does work. What's most interesting about this is that his CPU doesn't have AVX.

The problem is that I cannot reproduce this error :
I passed this test on a P4/Windows 2000, an AMD/Linux, an Intel core2/windows Vista and obtained the same result :
I:\D\Jean\LLR\llr387dev>cllr -q"3117*2^314958+1" -d
Starting Proth prime test of 3117*2^314958+1
Using all-complex Pentium4 type-1 FFT length 24K, Pass1=96, Pass2=256, a = 7
3117*2^314958+1 is not prime. Proth RES64: 4E6DB6FACE0861F5 Time : 340.530 sec.

I have no 64bit machine...
Is the LLR you are using built with the gwnum library V27.2 ? If yes, it may be the cause of your problem...
Regards,
Jean