Bitcoin 0.8.2rc1 on WinXP SP3 #2646

First run:

1. Old files removed and new archive extracted to Bitcoin install directory.
2. Bitcoin-Qt started and synced to network, then it stucked for a while showing progress meter and acting like some blocks are missing.
3. After a while it returned to normal state, with green check mark showing sync is complete.

Debug log reveals not everything is right - an example of errors encountered, there might be more so check log file linked bellow:

2013-05-12 14:32:42 received block 00000000000000a1acafe3cb63099b5cc8b5d81a0bbbf6191f5978ea05c4372c 2013-05-12 14:32:42 Committing 30380 changed transactions to coin database... 2013-05-12 14:32:42

EXCEPTION: St9bad_alloc std::bad_alloc C:\Program Files\Bitcoin\bitcoin-qt.exe in ProcessMessages()

2013-05-12 14:32:42 ProcessMessage(block, 442684 bytes) FAILED

2013-05-12 14:36:03 ERROR: Non-canonical signature: S value excessively padded 2013-05-12 14:36:03 ERROR: CScriptCheck() : c33bbdb11c757e9dc38063367cb460cf47d8934f8d9600c061d989b47ef2aa18 VerifySignature failed 2013-05-12 14:36:03 ERROR: CTxMemPool::accept() : ConnectInputs failed c33bbdb11c757e9dc38063367cb460cf47d8934f8d9600c061d989b47ef2aa18 2013-05-12 14:36:03 Misbehaving: 194.213.5.15:8333 (0 -> 0)

2013-05-12 14:30:03 ERROR: Non-canonical signature: R value excessively padded 2013-05-12 14:30:03 ERROR: CScriptCheck() : e390b43b53d5aa15a6c76020b019eec470567a607d8de08153cd8882067d7a77 VerifySignature failed 2013-05-12 14:30:03 ERROR: CTxMemPool::accept() : ConnectInputs failed e390b43b53d5aa15a6c76020b019eec470567a607d8de08153cd8882067d7a77 2013-05-12 14:30:03 Misbehaving: 77.249.178.204:8333 (10 -> 10)

2013-05-12 14:31:10 ERROR: Non-canonical signature: S value negative 2013-05-12 14:31:10 ERROR: CScriptCheck() : 1958ae3b25018b63683652f9875d1655990b5e99d22753503a00d67d56a019af VerifySignature failed 2013-05-12 14:31:10 ERROR: CTxMemPool::accept() : ConnectInputs failed 1958ae3b25018b63683652f9875d1655990b5e99d22753503a00d67d56a019af 2013-05-12 14:31:10 Misbehaving: 72.48.65.87:8333 (0 -> 0)

2013-05-12 14:33:05 ERROR: Non-canonical signature: R value negative 2013-05-12 14:33:05 ERROR: CScriptCheck() : 6618eea519e01f392c48d004d81ddaea799f36ea25a6b36ed818ef021d16884c VerifySignature failed 2013-05-12 14:33:05 ERROR: CTxMemPool::accept() : ConnectInputs failed 6618eea519e01f392c48d004d81ddaea799f36ea25a6b36ed818ef021d16884c 2013-05-12 14:33:05 Misbehaving: 109.190.65.235:8333 (0 -> 0)

Client seemed to be totally ignoring new blocks added to blockchain. I have compared block height with blockchain.info and saw that my client is 7 blocks behind but still showing green check mark. Upon exit, it crashed with error as shown on the linked image:

http://i.imgur.com/yolpQq7.png Full debug log for first run: http://www.filedropper.com/debug1

//////////////////////////////////////////////////////////////////////////////////////////////////////////////////

Second run:

1. Bitcoin-Qt started and synced properly, it updated to block height 235,845
2. Everything looked normal until I checked log file. One node was spamming my client with ton of orphan stuff, address adds and spent inputs without ever getting even banscore 10. I find that hillarious. Here is snapshot of spamming, for more check debug log linked bellow:

2013-05-12 14:56:08 ERROR: CTxMemPool::accept() : inputs already spent 2013-05-12 14:56:08 Misbehaving: 85.17.239.32:8333 (0 -> 0) 2013-05-12 14:56:08 ERROR: CTxMemPool::accept() : inputs already spent 2013-05-12 14:56:08 Misbehaving: 85.17.239.32:8333 (0 -> 0) 2013-05-12 14:56:08 ERROR: CTxMemPool::accept() : inputs already spent 2013-05-12 14:56:08 Misbehaving: 85.17.239.32:8333 (0 -> 0) 2013-05-12 14:56:08 ERROR: CTxMemPool::accept() : inputs already spent 2013-05-12 14:56:08 Misbehaving: 85.17.239.32:8333 (0 -> 0) 2013-05-12 14:56:08 ERROR: CTxMemPool::accept() : inputs already spent 2013-05-12 14:56:08 Misbehaving: 85.17.239.32:8333 (0 -> 0) 2013-05-12 14:56:08 ERROR: CTxMemPool::accept() : inputs already spent 2013-05-12 14:56:08 Misbehaving: 85.17.239.32:8333 (0 -> 0) 2013-05-12 14:56:08 ERROR: CTxMemPool::accept() : inputs already spent 2013-05-12 14:56:08 Misbehaving: 85.17.239.32:8333 (0 -> 0) 2013-05-12 14:56:08 ERROR: CTxMemPool::accept() : inputs already spent 2013-05-12 14:56:08 Misbehaving: 85.17.239.32:8333 (0 -> 0) 2013-05-12 14:56:08 ERROR: CTxMemPool::accept() : inputs already spent 2013-05-12 14:56:08 Misbehaving: 85.17.239.32:8333 (0 -> 0) 2013-05-12 14:56:08 ERROR: CTxMemPool::accept() : inputs already spent 2013-05-12 14:56:08 Misbehaving: 85.17.239.32:8333 (0 -> 0) 2013-05-12 14:56:08 ERROR: CTxMemPool::accept() : inputs already spent 2013-05-12 14:56:08 Misbehaving: 85.17.239.32:8333 (0 -> 0) 2013-05-12 14:56:08 ERROR: CTxMemPool::accept() : inputs already spent 2013-05-12 14:56:08 Misbehaving: 85.17.239.32:8333 (0 -> 0) 2013-05-12 14:56:08 ERROR: CTxMemPool::accept() : inputs already spent 2013-05-12 14:56:08 Misbehaving: 85.17.239.32:8333 (0 -> 0)

2013-05-12 15:01:13 Added 1 addresses from 85.17.239.32: 350 tried, 14092 new 2013-05-12 15:01:14 Added 1 addresses from 85.17.239.32: 350 tried, 14092 new 2013-05-12 15:01:15 Added 1 addresses from 85.17.239.32: 350 tried, 14092 new 2013-05-12 15:01:15 Added 1 addresses from 85.17.239.32: 350 tried, 14092 new

Bitcoin-Qt again refused to sync with newer block which was shown on blockchain.info but it exited without any error.

http://i.imgur.com/5vRYWkh.png (note BTC Guild self-owning, sort of :o))) Full debug log for second run: http://www.filedropper.com/debug2

Reverting to 0.8.1 for now. Let me know if you want me to test something specific.

P.S. Crashes on my machine are exclussive to Bitcoin. Beside it, I have Litecoin, Terracoin, Freicon, Feathercoin, BitBar, Small Change, YACoin, Bytecoin and PPCoin clients and none of them ever crashed. Machine has 2GB RAM and 8GB fixed swap file.

Bitcoin-Qt reverted back to 0.8.1 and started, it was in "attempting to sync" mode for few minutes and then it crashed with error as shown on screenshot bellow. I'm occassionaly seeing the same or similar errors for 6+ months now, just with Bitcoin-Qt, and so far none of MS Visual C++ runtime libraries available online fixed the issue.

http://i.imgur.com/9mFgSdY.png Full debug log, some weird errors inside: http://www.filedropper.com/debug3

On subsequent run Bitcoin-Qt 0.8.1 synced properly and so far everything seems normal except occassional spamming by few nodes. Syncing with newer blocks works perfectly. I'll update this post if something unexpected happens.

bad_alloc sounds like out-of-memory - are you running very close to the amount of memory available on your system?

The "inputs already spent" error is probably the wrong message, and should "inputs not found", since it may be just due to not knowing any of the inputs, no DoS logic is triggered.

Memory can't be the issue there because I used to run Armory (very memory hungry) beside Bitcoin-Qt and never got "memory low" or some similar warning. Crashes happen on random, so far I haven't found any procedure to replicate them on will. It is like a lottery for me, client sometimes runs for 24+ hours without any issue but then starts acting strange for next few runs, eventualy crashing with some MS Visual C++ error returned. Bitcoin-Qt itself uses 8 - 128 MB on average depending on the task and datadir is located on the partition that has 25+ GB free space at all times.

Note that node spamming orphan stuff, address adds and spent inputs (or whatever it is) reported 0 blocks upon connect:

2013-05-12 14:46:36 receive version message: version 70001, blocks=0, us=95.178.183.119:12954, them=85.17.239.32:8333, peer=85.17.239.32:8333

Full debug log for second run: http://www.filedropper.com/debug2 in line 100

Intentional misbehaviour?

Well bad_alloc is indeed memory related, it's an Exception thrown on failure allocating memory, see http://www.cplusplus.com/reference/new/bad_alloc. The problem here is, where does it come from... how many nodes were connected and what is your exact command-line (if any)? @sipa Take a look, seems to happen in ProcessMessages()

<pre> 2013-05-12 15:01:41 Committing 4247 changed transactions to coin database... 2013-05-12 15:01:41 ************************ EXCEPTION: St9bad_alloc std::bad_alloc C:\Program Files\Bitcoin\bitcoin-qt.exe in ProcessMessages() 2013-05-12 15:01:41 ProcessMessage(block, 451118 bytes) FAILED </pre>

-datadir=E:\BitcoinData added to shortcut used to run Bitcoin-Qt, bitcoin.conf contains the following lines:

keypool=1000 maxconnections=16 banscore=20 logtimestamps=1

I'm increasing or decreasing maxconnections based on if I'm in a need for upload bandwidth or not but it does not seem to affect the occurence of crashes. The same goes for keypool, I used to have it on default earlier and client was still crashing. I have reduced and increased swap file size, added it to all other partitions besides system one (C:) and even shuffled physical RAM DIMMs (4x 512MB, Dual channel enabled) but situation stayed the same.

There is also this bad_alloc in http://www.filedropper.com/debug3

EXCEPTION: St9bad_alloc std::bad_alloc C:\Program Files\Bitcoin\bitcoin-qt.exe in ThreadDumpAddress()

Bitcoin-Qt and all other cryptocoin clients are attempting to access all processes running on a computer regulary every 15 minutes or so which is not usual Win applications behaviour so I disabled process memory injection for all of them on firewall. Could it be that is the cause of problems? If yes, why other clients never crashed and what exactly Bitcoin-Qt gains by messing with memory of let's say firefox.exe or notepad.exe?

Are you sure you are using 0.8.2 RC1? AFAIK there is no ThreadDumpAddress() anymore in the client...

Error with ThreadDumpAddress() occured with 0.8.1which I used after deinstalling 0.8.2rc1

Node on 85.17.239.32 which was and is still spamming my node with crap is using some weird Bitcoin client:

{ "addr" : "85.17.239.32:8333", "services" : "00000000", "lastsend" : 1368798401, "lastrecv" : 1368798405, "conntime" : 1368792822, "version" : 70001, "subver" : "/Bitpeer:0.2.3/", <--- ??? "inbound" : false, "releasetime" : 0, "startingheight" : 0, "banscore" : 0 }

IP blacklisted on firewall, for now.