select failed 10038 fix

I believe I’ve fixed the bug related to “select failed: 10038” (error WSAENOTSOCK).  The select error is not a big deal, but it led the communications thread to get blocked on a socket that should have been in non-blocking mode but wasn’t.  It never came up until now because as long as select never failed, receive would never be called unless there was data. Without this fix, your node’s communication sometimes goes dead.  Connections are still made, but no data is passed.  Any generated blocks would probably not be accepted since you can’t broadcast them and other nodes will leave your branch behind.  That’s why Generate doesn’t run when you’re not connected. This could also have caused bitcoin.exe to fail to exit.  There’s no reason for shutdown to wait for the com thread, so I made it only wait for the message processing thread.  I’ll do a more thorough forced shutdown later. Looks like your node’s com thread just now got blocked on this bug again.  It went for a few hours this time before it did. Version 0.1.3 exe attached.

It definitely looks like 0.1.3 solved it.  It was getting so there were so many zombie nodes, I was having a hard time getting a reply to any of my messages.  Now, four inventory messages go out, four getdata messages come back. Did you get any “not accepted” blocks?  The connectivity bug could have caused a generated block not to be accepted if the node wasn’t able to broadcast at the time.  Once the status is above 5 or so it’s safely accepted. Unfortunately, I can’t receive incoming connections from where I am, which has made things more difficult.  Your node receiving incoming connections was the main thing keeping the network going the first day or two. You can send to my Bitcoin address if you want to, but you won’t get to see the full transfer sequence: 1NSwywA5Dvuyw89sfs3oLPvLiDNGf48cPD You could always findstr /c:“version message” debug.log and send a test to some random person you’re connected to near the end of the list.  The ones ending in port 8333 can receive connections. I just thought of something.  Eventually there’ll be some interest in brute force scanning bitcoin addresses to find one with the first few characters customized to your name, kind of like getting a phone number that spells out something.  Just by chance I have my initials. Satoshi Thanks, Satoshi, this new version seems to be running much better. I’ve got 8 connections, and watching debug.log there seems to be quite a bit of activity. I see you sent me a payment, thanks! Let me know your address and I will try sending one to you. I managed to generate a block yesterday and the coins are about to mature, if I understand it correctly. Hal

Could you send me the debug.log from the 0.1.3 crash? I can usually get a lot just from that. I’ll send you the debug builds shortly. Looks like 0.1.3 crashed during the night, unfortunately. Next time I will try running the debug version. Today I am working and will need to take this computer up and down quite a bit, so I won’t be able to run it for most of the day. Tonight I will try to look at it a little bit. Hal

Definitely the disk full.  I completely put off disk full handling until a later version.  Probably about time I did it now. Well, that’s a relief. Satoshi Hi Satoshi - Sorry I have not been able to do more today, this looks like a busy week for me. I started 0.1.3 again under the MSVC debugger this time so if it crashes tonight I may be able to get some more information. I remember now that last night, my disk filled up. I had downloaded a bunch of the dependencies (boost, etc) with an eye towards trying to build it myself, and my disk was already pretty full. I’m pretty sure this is what caused 0.1.3 to crash. I’ve attached the debug.log, which also includes some other runs. The error is about 1/3 of the way down and says, EXCEPTION: NSt8ios_base7failureE CAutoFile::read : end of file Normally this should be a rare occurrence with the large disk sizes people have today. Hal