Client keeps crashing

[JeffreyLee]

I had modified net.cpp ,It run good,not crashed any longer an hour.
-#ifdef WIN32
+#if 1
         int nBytes = send(pnode->hSocket, &data[pnode->nSendOffset], data.size() - pnode->nSendOffset, MSG_NOSIGNAL | MSG_DONTWAIT);
 #else
         int nBytes = send(pnode->hSocket, &data[pnode->nSendOffset], data.size() - pnode->nSendOffset, MSG_DONTWAIT);

[dzhan]

can you implement it into the existing code?

[bytemaster]

GREAT WORK! 

[victor]

Running a few tests to see if I can replicate the issue.  I've got a watchdog wrapper for my protoshare client, so if it crashes I'll capture the debug.log file for analysis.

I'll let you know if I spot anything.

We are aware of this issue and have a 1 BTC bounty for any patches that can help resolve it quickly.

My quick patch below should fix this issue. Please test it.

http://pastebin.com/FQv3snaP

The cause of this problem is that the old client disconnects the new client due to the wrong proof of work; however there is a race condition that sometimes the new client still wants to communicate with the old client, but since the old client has closed this connection, a "broken pipe" signal will be passed to the new client and it is terminated.

Interestingly, on Windows platform a flag MSG_NOSIGNAL is passed to send() to avoid this problem. This should also apply to Linux since MSG_NOSIGNAL is supported after kernel 2.2+

Code: [Select]

--- ProtoShares/src/net.cpp     2013-11-11 11:46:13.019922787 -0800
+++ ProtoShares-new/src/net.cpp 2013-11-11 12:34:22.155890315 -0800
@@ -710,7 +710,7 @@
     while (it != pnode->vSendMsg.end()) {
         const CSerializeData &data = *it;
         assert(data.size() > pnode->nSendOffset);
-#ifdef WIN32
+#if 1
         int nBytes = send(pnode->hSocket, &data[pnode->nSendOffset], data.size() - pnode->nSendOffset, MSG_NOSIGNAL | MSG_DONTWAIT);
 #else
         int nBytes = send(pnode->hSocket, &data[pnode->nSendOffset], data.size() - pnode->nSendOffset, MSG_DONTWAIT);

[bytemaster]

Testing the protosharesd daemon on windows . . . not seeing any of the problems as reported for linux. Not yet anyway. Think you might be looking for something linux specific - maybe something specific to a version of the boost libs.

It seems to be when an old node connects, can we add a checkpoint at 12097?

[FreeTrade]

Testing the protosharesd daemon on windows . . . not seeing any of the problems as reported for linux. Not yet anyway. Think you might be looking for something linux specific - maybe something specific to a version of the boost libs.

[bytemaster]

Running a few tests to see if I can replicate the issue.  I've got a watchdog wrapper for my protoshare client, so if it crashes I'll capture the debug.log file for analysis.

I'll let you know if I spot anything.

We are aware of this issue and have a 1 BTC bounty for any patches that can help resolve it quickly. 

[gigawatt]

Running a few tests to see if I can replicate the issue.  I've got a watchdog wrapper for my protoshare client, so if it crashes I'll capture the debug.log file for analysis.

I'll let you know if I spot anything.

[craggietx]

ditto here.   finally just shut down my servers last night as the client would crash within 10 secs of starting.   

Sounds like you guys are about to get this fixed.   Thanks for all the hard work!

[JeffreyLee]

I have exactly the same problem.Ubuntu 12.04.3 desktop and Ubuntu 12.04.3 Server

[ryen123]

Same here. I ran it at DigitalOcean and it keeps stopping after 15/20 minutes.

[Vizierx]

So I think we have two colliding networks - some bug is causing the command line version to be affected, but not the QT client.

As a stop-gap measure we could compile a list of misbehaving IPs and block them at a higher level.

I think we should make the new client more robust instead. Some users have not upgraded to the latest client, and when a new client is communicating with the old ones is just crashes. It is hard to block all these IPs; and what if they upgrade to the latest client?

right you are - or do something like what to stop crush

[FreeTrade]

Are you guys seeing this in your log files much?

ERROR: AcceptBlock() : incorrect proof of work
ERROR: ProcessBlock() : AcceptBlock FAILED
Misbehaving: 60.247.75.39:3888 (0 -> 100) DISCONNECTING
disconnecting node 60.247.75.39:3888

I've got about 10 of these since the fork - it might be that these are not being handled correctly

[victor]

So I think we have two colliding networks - some bug is causing the command line version to be affected, but not the QT client.

As a stop-gap measure we could compile a list of misbehaving IPs and block them at a higher level.

I think we should make the new client more robust instead. Some users have not upgraded to the latest client, and when a new client is communicating with the old ones is just crashes. It is hard to block all these IPs; and what if they upgrade to the latest client?

[FreeTrade]

So I think we have two colliding networks - some bug is causing the command line version to be affected, but not the QT client.

As a stop-gap measure we could compile a list of misbehaving IPs and block them at a higher level.