Restarted test node from wedged state @ +/- few seconds Wed Feb 26 17:26:19 CDT 2020 Catching up to max height... 619135 SetBestChain: new best=0000000000000000000ae0d89d1442c5b4cfb0730f60d74c8c200b07d57ca8b7 height=619135 work=4042381952238599882390792384 Complete. Now to let the node get 10 connections, currenly has 9... Done, now has 10 connections. GDB connected to process, currently in 'continue' mode. mod6@localhost ~ $ gdb -p 31119 GNU gdb (Gentoo 7.12.1 vanilla) 7.12.1 Copyright (C) 2017 Free Software Foundation, Inc. License GPLv3+: GNU GPL version 3 or later This is free software: you are free to change and redistribute it. There is NO WARRANTY, to the extent permitted by law. Type "show copying" and "show warranty" for details. This GDB was configured as "x86_64-pc-linux-gnu". Type "show configuration" for configuration details. For bug reporting instructions, please see: . Find the GDB manual and other documentation resources online at: . For help, type "help". Type "apropos word" to search for commands related to "word". Attaching to process 31119 [New LWP 31126] [New LWP 31128] [New LWP 31129] [New LWP 31130] [New LWP 31131] 0x000000000079c1de in __syscall () (gdb) continue Continuing. [New LWP 31160] [LWP 31160 exited] -------------------------------------------------------------------------- My previous test, test1 : http://www.mod6.net/wedger/mod6_wedger_test1.log http://www.mod6.net/wedger/trb_debug_wedgerpy_test1.log This test revealed that the node could be wedged with one press of the button. See the notes in 'mod6_wedger_test1.log'. -------------------------------------------------------------------------- This test will be exactly the same as the last test, except the following changes were made to net.h: mod6@localhost ~/trb $ vdiff a b diff -uNr a/bitcoin/src/net.h b/bitcoin/src/net.h --- a/bitcoin/src/net.h 492c9cc92a504bb8174d75fafcbee6980986182a459efc9bfa1d64766320d98ba2fa971d78d00a777c6cc50f82a5d424997927378e99738b1b3b550bdaa727f7 +++ b/bitcoin/src/net.h 9f9594ceded96846b7d6011b985bd0afe494fa810239f14ee0c240808ec49fbd1a030e50caf07b5d52a7e1db759add3e878d39b5f7f6d419d838515223d5e248 @@ -106,7 +106,7 @@ int64 nLastRecv; int64 nLastSendEmpty; int64 nTimeConnected; - unsigned int nHeaderStart; + int nHeaderStart; unsigned int nMessageStart; CAddress addr; int nVersion; @@ -289,7 +289,7 @@ void AbortMessage() { - if (nHeaderStart == -1) + if (nHeaderStart < 0) return; vSend.resize(nHeaderStart); nHeaderStart = -1; @@ -309,7 +309,7 @@ return; } - if (nHeaderStart == -1) + if (nHeaderStart < 0) return; // Set the size @@ -337,7 +337,7 @@ void EndMessageAbortIfEmpty() { - if (nHeaderStart == -1) + if (nHeaderStart < 0) return; int nSize = vSend.size() - nMessageStart; if (nSize > 0) -------------------------------------------------------------------------- Test 2: Send 49999 'getdata for block' commands to the node, see how it reacts and if it recovers. Host, Port, File = 127.0.0.1, 8333, snap_49999.txt mod6@localhost ~ $ ./wedger.py 127.0.0.1 8333 snap_49999.txt Alive: V=99999 (/therealbitcoin.org:0.9.99.99/) Jumpers=0x1 (TRB-Compat.) Return Addr=1.2.3.4:8333 Blocks=619137 Sending 1799991-byte message packet... Now listening for replies (Ctl-C to quit...) Violated BTC Protocol: Invalid payload length! .... In the debug.log after all of the request spam: 02/26/20 23:45:31 sending: block received getdata for: block 000000000000000000315d466fdf3b998863d292b47cb969e05fa253ba9e373a 02/26/20 23:45:31 sending: block received getdata for: block 0000000000000000007e5b8369be03692eb66bd6e00a34d2fea0ae3831eb95ab 02/26/20 23:45:31 sending: block Size large: 4295903080 (0x7fa3f1069e5a, 0x7fa4f114e5c2) Size wedge: 4295903080 (0x7fa3f1069e5a, 0x7fa4f114e5c2) Still wedged minutes later... received getdata for: block 00000000000000000048bd41931f1ee411eac82a5073afc1f3693719655a69cf 02/26/20 23:47:44 sending: block Size large: 4295957154 (0x7fa3f141952e, 0x7fa4f150afd0) Size wedge: 4295957154 (0x7fa3f141952e, 0x7fa4f150afd0) mod6@localhost ~ $ uptime 18:48:17 up 91 days, 7:45, 11 users, load average: 0.99, 0.71, 0.76 mod6@localhost ~ $ free total used free shared buff/cache available Mem: 131935684 4642744 2013956 744 125278984 125842132 Swap: 0 0 0 mod6@localhost ~ $ Also not responding to RPC commands! ----------------------------------------------------------------------- Now some debugging. Let's see what's in EndMessage(). I did this by re-running wedger.py with a snap file that contained just 1 block request entry. (gdb) break net.h:309 Breakpoint 1 at 0x45491a: file net.h, line 309. (gdb) continue Continuing. [Switching to LWP 31131] Thread 6 "bitcoind" hit Breakpoint 1, CNode::EndMessage (this=0xc3511a0) at net.h:312 312 if (nHeaderStart < 0) (gdb) bt #0 CNode::EndMessage (this=0xc3511a0) at net.h:312 #1 0x0000000000447062 in CNode::PushMessage (a1=..., pszCommand=0x7a95b6 "block", this=0xc3511a0) at net.h:386 #2 ProcessMessage (pfrom=pfrom@entry=0xc3511a0, strCommand=..., vRecv=...) at main.cpp:1894 #3 0x0000000000449a53 in ProcessMessages (pfrom=pfrom@entry=0xc3511a0) at main.cpp:2226 #4 0x000000000045c5e3 in ThreadMessageHandler2 (parg=parg@entry=0x0) at net.cpp:1129 #5 0x000000000045c7d7 in ThreadMessageHandler (parg=0x0) at net.cpp:1094 #6 0x0000000000798db6 in start () #7 0x0000000000000000 in ?? () (gdb) print vSend $3 = {vch = { >> = {_M_impl = {> = {> = {<__gnu_cxx::new_allocator> = {}, }, }, _M_start = 0x7fa3f0cc3020 "\371\276\264\331block", _M_finish = 0x7fa4f1b98644 "", _M_end_of_storage = 0x7fa52a3748c6 ""}}, }, nReadPos = 3798014, state = 0, exceptmask = 5, nType = 1, nVersion = 99999} (gdb) print nMessageStart $4 = 10762120 (gdb) print nHeaderStart $5 = 10762096 (gdb) p/x nMessageStart $6 = 0xa43788 (gdb) p/x nHeaderStart $7 = 0xa43770 (gdb) p/x (0x7fa52a3748c6 - (0x7fa3f0cc3020 + 0xa43788)) $8 = 0x138c6e11e (gdb) print 0x138c6e11e $9 = 5247525150 -------------------------------------------------------------------------- The code changes in the vpatch above did not work. Stopping this test for now. Going to add a simple checker to the code so I can find the blocks that are of 'wedge' size easily. Will try again shortly.