Dry Run 8: Need for Speed

[bytemaster]

W00t!!! Curious what it was. Link to change that fixes it in github?

https://github.com/BitShares/bitshares_toolkit/commit/45b7731435d2197961b79461705acb7c630c785d

[alt]

don't know if it's a known issue.
my client failed to  sync blocks at block 9661.
from the logs, switch fork failed because of detected duplicate transaction

Code: [Select]

20140711T010615.408801       th_a       switch_to_fork ] switch from fork 76fdaa3232590335bace099a977c31a36327a4ef to c91e6df277471ad7654273370452f783e78c9cb5         chain_database.cpp:497
20140711T010615.408824       th_a     get_fork_history ]                        chain_database.cpp:842
20140711T010615.408899       th_a     get_fork_history ] return: ["c91e6df277471ad7654273370452f783e78c9cb5","3c5a66fe4b06a2b7798d8c167bddf472d3dc847a","76fdaa3232590335bace099a977c31a36327a4ef"]                     chain_database.cpp:863
20140711T010615.408930       th_a       switch_to_fork ]     extend 3c5a66fe4b06a2b7798d8c167bddf472d3dc847a                    chain_database.cpp:507
20140711T010615.410323       th_a   apply_transactions ] Applying transactions from block: 9662                 chain_database.cpp:517
20140711T010615.410544       th_a         extend_chain ] error applying block: 30007 duplicate_transaction: duplicate transaction

    {"trx_id":"12c892efad26a84c73a9271d2b0469b99645d7fe"}
    th_a  transaction_evaluation_state.cpp:189 evaluate

    {"trx":{"expiration":"20140710T094537","delegate_slate_id":null,"operations":[{"type":"withdraw_op_type","data":{"balance_id":"XTSJa6bm5iPYsahikNECLr2k17gwWicnEUjm","amount":10000,"claim_input_data":""}},{"type":"withdraw_op_type","data":{"balance_id":"XTSBmdRD4rigXPmn6VjJVdydaNnq15SfzzAm","amount":10000,"claim_input_data":""}},{"type":"deposit_op_type","data":{"amount":10000,"condition":{"asset_id":0,"delegate_slate_id":7694373846492465735,"type":"withdraw_signature_type","data":{"owner":"XTS6gvyPkLeERzaNuP1JR5vrdW54skHzHJ56","memo":{"one_time_key":"XTS7D5HyiW6wPbHNbYzhYRhRG1hTfeBrDcHTm1W9Pq6VPHAg6hLLP","encrypted_memo_data":"d89b7e926009b356d23df76860e902952d435b0df62db29d723fdee18f916cd25ea576a06ecfddeeb8b34c70953b17d6f873e6c661a5ad534feb8f5d4f85a62f"}}}}}],"signatures":["20d7aee2566b2513d5d6f5ae3681c0e5fe9db4331343dd9e8e9e1cae61fec6c14ce053116fcf6744c946646cd1c7df4172e5cec953ef0246d02d92f4c69a518f6a","200a5d7c7fa6d90f1d6c71edca6c0da55e74ad1cc60a6feb212c8aec15d34ab631a2e5cdc159f52df64058166250d439f8c3ab258ca308eb659119bbf55b469fbc"]}}
    th_a  transaction_evaluation_state.cpp:218 evaluate

    {"trx_num":0}
    th_a  chain_database.cpp:550 apply_transactions                     chain_database.cpp:817
20140711T010615.549060       th_a           push_block ] attempt to switch to fork failed: 30007 duplicate_transaction: duplicate transaction

    {"trx_id":"12c892efad26a84c73a9271d2b0469b99645d7fe"}
    th_a  transaction_evaluation_state.cpp:189 evaluate


This looks like a very solid bug to track down...  Can you export your fork graph from block 9650 to 6750 and provide the output from blockchain_list_forks?

no fork from block 9650.

Code: [Select]

.....
           9534
     1cfdf7b637c77c1da5e72f216ca09e43690f3193              xeroc-delegate-9              6      1646 2014-07-10T07:35:10     62605     YES                 YES
     4594dd04d3ac9cbdb13003767df7c04a50cbc209                       vikram1             28      7014 2014-07-10T07:35:20     62595     N/A                  NO
           9543
     425460964f600c17f0ef1cbb3ce107ad9af3c0a7                        betax2              3       914 2014-07-10T07:37:20     62475     YES                 YES
     8155561bf3b26350b71ed7e7cdaed1897652fb7a                      vikram10              0       182 2014-07-10T07:37:40     62456     N/A                  NO
           9544
     decf369a504295b2408062714f259463f9045bca                        xeldal             62     19054 2014-07-10T07:37:30     62467     YES                 YES
     ab742689866ce3ad1b3c41a0a42e79e00acf9d2d                      vikram12              0       182 2014-07-10T07:41:50     62206     N/A                  NO
Actually, switch fork is called here not because of a real fork.
This happened when I just begin the program.
It begin to fetch block from very early.
then  it  reached to block 9661("76fdaa3232590335bace099a977c31a36327a4ef"), and have commit block 9661 to the chain.
then it get another two block: ["c91e6df277471ad7654273370452f783e78c9cb5","3c5a66fe4b06a2b7798d8c167bddf472d3dc847a",] ,
when merge block "3c5a66fe4b06a2b7798d8c167bddf472d3dc847a", it failed with duplicate transaction.

[bitmeat]

W00t!!! Curious what it was. Link to change that fixes it in github?

[bytemaster]

Valgrind does not like how FC manipulates the stack pointer for cooperative multitasking.


Sent from my iPhone using Tapatalk

It's so hard to find the memory problem. 

We have fixed the memory leak as well as the file handle leak. 

[bytemaster]

don't know if it's a known issue.
my client failed to  sync blocks at block 9661.
from the logs, switch fork failed because of detected duplicate transaction

Code: [Select]

20140711T010615.408801       th_a       switch_to_fork ] switch from fork 76fdaa3232590335bace099a977c31a36327a4ef to c91e6df277471ad7654273370452f783e78c9cb5         chain_database.cpp:497
20140711T010615.408824       th_a     get_fork_history ]                        chain_database.cpp:842
20140711T010615.408899       th_a     get_fork_history ] return: ["c91e6df277471ad7654273370452f783e78c9cb5","3c5a66fe4b06a2b7798d8c167bddf472d3dc847a","76fdaa3232590335bace099a977c31a36327a4ef"]                     chain_database.cpp:863
20140711T010615.408930       th_a       switch_to_fork ]     extend 3c5a66fe4b06a2b7798d8c167bddf472d3dc847a                    chain_database.cpp:507
20140711T010615.410323       th_a   apply_transactions ] Applying transactions from block: 9662                 chain_database.cpp:517
20140711T010615.410544       th_a         extend_chain ] error applying block: 30007 duplicate_transaction: duplicate transaction

    {"trx_id":"12c892efad26a84c73a9271d2b0469b99645d7fe"}
    th_a  transaction_evaluation_state.cpp:189 evaluate

    {"trx":{"expiration":"20140710T094537","delegate_slate_id":null,"operations":[{"type":"withdraw_op_type","data":{"balance_id":"XTSJa6bm5iPYsahikNECLr2k17gwWicnEUjm","amount":10000,"claim_input_data":""}},{"type":"withdraw_op_type","data":{"balance_id":"XTSBmdRD4rigXPmn6VjJVdydaNnq15SfzzAm","amount":10000,"claim_input_data":""}},{"type":"deposit_op_type","data":{"amount":10000,"condition":{"asset_id":0,"delegate_slate_id":7694373846492465735,"type":"withdraw_signature_type","data":{"owner":"XTS6gvyPkLeERzaNuP1JR5vrdW54skHzHJ56","memo":{"one_time_key":"XTS7D5HyiW6wPbHNbYzhYRhRG1hTfeBrDcHTm1W9Pq6VPHAg6hLLP","encrypted_memo_data":"d89b7e926009b356d23df76860e902952d435b0df62db29d723fdee18f916cd25ea576a06ecfddeeb8b34c70953b17d6f873e6c661a5ad534feb8f5d4f85a62f"}}}}}],"signatures":["20d7aee2566b2513d5d6f5ae3681c0e5fe9db4331343dd9e8e9e1cae61fec6c14ce053116fcf6744c946646cd1c7df4172e5cec953ef0246d02d92f4c69a518f6a","200a5d7c7fa6d90f1d6c71edca6c0da55e74ad1cc60a6feb212c8aec15d34ab631a2e5cdc159f52df64058166250d439f8c3ab258ca308eb659119bbf55b469fbc"]}}
    th_a  transaction_evaluation_state.cpp:218 evaluate

    {"trx_num":0}
    th_a  chain_database.cpp:550 apply_transactions                     chain_database.cpp:817
20140711T010615.549060       th_a           push_block ] attempt to switch to fork failed: 30007 duplicate_transaction: duplicate transaction

    {"trx_id":"12c892efad26a84c73a9271d2b0469b99645d7fe"}
    th_a  transaction_evaluation_state.cpp:189 evaluate


This looks like a very solid bug to track down...  Can you export your fork graph from block 9650 to 6750 and provide the output from blockchain_list_forks?

[alt]

Valgrind does not like how FC manipulates the stack pointer for cooperative multitasking.


Sent from my iPhone using Tapatalk

It's so hard to find the memory problem. 

[alt]

don't know if it's a known issue.
my client failed to  sync blocks at block 9661.
from the logs, switch fork failed because of detected duplicate transaction

Code: [Select]

20140711T010615.408801       th_a       switch_to_fork ] switch from fork 76fdaa3232590335bace099a977c31a36327a4ef to c91e6df277471ad7654273370452f783e78c9cb5         chain_database.cpp:497
20140711T010615.408824       th_a     get_fork_history ]                        chain_database.cpp:842
20140711T010615.408899       th_a     get_fork_history ] return: ["c91e6df277471ad7654273370452f783e78c9cb5","3c5a66fe4b06a2b7798d8c167bddf472d3dc847a","76fdaa3232590335bace099a977c31a36327a4ef"]                     chain_database.cpp:863
20140711T010615.408930       th_a       switch_to_fork ]     extend 3c5a66fe4b06a2b7798d8c167bddf472d3dc847a                    chain_database.cpp:507
20140711T010615.410323       th_a   apply_transactions ] Applying transactions from block: 9662                 chain_database.cpp:517
20140711T010615.410544       th_a         extend_chain ] error applying block: 30007 duplicate_transaction: duplicate transaction

    {"trx_id":"12c892efad26a84c73a9271d2b0469b99645d7fe"}
    th_a  transaction_evaluation_state.cpp:189 evaluate

    {"trx":{"expiration":"20140710T094537","delegate_slate_id":null,"operations":[{"type":"withdraw_op_type","data":{"balance_id":"XTSJa6bm5iPYsahikNECLr2k17gwWicnEUjm","amount":10000,"claim_input_data":""}},{"type":"withdraw_op_type","data":{"balance_id":"XTSBmdRD4rigXPmn6VjJVdydaNnq15SfzzAm","amount":10000,"claim_input_data":""}},{"type":"deposit_op_type","data":{"amount":10000,"condition":{"asset_id":0,"delegate_slate_id":7694373846492465735,"type":"withdraw_signature_type","data":{"owner":"XTS6gvyPkLeERzaNuP1JR5vrdW54skHzHJ56","memo":{"one_time_key":"XTS7D5HyiW6wPbHNbYzhYRhRG1hTfeBrDcHTm1W9Pq6VPHAg6hLLP","encrypted_memo_data":"d89b7e926009b356d23df76860e902952d435b0df62db29d723fdee18f916cd25ea576a06ecfddeeb8b34c70953b17d6f873e6c661a5ad534feb8f5d4f85a62f"}}}}}],"signatures":["20d7aee2566b2513d5d6f5ae3681c0e5fe9db4331343dd9e8e9e1cae61fec6c14ce053116fcf6744c946646cd1c7df4172e5cec953ef0246d02d92f4c69a518f6a","200a5d7c7fa6d90f1d6c71edca6c0da55e74ad1cc60a6feb212c8aec15d34ab631a2e5cdc159f52df64058166250d439f8c3ab258ca308eb659119bbf55b469fbc"]}}
    th_a  transaction_evaluation_state.cpp:218 evaluate

    {"trx_num":0}
    th_a  chain_database.cpp:550 apply_transactions                     chain_database.cpp:817
20140711T010615.549060       th_a           push_block ] attempt to switch to fork failed: 30007 duplicate_transaction: duplicate transaction

    {"trx_id":"12c892efad26a84c73a9271d2b0469b99645d7fe"}
    th_a  transaction_evaluation_state.cpp:189 evaluate


[cass]

thx

[liondani]

XTS59mt5n3gJDLtTG7Je2Lpcf7SWpq2Ec8gynoQzPh7zeBkKpB6cf some funds pls ..thx

sent you 888 XTS

[cass]

XTS59mt5n3gJDLtTG7Je2Lpcf7SWpq2Ec8gynoQzPh7zeBkKpB6cf some funds pls ..thx

[bytemaster]

Valgrind does not like how FC manipulates the stack pointer for cooperative multitasking.


Sent from my iPhone using Tapatalk

[alt]

Eric has put in a temporary hack that solves the connection issues by immediately closing the socket.  We are tracking down a much deeper bug that is causing the slow memory leak / destructor not to be called.

Do you use  valgrind to help memory debug?
I have try to start with valgrind, but program quit with segment fault.

Code: [Select]

alt@alt-ThinkPad-T430s ~/workspace/bitshares_toolkit/build/programs/client $ valgrind --tool=memcheck --leak-check=full --log-file=/tmp/log.txt ./bitshares_client --data-dir data   
Loading blockchain from "data/chain"
Loading config "data/config.json"
Not starting RPC server, use --server to enable the RPC interface
Attempting to map P2P port 8801 with UPNP...
Listening for P2P connections on port 8801
Attempting to connect to peer 107.170.30.182:8801
Attempting to connect to peer 107.170.30.182:8802
Attempting to connect to peer 107.170.30.182:8803
(wallet closed) >>> Segment fault(core dump)
from the output file log.txt, I can get some error, but have not  catch memory leak yet.

Code: [Select]

==2801==    at 0xC26F3B: jump_fcontext (in /home/alt/workspace/bitshares_toolkit/build/programs/client/bitshares_client)
==2801==  Address 0x40cefc0 is not stack'd, malloc'd or (recently) free'd
....
==2801== Use of uninitialised value of size 8
==2801==    at 0x62F85D: fc::thread::wait_until(fc::shared_ptr<fc::promise_base>&&, fc::time_point const&) (thread.cpp:357)
==2801==    by 0x63525F: fc::promise_base::_wait_until(fc::time_point const&) (future.cpp:57)
==2801==    by 0x635434: fc::promise_base::_wait(fc::microseconds const&) (future.cpp:47)
.....
==2801== Syscall param futex(futex) contains uninitialised byte(s)
==2801==    at 0x545108A: __lll_unlock_wake (lowlevellock.S:371)
==2801==    by 0x544D8A3: _L_unlock_722 (pthread_mutex_unlock.c:87)
==2801==    by 0x544D7F2: pthread_mutex_unlock (pthread_mutex_unlock.c:57)
==2801==    by 0x632E39: boost::cv_status boost::condition_variable::wait_until<boost::chrono::steady_clock, boost::chrono::duration<long, boost::ratio<1l, 1000000000l>
 > >(boost::unique_lock<boost::mutex>&, boost::chrono::time_point<boost::chrono::steady_clock, boost::chrono::duration<long, boost::ratio<1l, 1000000000l> > > const&) (
thread_data.hpp:207)
==2801==    by 0x634469: fc::thread_d::process_tasks() (thread_d.hpp:439)
==2801==    by 0x6344B5: fc::thread_d::start_process_tasks(long) (thread_d.hpp:352)
...
==2801== Process terminating with default action of signal 11 (SIGSEGV)
==2801==  Access not within mapped region at address 0x53BEBA55


[vikram]

Eric has put in a temporary hack that solves the connection issues by immediately closing the socket.  We are tracking down a much deeper bug that is causing the slow memory leak / destructor not to be called.

I believe this has now been fixed in the latest code.

[liondani]

Why are missing so many blocks?

[vikram]

I have pushed a change allowing genesis claims to show in your transaction history. The necessary wallet transaction record change may result in your transaction history displaying ERROR for old transactions. If you want to get rid of it, a wallet rescan should get rid of these errors. Note that genesis claim transactions shown will also probably have your current balance rather than the initial amount claimed, if you have already withdrawn this money to somewhere else. This is due to the claim transaction being added mid-chain; the correct original claim amount will be shown for all future chains