BitShares Forum
Main => General Discussion => Topic started by: DACSunlimited on August 28, 2014, 02:55:03 am
-
https://github.com/dacsunlimited/bitsharesx/releases/tag/0.4.9
Re-indexing required, be careful not to make two client producing blocks the same time, otherwise we will suggest others to vote you out.
-
compiling, will be done very soon +5%
btsx.chinesecommunity
Done +5%
-
git submodule update error
fatal: reference is not a tree: b2c0ccdeda9f327bb821db6bde39f48940da0e9a
Unable to checkout 'b2c0ccdeda9f327bb821db6bde39f48940da0e9a' in submodule path 'programs/web_wallet'
-
ing
Update:
*.bts500 are on 0.4.9 now.
-
Reindexing now. I will switch block production over after a few minutes.
-
x.ebit upgraded
-
delegate.taolje ,compiling
-
Compile @ 74%
Complete. First block running 0.4.9: 335859
-
git submodule update error
fatal: reference is not a tree: b2c0ccdeda9f327bb821db6bde39f48940da0e9a
Unable to checkout 'b2c0ccdeda9f327bb821db6bde39f48940da0e9a' in submodule path 'programs/web_wallet'
I got this too. Please advise if should continue.
-
sun.delegate.service
moon.delegate.service
(old mister,and delegate.mister)
ing
-
spartako,spartako1,spartako2 updated successfully to 0.4.9
-
git submodule update error
fatal: reference is not a tree: b2c0ccdeda9f327bb821db6bde39f48940da0e9a
Unable to checkout 'b2c0ccdeda9f327bb821db6bde39f48940da0e9a' in submodule path 'programs/web_wallet'
I got this too. Please advise if should continue.
I think delegate can update, this just for the gui client
-
mr.agsexplorer
mrs.agsexplorer
boombastic
Done!
-
git submodule update error
fatal: reference is not a tree: b2c0ccdeda9f327bb821db6bde39f48940da0e9a
Unable to checkout 'b2c0ccdeda9f327bb821db6bde39f48940da0e9a' in submodule path 'programs/web_wallet'
I got this too. Please advise if should continue.
I think delegate can update, this just for the gui client
Okay, that's what I figured. Continuing....
-
git submodule update error
fatal: reference is not a tree: b2c0ccdeda9f327bb821db6bde39f48940da0e9a
Unable to checkout 'b2c0ccdeda9f327bb821db6bde39f48940da0e9a' in submodule path 'programs/web_wallet'
I got this too. Please advise if should continue.
We forgot to push the web_wallet repo, just pushed, good to continue now, just git submodule update again
-
Compiling 90%.
-
git submodule update error
fatal: reference is not a tree: b2c0ccdeda9f327bb821db6bde39f48940da0e9a
Unable to checkout 'b2c0ccdeda9f327bb821db6bde39f48940da0e9a' in submodule path 'programs/web_wallet'
try
git submodule update
again, good to continue now.
-
Updated & reindexed
delegate.coinhoarder
-
mtang.outofcontrol
update complete
hope you can vote for me :)
-
Only one connection on my delegate. Anyone have any nodes I can connect to. I don't feel comfortable switching block production with only one connection.
-
Guys, you are so agile, thanks +5%
-
dc-delegate
bitsharesx-delegate
Done! ;D
-
x.ebit Done
-
standby delegate delegate.bitder updated to 0.4.9
-
google.helloworld
microsoft.helloworld
updated to 0.4.9 +5% +5% +5%
-
kokojie updated to 0.4.9
Looks like there's a lack of connections though, I only have 2 connections.
-
Done.
delegate.bitsuperlab
delegate-alt
delegate-baozi
delegate-watchman
-
GaltReport's Delegates Upgraded to 0.4.9:
delegate1-galt
delegate1.john-galt
Please consider voting for the above very reliable delegates.
-
Done:
hear.me.roar.lion
fire.and.blood.dragon
my.watch.begins.nightswatch
-
Done.
delegate.taolje
-
sun.delegate.service
moon.delegate.service
(old mister and delegate.mister)
Done. :D
please vote me
-
updated
-
Done
-
Active:
delegate.xeldal
delegate2.xeldal
standby
delegate3.xeldal
and all others
upgraded to 0.4.9
-
riverhead-del-server-1: Updated to 0.4.9
-
delegate.adam
delegate2.adam
daslab
delegate.kettenblog
-
done
-
calabiyau & neuronics up & running, thank you for voting back in.
-
I run an instance of the client on 0.4.9.
It failed to synchronize (new data dir):
I am disconnecting peer 61.164.87.130:14953 for reason: You offered us a block that we reject as invalid
I am disconnecting peer 93.48.104.46:61603 for reason: You offered us a block that we reject as invalid
I am disconnecting peer 106.185.26.162:1776 for reason: You offered us a block that we reject as invalid
I am disconnecting peer 69.90.132.209:1028 for reason: You offered us a block that we reject as invalid
I am disconnecting peer 201.145.195.188:57116 for reason: You offered us a block that we reject as invalid
I am disconnecting peer 84.238.140.192:42577 for reason: You offered us a block that we reject as invalid
I am disconnecting peer 75.128.156.59:63559 for reason: You offered us a block that we reject as invalid
I am disconnecting peer 68.189.49.243:55044 for reason: You offered us a block that we reject as invalid
I am disconnecting peer 222.244.50.180:62998 for reason: You offered us a block that we reject as invalid
I am disconnecting peer 54.84.33.170:1776 for reason: You offered us a block that we reject as invalid
I am disconnecting peer 183.29.176.165:58582 for reason: You offered us a block that we reject as invalid
I am disconnecting peer 106.187.42.214:1700 for reason: You offered us a block that we reject as invalid
I am disconnecting peer 209.141.206.195:37960 for reason: You offered us a block that we reject as invalid
I am disconnecting peer 61.194.2.252:57304 for reason: You offered us a block that we reject as invalid
I am disconnecting peer 71.231.63.172:61488 for reason: You offered us a block that we reject as invalid
I am disconnecting peer 23.102.66.61:1344 for reason: You offered us a block that we reject as invalid
I am disconnecting peer 54.197.203.51:1700 for reason: You offered us a block that we reject as invalid
I am disconnecting peer 50.206.156.115:51949 for reason: You offered us a block that we reject as invalid
I am disconnecting peer 217.14.49.100:3137 for reason: You offered us a block that we reject as invalid
I am disconnecting peer 61.194.2.252:54546 for reason: You offered us a block that we reject as invalid
I am disconnecting peer 123.110.16.111:51728 for reason: You offered us a block that we reject as invalid
I am disconnecting peer 61.164.87.130:18211 for reason: You offered us a block that we reject as invalid
I am disconnecting peer 76.91.0.24:62318 for reason: You offered us a block that we reject as invalid
I am disconnecting peer 65.93.177.125:51319 for reason: You offered us a block that we reject as invalid
--- there are now 14 active connections to the p2p network
--- there are now 13 active connections to the p2p network
--- there are now 12 active connections to the p2p network
--- there are now 11 active connections to the p2p network
--- there are now 10 active connections to the p2p network
(wallet closed) >>> info
{
"blockchain_head_block_num": 275171,
"blockchain_head_block_age": "7 days old",
"blockchain_head_block_timestamp": "2014-08-21T01:42:30",
"blockchain_average_delegate_participation": "0.16 %",
"blockchain_confirmation_requirement": 303,
"blockchain_accumulated_fees": "222,946.50184 BTSX",
"blockchain_delegate_pay_rate": "1.84314 BTSX",
"blockchain_share_supply": "1,999,946,838.10086 BTSX",
"blockchain_blocks_left_in_round": 54,
"blockchain_next_round_time": "at least 9 minutes in the future",
"blockchain_next_round_timestamp": "2014-08-28T06:41:20",
"blockchain_random_seed": "b4800b285ee2b68ea13596bb7ba93fb8726d763c",
"client_version": "0.4.9",
"network_num_connections": 10,
"network_num_connections_max": 100,
"ntp_time": "2014-08-28T06:32:20",
"ntp_time_error": 0.016278999999999998,
"wallet_open": false,
"wallet_unlocked": null,
"wallet_unlocked_until": null,
"wallet_unlocked_until_timestamp": null,
"wallet_last_scanned_block_timestamp": null,
"wallet_scan_progress": null,
"wallet_block_production_enabled": null,
"wallet_next_block_production_time": null,
"wallet_next_block_production_timestamp": null
}
(wallet closed) >>> blockchain_list_forks
FORKED BLOCK FORKING BLOCK ID SIGNING DELEGATE TXN COUNT SIZE TIMESTAMP LATENCY VALID IN CURRENT CHAIN
--------------------------------------------------------------------------------------------------------------------------------------------------------------
275164
11af0ac74dfd49f23e6e855d2ecd09c7ba263819 btsnow 5 1727 2014-08-20T22:54:10 632274 YES YES
abd972bc55db249c13e09640fc2d5f653e0c2b8e d.dacsun 1 1463 2014-08-20T22:42:30 632974 N/A NO
blockchain_list_balances blockchain_list_blocks
(wallet closed) >>> blockchain_list_blocks
6 key_not_found_exception: Key Not Found
unable to find key 275171
{"key":275171}
th_a level_map.hpp:95 fetch
error fetching key 275171
{"key":275171}
th_a level_map.hpp:105 fetch
{"block_num":275171}
th_a chain_database.cpp:1267 get_block_id
{"block_num":275171}
th_a chain_database.cpp:1262 get_block_record
{}
th_a common_api_client.cpp:451 blockchain_list_blocks
{"command":"blockchain_list_blocks"}
th_a cli.cpp:471 execute_command
Peer 223.3.87.78:61542 disconnected us: You offered us a block that we reject as invalid
After this message there is no further synchronization.
I'll try to use the datadir of 0.4.8 and post results. However I consider this serious issue.
-
maybe try syncing from the chain server: https://github.com/BitShares/bitshares_toolkit/wiki/Using-Chain-Servers
-
maybe try syncing from the chain server: https://github.com/BitShares/bitshares_toolkit/wiki/Using-Chain-Servers
I'll sync somehow...
But what about any new user?
UPDATE: I reindexed 0.4.8 datadir and it seems OK.
-
dc-delegate
bitsharesx-delegate
Done! ;D
pls vote for me back, thanks a lot.
-
delegate.webber
upgraded,vote me back,thanks.
-
maybe try syncing from the chain server: https://github.com/BitShares/bitshares_toolkit/wiki/Using-Chain-Servers
I'll sync somehow...
But what about any new user?
UPDATE: I reindexed 0.4.8 datadir and it seems OK.
Yee I am syncing too...finally, but I do not think, I am giving back anything... I expect 700 new threads of the 'Wallet won't sync'/'Severe network problem' variety as everybody is going through the same process/again/at once.
It would very good, if everybody is using some more resource sparing method like the one in bold above.
-
Done, vote me in :)
-
*.svk31 updated and running 0.4.9
Seednode currently indexing.
-
Seed node and delegates updated.
* angel and lotto included
-
upgraded to 0.4.9
-
Delegate ID:dnsdac
upgraded to 0.4.9 and running smoothly
vote me in :D
-
Delegate ID:d.e
Delegate ID:delegate.eureka
but why not connected ？
-
done.
bts.coin
e.coin
bimin.coin
-
upgraded to 0.49
delegate ID : chinese
-
wackou-delegate on 0.4.9 too, up and running
-
updated to 0.4.9
-
Updated to 0.4.9
-
updated to 0.4.9 and running smoothly
liondani
liondani-delegate-1
please vote for
delegate.liondani
so I can remove my 2 current active delegates
-
I have created a node and chain server:
Node Server: 104.131.35.149:1776
Chain Server: 104.131.35.149:1775
-
I have created a node and chain server:
Node Server: 104.131.35.149:1776
Chain Server: 104.131.35.149:1775
Can't connect. :(
-
Can't connect. :(
Looks like my node is still syncing. Might explain a lot of issues we're seeing if most of the seeds are either pre-fork or still syncing.
"blockchain_head_block_num": 135386,
"blockchain_head_block_age": "24 days old",
"blockchain_head_block_timestamp": "2014-08-04T10:04:30",
"blockchain_average_delegate_participation": "0.05 %",
"blockchain_confirmation_requirement": 1,
"blockchain_accumulated_fees": "131,570.66965 BTSX",
"blockchain_delegate_pay_rate": "1.08772 BTSX",
"blockchain_share_supply": "1,999,970,644.53254 BTSX",
"blockchain_blocks_left_in_round": 55,
"blockchain_next_round_time": "at least 9 minutes in the future",
"blockchain_next_round_timestamp": "2014-08-28T11:28:10",
"blockchain_random_seed": "e9576da879344a18b126333ab971f57a47d4aad0",
"client_data_dir": "/home/riverhead/.BitSharesX",
"client_version": "0.4.9",
"network_num_connections": 28,
"network_num_connections_max": 100,
"ntp_time": "2014-08-28T11:19:05",
"ntp_time_error": -0.028185999999999999,
-
As I said before - sync with 0.4.8 and then use the same data-dir for 0.4.9.
-
I wonder if it would be smoother with a staggered release:
1) node/chain servers upgrade and fully snyc.
2) delegates upgrade and fully sync
3) release to masses now that infrastructure is up to date.
I know we can't wait for everyone but perhaps wait until 10 - 20 of each type to check in before updating the version on the DACSun website.
-
Anyone running a node and having it crash after a bit (perhaps due to a lot of connections) I wrote a simple script to keep it going. Now I just need to tail -f node.log in a small window to make sure it restarts itself.
screen start_node.sh
tail -f node.log
while [ 1=1 ] ; do
echo "Starting node server" >>node.log
bitshares_client
echo "Balls, crashed" >> node.log
sleep 5
done
-
Anyone running a node and having it crash after a bit (perhaps due to a lot of connections) I wrote a simple script to keep it going. Now I just need to tail -f node.log in a small window to make sure it restarts itself.
screen start_node.sh
tail -f node.log
while [ 1=1 ] ; do
echo "Starting node server" >>node.log
bitshares_client
echo "Balls, crashed" >> node.log
sleep 5
done
in short
while true; do ./bitshares_client; done
-
in short
while true; do ./bitshares_client; done
That works well too but I wanted something to watch :).
-
I wonder if it would be smoother with a staggered release:
1) node/chain servers upgrade and fully snyc.
2) delegates upgrade and fully sync
3) release to masses now that infrastructure is up to date.
I know we can't wait for everyone but perhaps wait until 10 - 20 of each type to check in before updating the version on the DACSun website.
I agree this is how it should be done. I am attempting to gain my bearings on what is going on now that I am in the office.
1) Looks like my 0.4.8 OS X GUI still has 8 connections and 97% delegate participation! Good work guys.
2) My 0.4.9 command line client (OSX) fully synced from last night, attempting a fresh sync (so far so good, 8 connections from scratch)
3) About to test out 0.4.9 OS X GUI to see where we get....
Update: fully connected from a fresh start with 7 connections. Now for the GUI.
-
delegate1.y8 have finished updated
-
doxymoron-delegate updated.
-
I wonder if it would be smoother with a staggered release:
1) node/chain servers upgrade and fully snyc.
2) delegates upgrade and fully sync
3) release to masses now that infrastructure is up to date.
I know we can't wait for everyone but perhaps wait until 10 - 20 of each type to check in before updating the version on the DACSun website.
+5%
-
maqifrnswa and delegate1.maqifrnswa are now on 0.4.9
-
I have created a node and chain server:
Node Server: 104.131.35.149:1776
Will you be keeping this up so that we can add to the list of default seed nodes?
-
I have created a node and chain server:
Node Server: 104.131.35.149:1776
Will you be keeping this up so that we can add to the list of default seed nodes?
Yes. I have rented another Droplet as a dedicated node and chain server. It will be funded from my delegate.
Updated max connections to 200 to help get us passed this initial sync frenzy.
-
Node Server: 188.226.195.137:60696 updated to 0.4.9
network_add_node "188.226.195.137:60696" add
{
"blockchain_head_block_num": 339290,
"blockchain_head_block_age": "2 seconds old",
"blockchain_head_block_timestamp": "2014-08-28T15:35:40",
"blockchain_average_delegate_participation": "90.18 %",
"blockchain_confirmation_requirement": 1,
"blockchain_accumulated_fees": "155,244.02643 BTSX",
"blockchain_delegate_pay_rate": "1.28343 BTSX",
"blockchain_share_supply": "1,999,930,605.40256 BTSX",
"blockchain_blocks_left_in_round": 70,
"blockchain_next_round_time": "at least 12 minutes in the future",
"blockchain_next_round_timestamp": "2014-08-28T15:47:20",
"blockchain_random_seed": "cbed8e07c7e937629f0032a484570a12202ca0ec",
"client_data_dir": "/home/ihashfury/.BitSharesX",
"client_version": "0.4.9",
"network_num_connections": 36,
"network_num_connections_max": 36,
"ntp_time": "2014-08-28T15:35:42",
"ntp_time_error": -0.0016199999999999999,
"wallet_open": true,
"wallet_unlocked": true,
"wallet_unlocked_until": "3 years 2 months in the future",
"wallet_unlocked_until_timestamp": "2017-10-28T20:08:40",
"wallet_last_scanned_block_timestamp": "2014-08-27T15:52:40",
"wallet_scan_progress": "? %",
"wallet_block_production_enabled": true,
"wallet_next_block_production_time": null,
"wallet_next_block_production_timestamp": null
}
-
www.minebitshares-com
www2.minebitshares-com
Delegates now upgrades to 0.4.9
-
Anyone running a node and having it crash after a bit (perhaps due to a lot of connections) I wrote a simple script to keep it going. Now I just need to tail -f node.log in a small window to make sure it restarts itself.
screen start_node.sh
tail -f node.log
while [ 1=1 ] ; do
echo "Starting node server" >>node.log
bitshares_client
echo "Balls, crashed" >> node.log
sleep 5
done
in short
while true; do ./bitshares_client; done
+5% +5% +5%, this will make life easier for the guys running seed nodes.
-
any particular reason that I have been voted out?
-
any particular reason that I have been voted out?
(mine too) look like a bunch of inits were brought in
-
same here ..
-
He got me back in. Just make sure he knows you're updated. In the future we should have the tell us when you're updated thread list all the delegates that have updated in the first post. I think Dan is busy enough already without having to wade through six pages of a thread to see who is ready.
-
I wanted to error on the safe side...
-
He got me back in. Just make sure he knows you're updated. In the future we should have the tell us when you're updated thread list all the delegates that have updated in the first post. I think Dan is busy enough already without having to wade through six pages of a thread to see who is ready.
- good point
- mine are not yet up ..
- I like how BM has "everything under control" ;-)
- hard fork is gone .. 90+% participation .. nice and smooth :)
-
Someone needs to collect all the data and update that post.
Usually the original poster is DACSUnlimited so that might not be viable also.
Perhaps second or third post should contain all updated nodes.
BTW: *.bitdelegate are prepared.
PS: What about google spreadsheed containing delegate availability + version
-
And another issue:
You cant publish price feed if you are not an active delegate.
If you are voted out (or in) what happens to your last feed?
Is it possible for non-active delegates to publish feed (on standby)?
-
PS: What about google spreadsheed containing delegate availability + version
It looks like they're adding that function to the client
https://github.com/BitShares/bitshares_toolkit/issues/710
-
Producing blocks again - voting appreciated +5%
-
any particular reason that I have been voted out?
(mine too) look like a bunch of inits were brought in
Me as well.
Please vote me back in.
-
delegate name:
hongkong
usa
both are running on version 0.49
In what way you are you associated with dacsunlimited ?
-
In what way you are you associated with dacsunlimited ?
nothing to do with dacsunlimited. we are using dacsunlimited.com
thanks
-
Compile @ 74%
Complete. First block running 0.4.9: 335859
Just a bump to the above notice as I was purged. My 0.4.9 node is awaiting votes to resume block production.
Thanks,
Fox
-
please vote me back in: happyshares-2 @0.4.9
thanks
-
skyscraperfarms is back in the game!
Vote me back in please!
Do the forks purposely purge all the delegates?
-
bitsapphire up and running, syncing atm
-
Getting this error after running the client for 10 mins:
--- currently syncing at 206 blocks/sec, 10 minutes remaining
--- there are now 46 active connections to the p2p network
--- there are now 47 active connections to the p2p network
--- there are now 46 active connections to the p2p network
--- there are now 47 active connections to the p2p network
--- there are now 48 active connections to the p2p network
--- there are now 49 active connections to the p2p network
--- there are now 48 active connections to the p2p network
--- there are now 47 active connections to the p2p network
bitsapphire (unlocked) >>>
Program received signal SIGSEGV, Segmentation fault.
0x000000000065e91b in fc::exception::to_detail_string (this=this@entry=0xa46a1c0, ll=..., ll@entry=...)
at /root/bitsharesx/libraries/fc/src/exception.cpp:144
144 ss << variant(my->_code).as_string() <<" " << my->_name << ": " <<my->_what<<"\n";
Any thoughts?
-
Getting this error after running the client for 10 mins:
--- currently syncing at 206 blocks/sec, 10 minutes remaining
--- there are now 46 active connections to the p2p network
--- there are now 47 active connections to the p2p network
--- there are now 46 active connections to the p2p network
--- there are now 47 active connections to the p2p network
--- there are now 48 active connections to the p2p network
--- there are now 49 active connections to the p2p network
--- there are now 48 active connections to the p2p network
--- there are now 47 active connections to the p2p network
bitsapphire (unlocked) >>>
Program received signal SIGSEGV, Segmentation fault.
0x000000000065e91b in fc::exception::to_detail_string (this=this@entry=0xa46a1c0, ll=..., ll@entry=...)
at /root/bitsharesx/libraries/fc/src/exception.cpp:144
144 ss << variant(my->_code).as_string() <<" " << my->_name << ": " <<my->_what<<"\n";
Any thoughts?
I woke up to this error this morning. I'm not sure what it is, but it made me miss 8 blocks. >:(
-
We are experiencing the same issue just attempting to get a delegate setup.
Finished scanning for new transactions.
OK
--- there are now 17 active connections to the p2p network
--- there are now 18 active connections to the p2p network
--- there are now 19 active connections to the p2p network
--- there are now 16 active connections to the p2p network
--- there are now 15 active connections to the p2p network
Scanning for new transactions in block: 187/259352actions in block: 173/259352
Program received signal SIGSEGV, Segmentation fault.
0x000000000065e91b in fc::exception::to_detail_string (
this=this@entry=0x26d8620, ll=..., ll@entry=...)
at /usr/src/bitsharesx/libraries/fc/src/exception.cpp:144
144 ss << variant(my->_code).as_string() <<" " << my->_name << ": " <<
my->_what<<"\n";
As soon as we unlock the wallet it starts scanning and will crash anywhere from 180 to 300 blocks with an error similar to this.
Ubuntu 14.04 latest and running the latest build from a few hours from now. Hardware is running ok.
What can we do for a hotfix or will there be an update?
Thanks.
-
now.dacwin
future.dacwin
updated to 0.4.9.
-
coolspeed
and
*.coolspeed
updated to 0.4.9
-
bitsapphire (unlocked) >>>
Program received signal SIGSEGV, Segmentation fault.
0x000000000065e91b in fc::exception::to_detail_string (this=this@entry=0xa46a1c0, ll=..., ll@entry=...)
at /root/bitsharesx/libraries/fc/src/exception.cpp:144
144 ss << variant(my->_code).as_string() <<" " << my->_name << ": " <<my->_what<<"\n";
I've been getting loads of these since 0.4.8, see https://github.com/BitShares/bitshares_toolkit/issues/647#issuecomment-53440518
-
My delegate also resets regularily .. :(
-
My delegate also resets regularily .. :(
Interesting thing is that my delegates are relatively (1 crash on 0.4.7?) stable with no modifications (except max_connections = 50).
-
My delegate also resets regularily .. :(
Mine has been solid as a rock but it's also behind a firewall...not sure if that's why.
-
Yhea .. maybe i should reduce the num connections too .. ill wait for the next rush so the network is stronger befoe reducing it
-
I'm not sure if the dependencies are static or not. I'll often do a apt-get update, apt-get <list of dependencies from BUILD_UBUNTU.md>. So far my delgate client hasn't seg faulted once.
bitsapphire (unlocked) >>>
Program received signal SIGSEGV, Segmentation fault.
0x000000000065e91b in fc::exception::to_detail_string (this=this@entry=0xa46a1c0, ll=..., ll@entry=...)
at /root/bitsharesx/libraries/fc/src/exception.cpp:144
144 ss << variant(my->_code).as_string() <<" " << my->_name << ": " <<my->_what<<"\n";
I've been getting loads of these since 0.4.8, see https://github.com/BitShares/bitshares_toolkit/issues/647#issuecomment-53440518 (https://github.com/BitShares/bitshares_toolkit/issues/647#issuecomment-53440518)
-
I'm not sure if the dependencies are static or not. I'll often do a apt-get update, apt-get <list of dependencies from BUILD_UBUNTU.md>. So far my delgate client hasn't seg faulted once.
bitsapphire (unlocked) >>>
Program received signal SIGSEGV, Segmentation fault.
0x000000000065e91b in fc::exception::to_detail_string (this=this@entry=0xa46a1c0, ll=..., ll@entry=...)
at /root/bitsharesx/libraries/fc/src/exception.cpp:144
144 ss << variant(my->_code).as_string() <<" " << my->_name << ": " <<my->_what<<"\n";
I've been getting loads of these since 0.4.8, see https://github.com/BitShares/bitshares_toolkit/issues/647#issuecomment-53440518 (https://github.com/BitShares/bitshares_toolkit/issues/647#issuecomment-53440518)
I also keep mine up to date... Could this be an issue?
bitsapphire - why dont you try to update and tell us the result?
-
please vote me back in: happyshares-2 @0.4.9
thanks
since 24H i'm on standby @ version 0.4.9 , please vote me in again.
thank you
-
please vote me back in: happyshares-2 @0.4.9
thanks
since 24H i'm on standby @ version 0.4.9 , please vote me in again.
thank you
Me too! I think Bytemaster was pulling most of the weight by directing his or I3 or DACsun shares towards most delegates. This is why we get purged on the forks and a lot of init-delegates are back in the mix. I'd like to get back in! Votes are obviously hard to come by for a delegate that doesn't have a huge bank roll. ;) in due time I suppose. :D
-
The segmentation error has caused quite some trouble on our part. I think weve missed quite some blocks because of it. I was wondering if there is a way to decrease the connections as a measure to stop that from happening? What would be the best way to do that?
-
The segmentation error has caused quite some trouble on our part. I think weve missed quite some blocks because of it. I was wondering if there is a way to decrease the connections as a measure to stop that from happening? What would be the best way to do that?
Same here
I had some limited success using ./bitshares_client --accept-incoming-connections=0
but the connections would slowly move from 5 initially down to zero over some variable amount of time, and I'd start missing blocks again.
I'm currently trying:
network_set_advanced_node_parameters { "peer_connection_retry_timeout": 30, "desired_number_of_connections": 25, "maximum_number_of_connections": 50 }
Its been only 5 hours or so but no segfault crash yet.
-
I see no crashes on updated ubuntu server 14.04.
I do NOT set incoming connections to 0.
I set max_connections to 50.
It hasn't crashed on 0.4.9.