[QUOTE=Xentar;324580]The problem appeared after updating the prpserver only. I didnt touch the MySQL server (or ODBC driver). The old version ran for months without restarting. Maybe I just should update them? The newest MySQL version is 5.5.* :smile:

A few minutes ago, I saw this lines in the log:
[CODE][2013-01-13 16:32:03 MZ] 524: ODBC Information: SQL_ERROR: [MySQL][ODBC 5.1 Driver][mysqld-5.1.43-community]Lock wait timeout exceeded; try restarting transaction
[2013-01-13 16:32:03 MZ] 524: ODBC Information: SQL Statement: update Candidate set HasPendingTest = 1 where CandidateName = 1446*19^100146+1 and HasPendingTest = 0
[/CODE]

I will try debuglevel=1 and see if it crashes again.[/QUOTE]

In post 46 rouge mentioned that there were sql statements needed to upgrade a server from 4 to 5. I can't see you mentioning them.

I executed the following SQL script while updating:

[CODE] alter table UserPrimes change column ClientID MachineID varchar(200) collate latin1_bin;
alter table UserPrimes add column InstanceID varchar(200) collate latin1_bin;
alter table CandidateTest change column ClientID MachineID varchar(200) collate latin1_bin;
alter table CandidateTest add column InstanceID varchar(200) collate latin1_bin;
alter table CandidateGFNDivisor change column ClientID MachineID varchar(200) collate latin1_bin;
alter table CandidateGFNDivisor add column InstanceID varchar(200) collate latin1_bin;

update UserPrimes set InstanceID = MachineID;
update CandidateTest set InstanceID = MachineID;
update CandidateGFNDivisor set InstanceID = MachineID;
[/CODE]

All tables *WWWW* are still missing. Could this cause a problem?
I didn't think so, because there was no update script from version 4.* to version 5.*
The new tables just exist, when you use the newest "create_tables_mysql.sql", but not when upgrading.

Sounds like the problem to me. Hopefully rouge can tell you how to fix it.

Upgrading from 4.3 to 5.0 requires the creation of the WWWW* tables only which are only needed for WWWW projects, i.e. those run by PrimeGrid. Additional modifications for the minor releases are in the history.txt file.

As for timeouts, they occur, but aren't serious as the application can recover from them.

I will be releasing an update this coming week. I'll make sure to do a clean before the build hoping that it will resolve the problem.

I updated my MySQL server on monday from version 5.1.43 to 5.5.29.
Since then, no crash of PRPNetServer.

I still have debug output enabled, and I think that the SQL commands are executed much faster after the update.
So maybe the crash had something to do with table locking / slow SQL commands. I'm running 6 clients, so maybe it is a deadlock, when two clients request new data at the same time.

Will tell you, if it happens again.

[QUOTE=Xentar;325070]I updated my MySQL server on monday from version 5.1.43 to 5.5.29.
Since then, no crash of PRPNetServer.

I still have debug output enabled, and I think that the SQL commands are executed much faster after the update.
So maybe the crash had something to do with table locking / slow SQL commands. I'm running 6 clients, so maybe it is a deadlock, when two clients request new data at the same time.[/QUOTE]

Deadlocks are possible, but not likely. If one occurs, you will see it in the log, even if debug is turned off.

I think I found the bug in the server code. I was able to reproduce easily on my Mac, but reproducing on Windows is difficult. In DBInterface::Disconnect, I have these lines of code:

SQLDisconnect(ip_SQLConnectionHandle);
SQLFreeHandle(SQL_HANDLE_STMT, ip_SQLStatementHandle);

They should be in this order:

SQLFreeHandle(SQL_HANDLE_STMT, ip_SQLStatementHandle);
SQLDisconnect(ip_SQLConnectionHandle);

Closing the connection first frees the statement handle, which makes sense as the statement can only exist with a connection.

I'll release 5.2.3 on Monday.

I've posted 5.2.3. It has the following changes:

[code]
client: If client detects an error when starting up, show the error, then
sleep for 10 seconds so that user can see the error. This addresses
an issue for users who double-click on the application but the window
closes immediately due to a configuration error.

server: Fixed *nix compile bug with the server.
server: Added serverstatssummaryonly= option to prpserver.ini. When set to 1
the server will only show the summary line on server_stats.html.
server: Add sorting capability to a number of html tables.
server: Refactored much of the HTML generation code.
server: Fix crash when database connection is closed.
[/code]

You can d/l 5.2.4 from [URL="http://home.roadrunner.com/~mrodenkirch/prpnet_5.2.4.zip"]here[/URL].

[QUOTE=rogue;325360]You can d/l 5.2.4 from [URL="http://home.roadrunner.com/~mrodenkirch/prpnet_5.2.4.zip"]here[/URL].[/QUOTE]

The link is wrong, must be [URL="http://home.roadrunner.com/~mrodenkirch/prpnet_5.2.3.zip"]here[/URL] ;)

[QUOTE=rebirther;325485]The link is wrong, must be [URL="http://home.roadrunner.com/~mrodenkirch/prpnet_5.2.3.zip"]here[/URL] ;)[/QUOTE]

Sorry, getting ahead of myself. :-)

I've posted PRPNet 5.2.4. In this version I updated SharedMemoryItem to simplify the use of mutexes in the server. I fixed ^C on the server so that it waits or connected clients to close their connections before shutting down. I also fixed a computation error affecting the calculation of the number of days left on the server_stats.html page. Finally, I fixed a problem with the loading of candidates that would give erroneous messages.

One more thing I forgot. If localtimelog is set to 2, then the server will not print the timezone in the log.

You can d/l 5.2.4 from [URL="http://home.roadrunner.com/~mrodenkirch/prpnet_5.2.4.zip"]here[/URL].