Dash Core v18.0.1 Released

xkcd

Active Member
Masternode Owner/Operator
Feb 19, 2017
463
435
133
australia
mnowatch.org
Dash Address
XpoZXRfr2iFxWhfRSAK3j1jww9xd4tJVez
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.

Code:
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

1662469998924.png


Next time we can look at adding fork explorer to the site.
 
  • Like
Reactions: vazaki3

vazaki3

Active Member
Jul 1, 2019
627
296
133
34
apogee.dynu.net
Dash Address
XnpT2YQaYpyh7F9twM6EtDMn1TCDCEEgNX
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
 
  • Like
Reactions: xkcd

Figlmüller

Member
Sep 2, 2014
88
48
58
Vienna, Austria
Looks like the latest update to dashd (v18) reintroduced the locale issues, causing the process to terminate with:


Code:
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)
 
  • Like
Reactions: stan.distortion

xkcd

Active Member
Masternode Owner/Operator
Feb 19, 2017
463
435
133
australia
mnowatch.org
Dash Address
XpoZXRfr2iFxWhfRSAK3j1jww9xd4tJVez
Looks like the latest update to dashd (v18) reintroduced the locale issues, causing the process to terminate with:


Code:
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?
 
  • Like
Reactions: AgnewPickens

thephez

Member
Dash Core Group
Jan 23, 2016
139
96
78
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.
 
  • Like
Reactions: vazaki3 and xkcd

Figlmüller

Member
Sep 2, 2014
88
48
58
Vienna, Austria
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.
 
Last edited:

bogdan_bdg

New Member
Sep 17, 2022
3
1
3
23
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?
 
  • Like
Reactions: xkcd

Figlmüller

Member
Sep 2, 2014
88
48
58
Vienna, Austria
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.
 
  • Like
Reactions: xkcd

xkcd

Active Member
Masternode Owner/Operator
Feb 19, 2017
463
435
133
australia
mnowatch.org
Dash Address
XpoZXRfr2iFxWhfRSAK3j1jww9xd4tJVez
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

Member
Dash Core Group
Jan 23, 2016
139
96
78
  • Like
Reactions: bogdan_bdg and xkcd

bogdan_bdg

New Member
Sep 17, 2022
3
1
3
23
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?
 
Last edited: