Dash Core v18.0.1 Released

[xkcd]

In what chart of mnowatch.org can we see that there was no drop in miner signalling?

It isn't published, last time I tried to install the Phez' fork explorer, but faced some issue, this time I did not bother, instead I had two simple scripts running on loop to monitor it.

unset oldblockcount;while : ;do blockcount=$(dash-cli getblockcount)&&fork=$(dash-cli getblockchaininfo)&& count=$(jq -r '.bip9_softforks.dip0024.statistics.count' <<<"$fork");if((blockcount!=oldblockcount));then echo -e "Block: $blockcount\tcount: $count";oldblockcount=$blockcount;fi;sleep 1;done

and

Next time we can look at adding fork explorer to the site.

 

[vazaki3]

Next time we can look at adding fork explorer to the site.

Yes...with v18 the proposal fee fell to 1 dash, so more governance proposals will be posed, and thus more forks will occur.
Lets add a fork explorer in mnowatch.org

 

[Figlmüller]

Looks like the latest update to dashd (v18) reintroduced the locale issues, causing the process to terminate with:

std::terminate() called due to unhandled exception
Exception: type=std::runtime_error, what="locale::facet::_S_create_c_locale name not valid"

unless the locale is automatically set through an env variable on our machines (LC_ALL="C" && export LC_ALL)

 

[xkcd]

Looks like the latest update to dashd (v18) reintroduced the locale issues, causing the process to terminate with:

std::terminate() called due to unhandled exception
Exception: type=std::runtime_error, what="locale::facet::_S_create_c_locale name not valid"

unless the locale is automatically set through an env variable on our machines (LC_ALL="C" && export LC_ALL)

Can you elaborate on this? Is this to start the QT wallet, or a headless node? What is your current locale?

 

[thephez]

In what chart of mnowatch.org can we see that there was no drop in miner signalling?

The actual data is in the blockchain so it can be reviewed directly there. But this is my snapshot from every 15 minutes showing the number of blocks signaling in the window ("Count" column): https://keybase.pub/thephez/dash-18.0.1/dash-18-miner-update-progress.csv. You can see it charted here: https://docs.google.com/spreadsheet...03vCw2r9h5KyXR7FTyyIgmoVRg/edit#gid=452706455.

I don't see any substantial change in signaling near lock-in. In fact, all the miners could have stopped signaling the last day and it still would have locked-in because the threshold had already been achieved. The Dash_info chart can be a little misleading because it doesn't factor in the signaling windows.

 

[Figlmüller]

Can you elaborate on this? Is this to start the QT wallet, or a headless node? What is your current locale?

Sorry, I was talking about dashd and dash-cli being used headless as masternodes on Linux.
All images use en_US.UTF-8 as their locale and I have to override it to C by setting the LC_ALL env var.
Using Debian LTS (currently 10).
Related issue in bitcoin

After about when dash/darkcoin stopped linking its deps dynamically, the issue was gone. Now it has returned.

 

[bogdan_bdg]

Nothing seems to be working. I bought a 4 core VCPU with 16gb of ram. It is 2 days now and the blockchain has not been fully synced and the CPU usage is still consuming 150%. Is there something I am doing wrong?

After updating MN to 18.0.1 it got PoSe Banned. Checking the logs showed "possible database corruption". So I wiped it out and began resyncing. After two days it still wasn't resynced so I started checking deeper. What I found eventually out is that the CPU usage is not really an issue but.... apparently 4GiB of physical plus 8GiB of swap is not enough for it to complete the full sync. `dashd` keeps gradually allocating all available memory until it gets killed. This could also explain the "possible database corruption" in the first place I guess. A memory leak somewhere in the new version?

 

[Figlmüller]

After updating MN to 18.0.1 it got PoSe Banned. Checking the logs showed "possible database corruption". So I wiped it out and began resyncing. After two days it still wasn't resynced so I started checking deeper. What I found eventually out is that the CPU usage is not really an issue but.... apparently 4GiB of physical plus 8GiB of swap is not enough for it to complete the full sync. `dashd` keeps gradually allocating all available memory until it gets killed. This could also explain the "possible database corruption" in the first place I guess. A memory leak somewhere in the new version?

I also noticed that. On the first launch when building the block index, dashd would show around 5GB resident size, allocating around 10GB in total. Restarting dashd after the initial rebuild would let it return to normal levels and stop my monitoring from sending me SMS every 15 minutes x).

Also keep in mind, that Sentinel must be updated and now requires python3. You might need to rebuild your python venv!
Also note that configuring sentinel by referencing and parsing your dashd.conf is now deprecated and you're encouraged to set up environment variables instead.

 

[AgnewPickens]

@johnyj ^^^

 

[xkcd]

After updating MN to 18.0.1 it got PoSe Banned. Checking the logs showed "possible database corruption". So I wiped it out and began resyncing. After two days it still wasn't resynced so I started checking deeper. What I found eventually out is that the CPU usage is not really an issue but.... apparently 4GiB of physical plus 8GiB of swap is not enough for it to complete the full sync. `dashd` keeps gradually allocating all available memory until it gets killed. This could also explain the "possible database corruption" in the first place I guess. A memory leak somewhere in the new version?

Yep, you guessed it! A new version is coming soon, v18.0.2 which will address that issue. If you need to get around the issue for now, then just restart the dashd several times during syncing to reclaim that RAM before it crashes.

 

[thephez]

Yep, you guessed it! A new version is coming soon, v18.0.2 which will address that issue. If you need to get around the issue for now, then just restart the dashd several times during syncing to reclaim that RAM before it crashes.

Related PR: https://github.com/dashpay/dash/pull/5007

And a temporary alternative to restarting or waiting for a new version: https://github.com/dashpay/dash/issues/5012#issuecomment-1246059549

 

[bogdan_bdg]

I also noticed that. On the first launch when building the block index, dashd would show around 5GB resident size, allocating around 10GB in total. Restarting dashd after the initial rebuild would let it return to normal levels and stop my monitoring from sending me SMS every 15 minutes x).

I kept monitoring it and adding swap on-the-go. It eventually synchronised but I ended up with 16GiB of swap, out of which close to 12GiB was used. The last 4GiB I added once swap usage approached 11GiB was not touched. Anyway that's not "correct" by any means ;-) BTW - I noticed quite a bit of PoSe banned MNs populating the list recently. Related?

 

[jamesbrrwniel]

Is it just a coincidence that the percentage of the miners started falling below 80%, when the masternodes reached 80%?

it is impossible to completely exclude the transition from one activity to another

 

[bogdan_bdg]

BTW - were the mobile applications updated recently too? Where is it best to talk about them?

 

[Pasta]

The release of Dash Core 18.0.2 has been released. Please see the github release. This is an optional upgrade for those who have had issues syncing with 18.0.1 due to higher memory usage.

https://github.com/dashpay/dash/releases/tag/v18.0.2

 

[Pasta]

18.1.0 thread posted

Dash Core v18.1 Release Announcement

Dash Core v18.1 is Officially Released! Please see the github release with binaries here: https://github.com/dashpay/dash/releases/tag/v18.1.0 Feel free to ask questions here.

www.dash.org