PRPNet released!

[Lennart]

Originally Posted by rogue

I found a major bug in 2.4.3 that occurs when the server allows for more than 15 or so workunits at a time and the client grabs that many. This causes the client to crash when returning them.

Here is a consolidated list of changes from 2.4.3:

• all: Fix a crash that occurs when large messages (> 1000 bytes) are received.
• server: Prevent server from double-checking primes.
• server: Output a message if unable to open of the .removed files and keep candidate in the main file until the .removed file can be opened. This addresses a potential crash in which the server presumes that the .removed file could be opened.

You can d/l it from here.

Enjoy,
Mark

All servers on PG are now running 2.4.4 :)

Lennart

[mdettweiler]

Originally Posted by rogue

server: Prevent server from double-checking primes.

Quick question: why not doublecheck primes if doublechecking is turned on? Or is it assumed that most projects will have a separate process for doublechecking primes if they're doing doublechecking concurrently with the first-pass tests?

[rogue]

Originally Posted by mdettweiler

Quick question: why not doublecheck primes if doublechecking is turned on? Or is it assumed that most projects will have a separate process for doublechecking primes if they're doing doublechecking concurrently with the first-pass tests?

The chance of running two tests on a number with two different programs and one returning PRP and the other prime is virtually impossible. If only a single test is used for primality (base 2 for example), then it is slightly more likely that the result is incorrect, but not significantly so. My recommendation is that projects do a second independent test for primality.

[mdettweiler]

Originally Posted by rogue

The chance of running two tests on a number with two different programs and one returning PRP and the other prime is virtually impossible. If only a single test is used for primality (base 2 for example), then it is slightly more likely that the result is incorrect, but not significantly so. My recommendation is that projects do a second independent test for primality.

Ah, right, I forgot about the second primality test. Okay, that makes sense.

[rogue]

This release addresses most (if not all) of the stability issues from 2.4.x. Thanks to Max and Lennart for assisting me in tracking down these nuisance bugs.

Here is a list of changes from 2.4.4:

• all: Reduced socket timeout from 30 seconds to 10.
• all: Fixed a crash that can occur when logging is turned on. This was inadvertently added in 2.4.4.
• all: Modified handling of large messages since some OSs return the number of bytes read from the socket while others return the number of bytes in the receive buffer.

That last one was particularly nasty to diagnose and find because I could not reproduce it on any of the OSs available to me. Max is still experiencing some issues with PRPNet on Linux, which I hope to track down as soon as I has access to one of his boxes.

You can d/l it from here.

Enjoy,
Mark

[rogue]

I fixed a stupid bug I introduced into the server. If you run the server, you will need to d/l again.

[rogue]

You can d/l the software from here.AFAIK, this release resolves the last socket issue on Ubuntu (which I think has a bug WRT sockets). Here is a summary of changes

• all: Force close of socket if nothing is received.
• all: Use select() on the socket before receiving. On Linux (and only Linux), recv() will not return if there is nothing to be read from the socket. select() can be configured to timeout if there is nothing to be received. On all other OSs (Windows, Mac OS X, HP-UX, and Solaris) recv() return a 0 if there is nothing to be received.
• prpadmin: Change order of includes to address builds on Unix.
• prpadmin: Fixed an error where messages from server would not print.
• prpserver: Modified generic server stats to not list GFN divisors found.
• prpserver: Added HTML classes for GFNs, Primorials, and Factorials

Enjoy,
Mark

[Mini-Geek]

Hate to be the bearer of bad news again, but I'm getting some instability on the 2.4.6 client. It sometimes crashes at the end of a getwork communication. Nothing looks wrong in the communication, and there is no error message, just a silent crash. It does not write the files necessary to work the new assignments.
I'm currently trying to get some debug info and verify that it's on the released one (and not only one of the early-release versions of it).

[rogue]

Originally Posted by Mini-Geek

Hate to be the bearer of bad news again, but I'm getting some instability on the 2.4.6 client. It sometimes crashes at the end of a getwork communication. Nothing looks wrong in the communication, and there is no error message, just a silent crash. It does not write the files necessary to work the new assignments.
I'm currently trying to get some debug info and verify that it's on the released one (and not only one of the early-release versions of it).

Make sure you let me know which OS this is affecting.

[Mini-Geek]

Originally Posted by rogue

Make sure you let me know which OS this is affecting.

Windows. More specifically, 32-bit XP SP3.
I've used the debugger just like I did for the server (except I have it attached to multiple processes to watch all the clients), including building it on my machine in debug mode and copying the .ilk and .pdb files to the running folder, but the debugger didn't trigger and show the problem when the client crashed again. I'm more confused than I was before... All it said in the debugger was "The program '[3136] prpclient.exe: Native' has exited with code -1 (0xffffffff)."
Just in case running one instance of Vis Studio on more than one client process was the reason it didn't tell me anything useful (at least not directly anyway, though perhaps the lack of error message is somewhat helpful), I'll run it overnight with it just attached to one client. Given the failure rate, I'd say there's a decent, but not near-certain, chance of it happening.

[rogue]

Originally Posted by Mini-Geek

Windows. More specifically, 32-bit XP SP3.
I've used the debugger just like I did for the server (except I have it attached to multiple processes to watch all the clients), including building it on my machine in debug mode and copying the .ilk and .pdb files to the running folder, but the debugger didn't trigger and show the problem when the client crashed again. I'm more confused than I was before... All it said in the debugger was "The program '[3136] prpclient.exe: Native' has exited with code -1 (0xffffffff)."
Just in case running one instance of Vis Studio on more than one client process was the reason it didn't tell me anything useful (at least not directly anyway, though perhaps the lack of error message is somewhat helpful), I'll run it overnight with it just attached to one client. Given the failure rate, I'd say there's a decent, but not near-certain, chance of it happening.

The -1 is an exit, not a crash. This occurs when the client has detected an unrecoverable error, such as not being able to write to or read from a file. It can also happen if it could not parse the output from the helper program. If you run the client from a DOS window, it should show you an error before it terminates. I would suggest this rather than double-clicking on the exe from explorer.

If this is a problem with reading the output from a helper program, it should be fairly easy to fix. It is most likely due to the client not recognizing a line of output from the helper program.