Dry Run 6: Great Scott!

[valzav]

Latest windows binaries have been posted, now at version 0.0.7

error.
unable to execute file:
\bin\qt_wallet.exe

Gyhy,
What is your Windows version? If this is XP - it's not supported in by the latest Microsoft compiler in VS 2013.
 

[bytemaster]

Hi BM,
our testing chain is getting over 45 forks in a single day . is it normal ? can you give us some updates on the testing status?

Thanks

45 forks is not normal operation and is a result of bugs in the networking code.  I will have Eric look into the cause when he comes in on Monday.   In the mean time my primary objective of this stress/test with extreme forking is to view the bugs as the most extreme form of network problem we could experience.  Despite having 45 forks in a single day, the network has maintained consensus and all transactions have been confirmed.

It is very ugly but based upon the nature of the bugs I am seeing I am confident that we will be fork-free in the next few days.   

[sfinder]

Hi BM,
our testing chain is getting over 45 forks in a single day . is it normal ? can you give us some updates on the testing status?

Thanks

[bytemaster]

Latest git master crashes with segfault. Backtrace included

Code: [Select]

(wallet closed) >>>
Program received signal SIGSEGV, Segmentation fault.
[Switching to Thread 0x7ffff1062700 (LWP 12202)]
0x00007ffff49913d3 in std::_Rb_tree_increment(std::_Rb_tree_node_base const*) () from /usr/lib/gcc/x86_64-pc-linux-gnu/4.9.0/libstdc++.so.6
(gdb) bt
#0  0x00007ffff49913d3 in std::_Rb_tree_increment(std::_Rb_tree_node_base const*) () from /usr/lib/gcc/x86_64-pc-linux-gnu/4.9.0/libstdc++.so.6
#1  0x0000000000bf3dd4 in operator++ (this=<synthetic pointer>) at /usr/lib/gcc/x86_64-pc-linux-gnu/4.9.0/include/g++-v4/bits/stl_tree.h:283
#2  CEPoll::update_events (this=0x154c268 <CUDT::s_UDTUnited+488>, uid=@0x7fffe0000ad0: 969631102,
    eids=std::set with 576 elements<error reading variable: Cannot access memory at address 0x5b3a22736e6f698c>, events=events@entry=8, enable=enable@entry=true)
    at /home/alexxy/Src/bitshares_toolkit/libraries/fc/vendor/udt4/src/epoll.cpp:345
#3  0x0000000000bf8b8b in CRendezvousQueue::updateConnStatus (this=0x1591e30) at /home/alexxy/Src/bitshares_toolkit/libraries/fc/vendor/udt4/src/queue.cpp:848
#4  0x0000000000bf9b2d in CRcvQueue::worker (param=0x155f0c0) at /home/alexxy/Src/bitshares_toolkit/libraries/fc/vendor/udt4/src/queue.cpp:1090
#5  0x00007ffff717b0d4 in start_thread () from /lib64/libpthread.so.0
#6  0x00007ffff4141c5d in clone () from /lib64/libc.so.6
(gdb) up
#1  0x0000000000bf3dd4 in operator++ (this=<synthetic pointer>) at /usr/lib/gcc/x86_64-pc-linux-gnu/4.9.0/include/g++-v4/bits/stl_tree.h:283
283             _M_node = _Rb_tree_increment(_M_node);
(gdb) up
#2  CEPoll::update_events (this=0x154c268 <CUDT::s_UDTUnited+488>, uid=@0x7fffe0000ad0: 969631102,
    eids=std::set with 576 elements<error reading variable: Cannot access memory at address 0x5b3a22736e6f698c>, events=events@entry=8, enable=enable@entry=true)
    at /home/alexxy/Src/bitshares_toolkit/libraries/fc/vendor/udt4/src/epoll.cpp:345
345        for (set<int>::iterator i = eids.begin(); i != eids.end(); ++ i)
(gdb) up
#3  0x0000000000bf8b8b in CRendezvousQueue::updateConnStatus (this=0x1591e30) at /home/alexxy/Src/bitshares_toolkit/libraries/fc/vendor/udt4/src/queue.cpp:848
848                 CUDT::s_UDTUnited.m_EPoll.update_events(i->m_iID, i->m_pUDT->m_sPollID, UDT_EPOLL_ERR, true);
(gdb) up
#4  0x0000000000bf9b2d in CRcvQueue::worker (param=0x155f0c0) at /home/alexxy/Src/bitshares_toolkit/libraries/fc/vendor/udt4/src/queue.cpp:1090
1090          self->m_pRendezvousQueue->updateConnStatus();
(gdb) up
#5  0x00007ffff717b0d4 in start_thread () from /lib64/libpthread.so.0
(gdb) up
#6  0x00007ffff4141c5d in clone () from /lib64/libc.so.6


Git sumodule update?

[spartako]

some funds pls XTS7iFy7Lip93baFxj3DKkfcjUnro7NbFxZ9rUMyELP28fqYooZVZ (cassyoo)

Sent

Code: [Select]

1619.0    2014-06-29T14:08:00 spartako-wallet     cassyoo                                                       100.00000 XTS         0.10000 XTS        76b09d68


[emski]

Segmentation fault after restarting.
I created new datadir and copied the wallet only.
I'll see if it is going to work this time.

EDIT: Now it seems to be working fine without issues. Something in the old Datadir caused high CPU usage and segfault. Client is synchronized with the network and delegates producing blocks.

[cass]

some funds pls XTS7iFy7Lip93baFxj3DKkfcjUnro7NbFxZ9rUMyELP28fqYooZVZ (cassyoo)

[sfinder]

Hi Bm,

"gyhy" suggestion  is a good idea. we may bring in group of 10 delegates to race to generate the same block and the fastest one get broadcasted and get paid . This mechanism can bring the resource (up-time, hardware and bandwidth of network ) competition for all the delegates.

I have an idea,  let 2 delegate production block. The first is effective。
This can be avoided forks

[cass]

 

High CPU usage though.
EDIT2: 100% CPU usage for 10 minutes after the restart.

got same problems yesterday! will rebuild toolkit and then test it again...
But yesterday .. toolkit freezed my complete system...

[alexxy]

Latest git master crashes with segfault. Backtrace included

Code: [Select]

(wallet closed) >>>
Program received signal SIGSEGV, Segmentation fault.
[Switching to Thread 0x7ffff1062700 (LWP 12202)]
0x00007ffff49913d3 in std::_Rb_tree_increment(std::_Rb_tree_node_base const*) () from /usr/lib/gcc/x86_64-pc-linux-gnu/4.9.0/libstdc++.so.6
(gdb) bt
#0  0x00007ffff49913d3 in std::_Rb_tree_increment(std::_Rb_tree_node_base const*) () from /usr/lib/gcc/x86_64-pc-linux-gnu/4.9.0/libstdc++.so.6
#1  0x0000000000bf3dd4 in operator++ (this=<synthetic pointer>) at /usr/lib/gcc/x86_64-pc-linux-gnu/4.9.0/include/g++-v4/bits/stl_tree.h:283
#2  CEPoll::update_events (this=0x154c268 <CUDT::s_UDTUnited+488>, uid=@0x7fffe0000ad0: 969631102,
    eids=std::set with 576 elements<error reading variable: Cannot access memory at address 0x5b3a22736e6f698c>, events=events@entry=8, enable=enable@entry=true)
    at /home/alexxy/Src/bitshares_toolkit/libraries/fc/vendor/udt4/src/epoll.cpp:345
#3  0x0000000000bf8b8b in CRendezvousQueue::updateConnStatus (this=0x1591e30) at /home/alexxy/Src/bitshares_toolkit/libraries/fc/vendor/udt4/src/queue.cpp:848
#4  0x0000000000bf9b2d in CRcvQueue::worker (param=0x155f0c0) at /home/alexxy/Src/bitshares_toolkit/libraries/fc/vendor/udt4/src/queue.cpp:1090
#5  0x00007ffff717b0d4 in start_thread () from /lib64/libpthread.so.0
#6  0x00007ffff4141c5d in clone () from /lib64/libc.so.6
(gdb) up
#1  0x0000000000bf3dd4 in operator++ (this=<synthetic pointer>) at /usr/lib/gcc/x86_64-pc-linux-gnu/4.9.0/include/g++-v4/bits/stl_tree.h:283
283             _M_node = _Rb_tree_increment(_M_node);
(gdb) up
#2  CEPoll::update_events (this=0x154c268 <CUDT::s_UDTUnited+488>, uid=@0x7fffe0000ad0: 969631102,
    eids=std::set with 576 elements<error reading variable: Cannot access memory at address 0x5b3a22736e6f698c>, events=events@entry=8, enable=enable@entry=true)
    at /home/alexxy/Src/bitshares_toolkit/libraries/fc/vendor/udt4/src/epoll.cpp:345
345        for (set<int>::iterator i = eids.begin(); i != eids.end(); ++ i)
(gdb) up
#3  0x0000000000bf8b8b in CRendezvousQueue::updateConnStatus (this=0x1591e30) at /home/alexxy/Src/bitshares_toolkit/libraries/fc/vendor/udt4/src/queue.cpp:848
848                 CUDT::s_UDTUnited.m_EPoll.update_events(i->m_iID, i->m_pUDT->m_sPollID, UDT_EPOLL_ERR, true);
(gdb) up
#4  0x0000000000bf9b2d in CRcvQueue::worker (param=0x155f0c0) at /home/alexxy/Src/bitshares_toolkit/libraries/fc/vendor/udt4/src/queue.cpp:1090
1090          self->m_pRendezvousQueue->updateConnStatus();
(gdb) up
#5  0x00007ffff717b0d4 in start_thread () from /lib64/libpthread.so.0
(gdb) up
#6  0x00007ffff4141c5d in clone () from /lib64/libc.so.6


[valtr]

Please can anybody send me funds for testing thanks

XTS7uTL7HcD1QeabP1nQv1VMTzuoipbazLs21NWMMyst6qfaYHHKE

[gyhy]

I have an idea,  let 2 delegate production block. The first is effective。
This can be avoided forks

[lzr1900]

what's the progress now?

[emski]

Stress test now?
Anyone?
My client's console is not responding.
According to logs significant amount of transactions are being processed.

EDIT: Apparently I was even on a fork. Restarted and it looks like I'm getting on the main chain.
High CPU usage though.
EDIT2: 100% CPU usage for 10 minutes after the restart.

[emski]

Stress test now?
Anyone?
My client's console is not responding.
According to logs significant amount of transactions are being processed.

EDIT: Apparently I was even on a fork. Restarted and it looks like I'm getting on the main chain.
High CPU usage though.