LLR development version 3.8.7 is available! - Page 3

AG5BPilot · 2012-02-13, 21:24

Quote:

Originally Posted by Jean Penné

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

No, it's built with the same gwnum in your distribution. I can't reproduce the problem either, unfortunately.

paulunderwood · 2012-02-24, 10:10

I am still having fun and games with llr64. In particular, the intermedidiate files cause me problems.

Code:

Linux pc2 2.6.32-5-amd64 #1 SMP Mon Jan 16 16:22:28 UTC 2012 x86_64 GNU/Linux

Here is a llr64 session - note the seg fault:

Code:

	     Main Menu

	 1.  Test/Input Data
	 2.  Test/Continue
	 3.  Test/Exit

	 4.  Options/CPU
	 5.  Options/Preferences
	 6.  Advanced/Priority

	 7.  Help/About
Your choice: 2

Starting Vrba-Reix test of (2^83339+1)/3
^C^83339+1)/3, bit: 30000 / 83338 [35.99%].  Time per bit: 0.123 ms.
 Caught signal.  Terminating.

Hit enter to continue: 
	     Main Menu

	 1.  Test/Input Data
	 2.  Test/Continue
	 3.  Test/Exit

	 4.  Options/CPU
	 5.  Options/Preferences
	 6.  Advanced/Priority

	 7.  Help/About
Your choice: 2

Resuming Vrba-Reix test of (2^83339+1)/3 at bit 37014 [44.41%]
^C^83339+1)/3, bit: 70000 / 83338 [83.99%].  Time per bit: 0.121 ms.
 Caught signal.  Terminating.
Segmentation fault

paulunderwood · 2012-02-24, 10:27

If and only if I have a "z save file" I get this with sllr64:

Code:

 ./sllr64 
*** glibc detected *** ./sllr64: free(): invalid next size (normal): 0x00000000033b8c90 ***
======= Backtrace: =========
[0x1ace6b2]
[0x1ad3207]
[0x43c316]
[0x420d30]
[0x42d0d3]
[0x42f48b]
[0x4312bd]
[0x4316b0]
[0x1abd44e]
[0x400309]
======= Memory map: ========
00400000-01b7f000 r-xp 00000000 08:01 343436                            
 /home/paul/Desktop/test_llr64/sllr64
01d7f000-01d8a000 rwxp 0177f000 08:01 343436                             
/home/paul/Desktop/test_llr64/sllr64
01d8a000-01db2000 rwxp 00000000 00:00 0 
0339c000-0342b000 rwxp 00000000 00:00 0                                  
[heap]
7fb90c000000-7fb90c021000 rwxp 00000000 00:00 0 
7fb90c021000-7fb910000000 ---p 00000000 00:00 0 
7fb91262b000-7fb91264f000 rwxp 00000000 00:00 0 
7fff780cc000-7fff780f3000 rwxp 00000000 00:00 0                          
[stack]
7fff781ff000-7fff78200000 r-xp 00000000 00:00 0                          
[vdso]
ffffffffff600000-ffffffffff601000 r-xp 00000000 00:00 0                  
[vsyscall]
Aborted

I will download and try the very latest instance of this package and try it....
I just tried the very latest and the problem is still there for me.

Jean Penné · 2012-03-16, 18:24

Hi All,

I released today the 32bit binaries of LLR 3.8.8 on my development directory :

http://jpenne.free.fr/Development/

The only difference with LLR 3.8.7 is these binaries are linked with version 27.5 of gwnum library, although 3.8.7 ones are linked with version 26.5

Moreover, cllrd binary is linked with the debug library gwnumd.lib which detects internal errors such as failing asserts, and then abort the processing.

Please consult the Readme file for details.

Best Regards,
Jean

Jean Penné · 2012-03-16, 18:30

Hi All,

I released on my Development directory a special debugging version of LLR 3.8.7 ;
As all LLR 3.8.7 versions released on my site, it is linked with version 26.5 of the gwnum library.
but there, the gwnum.c file is slightly modified, so the result of (m == 45) assertion is registered in a global variable.
As I wrote in the Readme file :
The main purpose of this program is to help users for the recovery of
possibly false results obtained while using gwnum V26 linked prime testing
programs on some machines such as core duo T6300 or T6400.
This program detects "m == 45" errors at setup time, and then, does not
process the number further...
Also, by using the -oTestm45=1 option, it can be used as a tool to record
in the output file, the candidates that trigger this error, while ignoring
the others ; with this option set, only the setup is done for each candidate.
The names of the relevant compressed files follow :

cllr387debugv6.zip, Windows console application.
llr387debugv26linux.zip, Linux application, dynamic link.
llr387debugv26slinux.zip, Linux application, static link.
llr387debugv26src.zip, Complete source directory.

If you need to build a Mac Os executable, you may have to
modify some makefiles... Then be sure to compile Llr.c with "tm45" defined,
by setting the relevant preprocessor option -Dtm45.
I hope it will help...

Best Regards,
Jean

Jean Penné · 2012-03-23, 19:54

Quote:

Originally Posted by Jean Penné

Hi All,

I released today the 32bit binaries of LLR 3.8.8 on my development directory :

http://jpenne.free.fr/Development/

The only difference with LLR 3.8.7 is these binaries are linked with version 27.5 of gwnum library, although 3.8.7 ones are linked with version 26.5

Moreover, cllrd binary is linked with the debug library gwnumd.lib which detects internal errors such as failing asserts, and then abort the processing.

Please consult the Readme file for details.

Best Regards,
Jean

The 32 and 64bit Mac OS binaries,
the 64bit Windows and Linux binaries are also available now at this address.
Regards,
Jean

paulunderwood · 2012-03-23, 20:43

I still get a segmentation fault with both llr64 and sllr64

Code:

$uname -a
Linux box2 2.6.32-5-amd64 #1 SMP Mon Jan 16 16:22:28 UTC 2012 x86_64 GNU/Linux

llr64 session (similarly for sllr64):

Code:

	     Main Menu

	 1.  Test/Input Data
	 2.  Test/Continue
	 3.  Test/Exit

	 4.  Options/CPU
	 5.  Options/Preferences
	 6.  Advanced/Priority

	 7.  Help/About
Your choice: 2

Starting Vrba-Reix test of (2^83339+1)/3
^C^83339+1)/3, bit: 40000 / 83338 [47.99%].  Time per bit: 0.074 ms.
 Caught signal.  Terminating.

Hit enter to continue: 
	     Main Menu

	 1.  Test/Input Data
	 2.  Test/Continue
	 3.  Test/Exit

	 4.  Options/CPU
	 5.  Options/Preferences
	 6.  Advanced/Priority

	 7.  Help/About
Your choice: 2

Resuming Vrba-Reix test of (2^83339+1)/3 at bit 40429 [48.51%]
^C^83339+1)/3, bit: 60000 / 83338 [71.99%].  Time per bit: 0.085 ms.
 Caught signal.  Terminating.
Segmentation fault

Jean Penné · 2012-03-29, 09:34

Quote:

Originally Posted by paulunderwood

I still get a segmentation fault with both llr64 and sllr64

Code:

$uname -a
Linux box2 2.6.32-5-amd64 #1 SMP Mon Jan 16 16:22:28 UTC 2012 x86_64 GNU/Linux

llr64 session (similarly for sllr64):

Code:

	     Main Menu

	 1.  Test/Input Data
	 2.  Test/Continue
	 3.  Test/Exit

	 4.  Options/CPU
	 5.  Options/Preferences
	 6.  Advanced/Priority

	 7.  Help/About
Your choice: 2

Starting Vrba-Reix test of (2^83339+1)/3
^C^83339+1)/3, bit: 40000 / 83338 [47.99%].  Time per bit: 0.074 ms.
 Caught signal.  Terminating.

Hit enter to continue: 
	     Main Menu

	 1.  Test/Input Data
	 2.  Test/Continue
	 3.  Test/Exit

	 4.  Options/CPU
	 5.  Options/Preferences
	 6.  Advanced/Priority

	 7.  Help/About
Your choice: 2

Resuming Vrba-Reix test of (2^83339+1)/3 at bit 40429 [48.51%]
^C^83339+1)/3, bit: 60000 / 83338 [71.99%].  Time per bit: 0.085 ms.
 Caught signal.  Terminating.
Segmentation fault

Hi Paul,

I apologize for this late response, but I was unable to reproduce this problem. Now, I have a 64bit machine : an AMD Phenom(tm) II X4 965 Processor, whith Debian Linux AMD64 installed, and I could reproduce it.
It seems the precompiler macro "CC" was not defined in the Makefile, causing a bad link in this case...
I rebuilt llr64 and sllr64 on this machine, and now, I have no more problem with your example, while stopping and restarting, as you did.

So, I updated the "llr388devlinux64.zip" and "llr388devslinux64.zip" on my development directory accordingly.
I hope it resolves your problem!

Best Regards,
Jean

paulunderwood · 2012-03-29, 16:52

Quote:

Originally Posted by Jean Penné

Hi Paul,

I apologize for this late response, but I was unable to reproduce this problem. Now, I have a 64bit machine : an AMD Phenom(tm) II X4 965 Processor, whith Debian Linux AMD64 installed, and I could reproduce it.
It seems the precompiler macro "CC" was not defined in the Makefile, causing a bad link in this case...
I rebuilt llr64 and sllr64 on this machine, and now, I have no more problem with your example, while stopping and restarting, as you did.

So, I updated the "llr388devlinux64.zip" and "llr388devslinux64.zip" on my development directory accordingly.
I hope it resolves your problem!

Best Regards,
Jean

I tried the new builds here on Debian and the problem remains for me. It is really only a problem when I have to reboot one of my boxes -- I have a script to delete "save files" to make things safe. I could use the option to use no save files...

ps. I tried compiling from the source, but no joy

Paul

Jeff Gilchrist · 2012-03-29, 17:50

Quote:

Originally Posted by Jean Penné

The 32 and 64bit Mac OS binaries,
the 64bit Windows and Linux binaries are also available now at this address.

Jean, I just wanted to say merci for the latest release using GWNUM that supports AVX code. I have seen an enormous speedup for Vrba-Reix tests using a 480K FFT length. With LLR 3.8.7 I was getting an average of 62500 seconds per test and with 3.8.8 this has decreased to 37500 seconds!

Jeff.

Jean Penné · 2012-03-29, 19:39

Quote:

Originally Posted by paulunderwood

I tried the new builds here on Debian and the problem remains for me. It is really only a problem when I have to reboot one of my boxes -- I have a script to delete "save files" to make things safe. I could use the option to use no save files...

ps. I tried compiling from the source, but no joy

Paul

It is surprising! I have exactly the same Debian Linux system as you, and I have not this restart problem with your sample test...
(But I had it with the "externally built" binary!)

What CPU have you? It seems to be only hardware dependant...
Jean

2012-03-16, 18:24	#26
Jean Penné May 2004 FRANCE 2²×5×29 Posts	LLR 3.8.8 development version released Hi All, I released today the 32bit binaries of LLR 3.8.8 on my development directory : http://jpenne.free.fr/Development/ The only difference with LLR 3.8.7 is these binaries are linked with version 27.5 of gwnum library, although 3.8.7 ones are linked with version 26.5 Moreover, cllrd binary is linked with the debug library gwnumd.lib which detects internal errors such as failing asserts, and then abort the processing. Please consult the Readme file for details. Best Regards, Jean

2012-03-16, 18:30	#27
Jean Penné May 2004 FRANCE 244₁₆ Posts	Debugging tool for LLR 3.8.7 released Hi All, I released on my Development directory a special debugging version of LLR 3.8.7 ; As all LLR 3.8.7 versions released on my site, it is linked with version 26.5 of the gwnum library. but there, the gwnum.c file is slightly modified, so the result of (m == 45) assertion is registered in a global variable. As I wrote in the Readme file : The main purpose of this program is to help users for the recovery of possibly false results obtained while using gwnum V26 linked prime testing programs on some machines such as core duo T6300 or T6400. This program detects "m == 45" errors at setup time, and then, does not process the number further... Also, by using the -oTestm45=1 option, it can be used as a tool to record in the output file, the candidates that trigger this error, while ignoring the others ; with this option set, only the setup is done for each candidate. The names of the relevant compressed files follow : cllr387debugv6.zip, Windows console application. llr387debugv26linux.zip, Linux application, dynamic link. llr387debugv26slinux.zip, Linux application, static link. llr387debugv26src.zip, Complete source directory. If you need to build a Mac Os executable, you may have to modify some makefiles... Then be sure to compile Llr.c with "tm45" defined, by setting the relevant preprocessor option -Dtm45. I hope it will help... Best Regards, Jean

Similar Threads
Thread	Thread Starter	Forum	Replies	Last Post
LLR Development Version 3.8.9 released.	Jean Penné	Software	6	2012-05-09 23:44
LLR 3.8.6 Development version	Jean Penné	Software	0	2011-06-16 20:05
LLR 3.8.5 Development version	Jean Penné	Software	6	2011-04-28 06:21
PowerPC development platform	nuggetprime	Hardware	2	2011-01-06 18:37
LLR 3.8.4 development version is available!	Jean Penné	Software	4	2010-11-14 17:32