segfault in 0.4.19

[liondani]

Lets update to 0.4.19...

it will be an exciting night in Greece again ! Another pizza session will not heart me I guess  :)


Sent from my ALCATEL ONE TOUCH 997D

[bytemaster]

hmmm .. 2GB is already low memory .. oha

Yes it is because we haven't taken time to optimize memory usage. 

We are keeping large portions of the blockchain database *IN RAM* for performance reasons and will probably continue to keep it in RAM long term.   Long-term light weight clients will not have the full chain and will therefore have a much smaller memory footprint and delegates can run machines with 128 GB of memory.   This will allow us to grow transaction volume and keep block latencies low.

[xfund]

0.4.19 ok

[xeroc]

hmmm .. 2GB is already low memory .. oha

three machines
XEN DomU - 2GB RAM - debian/archlinux - 64 bit

[liondani]

that's a good example why the hard fork must have a bigger block distance from the initial announcement time ...

Sent from my ALCATEL ONE TOUCH 997D

[bytemaster]

Because downgrading is so unpleasant and we want the blockchain updates asap 

Dan & Eric are looking into the crash, but those that are experiencing it could you please report the specs of the machine you are running on?
Lets update to 0.4.19...    

[bytemaster]

Updating to v0.4.19 seems reasonable to me. Segfault by itself isn't that much of a deal.
However bytemaster recommended not to update. Maybe he has other reasons?
There is still plenty of time for an informed decision. I suggest waiting for bytemaster's input and update to v0.4.19 as default option (if he is silent about this).

I agree. everyone downgrading would be very unpleasant.

There are no blockchain level bugs... we suspect that it may be low-memory machines that are crashing which is why we did not experience crashes in our own tests. 

[GaltReport]

Average confirmation time is 5 secs.  That's good.

[GaltReport]

Updating to v0.4.19 seems reasonable to me. Segfault by itself isn't that much of a deal.
However bytemaster recommended not to update. Maybe he has other reasons?
There is still plenty of time for an informed decision. I suggest waiting for bytemaster's input and update to v0.4.19 as default option (if he is silent about this).

I agree. everyone downgrading would be very unpleasant.

[svk]

Mine's been stable since the initial segfault, running v0.4.19 with 8 connections max.

I think it'll be hard to get everyone over on .18 in time, but I suggest those who want to do so re-publish their version so we can monitor the number of delegates on each side. Currently .19 is in the majority, but I'm ready to switch over if necessary.

[liondani]

It was clear enough...  everybody back to v0.4.18.  Anybody not doing it will heart his reliability statistics...  enough time for downgrading... delete your hidden directory   ".Bitsharesx "  also. After all v0.4.18 is proven stable at least since we all run it a few days...

Sent from my ALCATEL ONE TOUCH 997D

[xeroc]

BTW:

Code Select Expand


$ python3 timeofblock.py 640000
block 640000 to appear in <= 6:02:20
UTC time: 2014-10-02 19:36:10


6 hours left

[xfund]

I think:
we all  :network_set_advanced_node_parameters {"maximum_number_of_connections":10}
and wait v0.4.20

[emski]

Updating to v0.4.19 seems reasonable to me. Segfault by itself isn't that much of a deal.
However bytemaster recommended not to update. Maybe he has other reasons?
There is still plenty of time for an informed decision. I suggest waiting for bytemaster's input and update to v0.4.19 as default option (if he is silent about this).

[bitder]

I've had a single segfault but 0.4.19 has been stable otherwise.
Since the majority has already upgraded to 0.4.19 it's probably easier to commit to it. The segfault is a hassle but it seems to be harmless otherwise.
The only problem is just restarting your delegate after a segfault but that can be done automatically with HackFisher's expect script (or a slightly modified version of it)
This way we can just wait for patch releases of 0.4.19 as they are made available.
Thoughts?

https://github.com/Bitsuperlab/operation_tools.git
restart/run_wallet.exp

Code Select Expand


#!/usr/bin/expect -f

set timeout -1
set default_port 1776
set port $default_port

### change wallet_name here
set wallet_name "delegate"
send_user "wallet name is: $wallet_name\n"
send_user "wallet passphrase: "
stty -echo
expect_user -re "(.*)\n"
  stty echo
set wallet_pass $expect_out(1,string)

  proc run_wallet {} {
    global wallet_name wallet_pass default_port port
      ### change command line here
      spawn ./bitshares_client --data-dir=delegate --p2p-port $port --server --httpport 9989 --rpcuser user --rpcpassword pass

      expect -exact "(wallet closed) >>> "
      send -- "about\r"
      expect -exact "(wallet closed) >>> "
      send -- "wallet_open $wallet_name\r"
      expect -exact "$wallet_name (locked) >>> "
      send -- "wallet_unlock 99999999\r"
      expect -exact "passphrase: "
      send -- "$wallet_pass\r"
      expect -exact "$wallet_name (unlocked) >>> "
      send -- "wallet_delegate_set_block_production ALL true\r"
      expect -exact "$wallet_name (unlocked) >>> "
      send -- "info\r"
      expect -exact "$wallet_name (unlocked) >>> "
      send -- "wallet_list_my_accounts\r"
      interact
      wait

      if { $port == $default_port } {
        set port [expr $port+1]
      } else {
        set port [expr $port-1]
      }
  }

while true {
  run_wallet
}