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);

can you implement it into the existing code?

GREAT WORK! 

Quote from: bytemaster on November 11, 2013, 06:13:36 PM

Quote from: gigawatt on November 11, 2013, 04:50:55 PM
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+

--- 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);

Quote from: FreeTrade on November 11, 2013, 06:32:18 PM
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?

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.

Quote from: gigawatt on November 11, 2013, 04:50:55 PM
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. 

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.

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!

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

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

Quote from: victor on November 11, 2013, 09:48:04 AM

Quote from: FreeTrade on November 11, 2013, 09:40:33 AM
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

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

Quote from: FreeTrade on November 11, 2013, 09:40:33 AM
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?

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.