segfault in 0.4.19

[bitcoinerS]

Don't upgrade to .19.  Clearly it has issues.

any advice on how to downgrade smoothly? Should we just relaunch 0.4.18 on an empty DB and reimport keys? I imagine that as everything is already re-indexed for 0.4.19 there is no way to downgrade this to 0.4.18 directly without wiping some indices first, right?

I downgraded to 0.4.18, but had to delete ~/.BitSharesX/chain to get it working again. 

[emski]

640000 hasn't come yet (current block is ~637725). Currently all delegates are on the same fork and there are no issues (except the segfault).
By block 640000 all(most) delegates should be on the same version.

[GaltReport]

Don't upgrade to .19.  Clearly it has issues.

any advice on how to downgrade smoothly? Should we just relaunch 0.4.18 on an empty DB and reimport keys? I imagine that as everything is already re-indexed for 0.4.19 there is no way to downgrade this to 0.4.18 directly without wiping some indices first, right?

I would suggest that if it is working for you, you should not have to downgrade but hopefully BM will weigh in.

All delegates should be on the same version. Unless we want forks.

Can't they delay planned forks ?  Not sure if that is what you are referring to or not.  I only notice that when we do upgrades their are days when people are on different versions.

Forks are hardcoded in the code for block number. Current v0.4.19 fork is scheduled for block 640000. All v0.4.19 will fork at that block. Any previous versions might not accept blocks produced by v0.4.19. That is why either all (most) of the delegates upgrade by block 640000 or none (very few) of them upgrade. Note that v0.4.19-RC1 is different version  -> it should not accept blocks by both v0.4.19 and v0.4.18.

ugh, looks like we're "f--ked"... Seems like approx. 68 active delegates are on 0.4.19.

[emski]

Don't upgrade to .19.  Clearly it has issues.

any advice on how to downgrade smoothly? Should we just relaunch 0.4.18 on an empty DB and reimport keys? I imagine that as everything is already re-indexed for 0.4.19 there is no way to downgrade this to 0.4.18 directly without wiping some indices first, right?

I would suggest that if it is working for you, you should not have to downgrade but hopefully BM will weigh in.

All delegates should be on the same version. Unless we want forks.

Can't they delay planned forks ?  Not sure if that is what you are referring to or not.  I only notice that when we do upgrades their are days when people are on different versions.

Forks are hardcoded in the code for block number. Current v0.4.19 fork is scheduled for block 640000. All v0.4.19 will fork at that block. Any previous versions might not accept blocks produced by v0.4.19. That is why either all (most) of the delegates should upgrade by block 640000 or none (very few) of them should upgrade. Note that v0.4.19-RC1 is different version  -> it should not accept blocks by both v0.4.19 and v0.4.18.

[wackou]

I would suggest that if it is working for you, you should not have to downgrade but hopefully BM will weigh in.

well, 3 crashes in less than 1 hour, reported here: https://github.com/BitShares/bitshares_toolkit/issues/834

good thing is, it helps me debug my monitoring script 

[GaltReport]

Don't upgrade to .19.  Clearly it has issues.

any advice on how to downgrade smoothly? Should we just relaunch 0.4.18 on an empty DB and reimport keys? I imagine that as everything is already re-indexed for 0.4.19 there is no way to downgrade this to 0.4.18 directly without wiping some indices first, right?

I would suggest that if it is working for you, you should not have to downgrade but hopefully BM will weigh in.

All delegates should be on the same version. Unless we want forks.

Can't they delay planned forks ?  Not sure if that is what you are referring to or not.  I only notice that when we do upgrades their are days when people are on different versions.

[emski]

Don't upgrade to .19.  Clearly it has issues.

any advice on how to downgrade smoothly? Should we just relaunch 0.4.18 on an empty DB and reimport keys? I imagine that as everything is already re-indexed for 0.4.19 there is no way to downgrade this to 0.4.18 directly without wiping some indices first, right?

I would suggest that if it is working for you, you should not have to downgrade but hopefully BM will weigh in.

All delegates should be on the same version. Unless we want forks.

[GaltReport]

Don't upgrade to .19.  Clearly it has issues.

any advice on how to downgrade smoothly? Should we just relaunch 0.4.18 on an empty DB and reimport keys? I imagine that as everything is already re-indexed for 0.4.19 there is no way to downgrade this to 0.4.18 directly without wiping some indices first, right?

I would suggest that if it is working for you, you should not have to downgrade but hopefully BM will weigh in.

[wackou]

Don't upgrade to .19.  Clearly it has issues.

any advice on how to downgrade smoothly? Should we just relaunch 0.4.18 on an empty DB and reimport keys? I imagine that as everything is already re-indexed for 0.4.19 there is no way to downgrade this to 0.4.18 directly without wiping some indices first, right?

[serejandmyself]

Don't upgrade to .19.  Clearly it has issues.

What if you already did and it's working?

or doesnt? 

[emski]

Don't upgrade to .19.  Clearly it has issues.

Should we use RC1 ? It seems stable.

[GaltReport]

Don't upgrade to .19.  Clearly it has issues.

What if you already did and it's working?

[bytemaster]

Don't upgrade to .19.  Clearly it has issues.   

[cube]

I have been running 0.4.19 for a few hours now.  So far being stable. No crash.

[GaltReport]

I'm running under this setting:

Code: [Select]

network_set_advanced_node_parameters { "peer_connection_retry_timeout": 10, "desired_number_of_connections": 10, "maximum_number_of_connections": 10 }
if that helps anyone.