Dry Run 8: Need for Speed

bytemaster · July 11, 2014, 02:44:26 AM

Quote from: krabbypatty on July 11, 2014, 02:36:47 AM
W00t!!! Curious what it was. Link to change that fixes it in github? :)

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

alt · July 11, 2014, 02:41:47 AM

Quote from: bytemaster on July 11, 2014, 02:28:26 AM
Quote from: alt on July 11, 2014, 02:06:11 AM
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 Expand
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 · July 11, 2014, 02:36:47 AM

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

bytemaster · July 11, 2014, 02:33:27 AM

Quote from: alt on July 11, 2014, 02:12:01 AM
Quote from: bytemaster on July 11, 2014, 12:12:55 AM
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 · July 11, 2014, 02:28:26 AM

Quote from: alt on July 11, 2014, 02:06:11 AM
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 Expand
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 · July 11, 2014, 02:12:01 AM

Quote from: bytemaster on July 11, 2014, 12:12:55 AM
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 · July 11, 2014, 02:06:11 AM

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 · July 11, 2014, 01:43:44 AM

thx

liondani · July 11, 2014, 01:43:23 AM

Quote from: cass on July 11, 2014, 01:36:20 AM
XTS59mt5n3gJDLtTG7Je2Lpcf7SWpq2Ec8gynoQzPh7zeBkKpB6cf some funds pls ..thx

sent you 888 XTS

cass · July 11, 2014, 01:36:20 AM

XTS59mt5n3gJDLtTG7Je2Lpcf7SWpq2Ec8gynoQzPh7zeBkKpB6cf some funds pls ..thx

bytemaster · July 11, 2014, 12:12:55 AM

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

Sent from my iPhone using Tapatalk

alt · July 10, 2014, 11:57:56 PM

Quote from: bytemaster on July 10, 2014, 03:14:03 PM
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 · July 10, 2014, 10:06:55 PM

Quote from: bytemaster on July 10, 2014, 03:14:03 PM
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 · July 10, 2014, 09:59:45 PM

Why are missing so many blocks?

vikram · July 10, 2014, 08:49:15 PM

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