Quote from: gyhy on June 29, 2014, 03:38:09 AM

Quote from: bytemaster on June 29, 2014, 03:14:57 AM
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.
 

Quote from: sfinder on June 29, 2014, 02:28:01 PM
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.   

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

Quote from: alexxy on June 29, 2014, 11:05:02 AM
Latest git master crashes with segfault. Backtrace included

Code Select Expand


(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?

Quote from: cass on June 29, 2014, 01:05:21 PM
some funds pls XTS7iFy7Lip93baFxj3DKkfcjUnro7NbFxZ9rUMyELP28fqYooZVZ (cassyoo)

Sent

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


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.

some funds pls XTS7iFy7Lip93baFxj3DKkfcjUnro7NbFxZ9rUMyELP28fqYooZVZ (cassyoo)

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.

Quote from: gyhy on June 29, 2014, 10:06:09 AM
I have an idea,  let 2 delegate production block. The first is effective。
This can be avoided forks

 :o

Quote from: emski on June 29, 2014, 08:58:02 AM

Quote from: emski on June 29, 2014, 08:36:23 AM
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...

Latest git master crashes with segfault. Backtrace included

(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


Please can anybody send me funds for testing thanks

XTS7uTL7HcD1QeabP1nQv1VMTzuoipbazLs21NWMMyst6qfaYHHKE

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

what's the progress now?

Quote from: emski on June 29, 2014, 08:36:23 AM
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.

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.