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 <http://gnu.org/licenses/gpl.html>
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:
<https://bugs.gentoo.org/>.
Find the GDB manual and other documentation resources online at:
<http://www.gnu.org/software/gdb/documentation/>.
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 
<INCOMING MESSAGE: 'version', 115 bytes>
Alive: V=99999 (/therealbitcoin.org:0.9.99.99/) Jumpers=0x1 (TRB-Compat.) Return Addr=1.2.3.4:8333 Blocks=619137
<INCOMING MESSAGE: 'verack', 0 bytes>
Sending 1799991-byte message packet...
Now listening for replies (Ctl-C to quit...)
<INCOMING MESSAGE: 'getblocks', 1029 bytes>
<INCOMING MESSAGE: 'block', 978262 bytes>
<INCOMING MESSAGE: 'block', 974661 bytes>
<INCOMING MESSAGE: 'block', 968422 bytes>
<INCOMING MESSAGE: 'block', 967259 bytes>
<INCOMING MESSAGE: 'block', 972178 bytes>
<INCOMING MESSAGE: 'block', 985159 bytes>
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<CBlock> (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 = {<std::_Vector_base<char, zero_after_free_allocator<char> >> = {_M_impl = {<zero_after_free_allocator<char>> = {<std::allocator<char>> = {<__gnu_cxx::new_allocator<char>> = {<No data fields>}, <No data fields>}, <No data fields>},
        _M_start = 0x7fa3f0cc3020 "\371\276\264\331block", _M_finish = 0x7fa4f1b98644 "", _M_end_of_storage = 0x7fa52a3748c6 ""}}, <No data fields>}, 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.