Version 12.1 Release
- Thread starter eduffield
- Start date
- Status
t0dd
Active member
[NOTE: These are semi-official builds]
v0.12.1.1 tested and built for the Red Hat family of Linuxes
https://github.com/taw00/dashcore-rpm
A few have been testing early builds of 12.1.1 and I watched the release candidate on mainnet for a day+ before building the new production build.
If you are running my RPMs on 12.1.0...
If running as a systemd-managed service...
sudo systemctl stop dashd
sudo dnf upgrade -y --refresh
sudo systemctl start dashd
The order of commands is not dramatically important, but it is the cleanest method.
If running as a ~/.dashcore configured wallet or node...
So far, MUCH more stable and it syncs in a timely manner. There are a host of other improvements. For the Red Hat versions, I tweaked the default systemd config settings a bit, and I made it easy for you if you want your system to email you upon reboots, restarts, etc.
Also, Dash now builds against Fedora 26 (which is still in rawhide testing)
This was possible because someone on the core team made Dash 0.12.1.1 able to build against OpenSSL 1.1 versus the old OpenSSL 1.0. Fedora 26 defaults to v1.1. I'm sure Ubuntu will eventually move to this new and much improved OpenSSL at some point (though they tend to move slower). Therefore, Dash should be ready for the next gen version of Linux -- No, I have no idea what this means for Windows or Mac.
Happy dashing. -t
v0.12.1.1 tested and built for the Red Hat family of Linuxes
https://github.com/taw00/dashcore-rpm
A few have been testing early builds of 12.1.1 and I watched the release candidate on mainnet for a day+ before building the new production build.
If you are running my RPMs on 12.1.0...
If running as a systemd-managed service...
sudo systemctl stop dashd
sudo dnf upgrade -y --refresh
sudo systemctl start dashd
The order of commands is not dramatically important, but it is the cleanest method.
If running as a ~/.dashcore configured wallet or node...
- Shutdown wallet
....or shutdown the node: dash-cli stop - sudo dnf upgrade -y refresh
- Restart wallet
...or restart the node: dashd
So far, MUCH more stable and it syncs in a timely manner. There are a host of other improvements. For the Red Hat versions, I tweaked the default systemd config settings a bit, and I made it easy for you if you want your system to email you upon reboots, restarts, etc.
Also, Dash now builds against Fedora 26 (which is still in rawhide testing)
This was possible because someone on the core team made Dash 0.12.1.1 able to build against OpenSSL 1.1 versus the old OpenSSL 1.0. Fedora 26 defaults to v1.1. I'm sure Ubuntu will eventually move to this new and much improved OpenSSL at some point (though they tend to move slower). Therefore, Dash should be ready for the next gen version of Linux -- No, I have no idea what this means for Windows or Mac.
Happy dashing. -t
Last edited:
t0dd
Active member
Added a notice that these are unofficial builds. Which they are.
As for stopping posting these things... I have been posting these builds for close to a year with encouragement from the community and, of late, patronage from the treasury. And now, today, is the day you take exception to it? Regardless, I will talk to Flare about how to proceed, but, um... this request kinda just came out of ... where?
And, oh... ha! @flare, I didn't realized I preempted you. Apologies. I saw the official tag in github and marched forward.
Last edited:
Added a notice that these are unofficial builds. Which they are.
As for stopping posting these things... I have been posting these builds for close to a year with encouragement from the community and, of late, patronage from the treasury. And now, today, is the day you take exception to it? Regardless, I will talk to Flare about how to proceed, but, um... this request kinda just came out of ... where?
And, oh... ha! @flare, I didn't realized I preempted you. Apologies. I saw the official tag in github and marched forward.
lol
all good brother - sorry - heard as well u are doing office builds for fedora
(would be good to coordinate those with the general webpage release - then we are all on the same page )
tx
12.1.1 is out
Highly Recommended - some Bugs fixed
(12.1.0 will still be paid)
+ MN's no start-<mode> required, just replace the daemon (if running mn)
Release Notes: https://github.com/dashpay/dash/releases/tag/v0.12.1.1
please update
https://www.dash.org/wallets/
Highly Recommended - some Bugs fixed
(12.1.0 will still be paid)
+ MN's no start-<mode> required, just replace the daemon (if running mn)
Release Notes: https://github.com/dashpay/dash/releases/tag/v0.12.1.1
please update
https://www.dash.org/wallets/
Last edited:
flare
Well-known member
Yes, we are using fixed reference times to ensure deterministic builds.
--> https://github.com/dashpay/dash/blob/master/contrib/gitian-descriptors/gitian-linux.yml#L21
Every user can recreate the exact identical binaries from the source code to verify if something has been spoofed. For this to work the files need to have identical timestamps, otherwise the hashes of the tar.gz archives would be different.
holgum
New member
Thanks for clarifying!
I wouldn't have a problem with different signatures for different binaries but ok - I can see that the current mechanism would make things easier to manage.
At first I thought I goofed somewhere when I saw the file dates didn't change, so it might be something to note on the download page.
I wouldn't have a problem with different signatures for different binaries but ok - I can see that the current mechanism would make things easier to manage.
At first I thought I goofed somewhere when I saw the file dates didn't change, so it might be something to note on the download page.
I can't reproduce...
Can you please either start it with -debug=privatesend cmd-line option or switch to debug mode from console "debug privatesend"?
That should spam in debug.log a bit more and probably would help to resolve the issue when it crashes next time.
Well, at least if it's really mixing-related and not just a coincidence and you are lucky enough to catch some rare flowing bug...
How long time 12.1.0 will still be paid?
Last edited:
camosoul
Well-known member
Doing so now.
I can't reproduce...
Can you please either start it with -debug=privatesend cmd-line option or switch to debug mode from console "debug privatesend"?
That should spam in debug.log a bit more and probably would help to resolve the issue when it crashes next time.
Well, at least if it's really mixing-related and not just a coincidence and you are lucky enough to catch some rare flowing bug...
I also noticed that it likes to stop mixing on it's own. Button switches to "start mixing." As if someone clicked the button to stop, but I was nowhere near the machine for hours...
camosoul
Well-known member
Perhaps perpetually, since it looks like the bug fixes don't impact MN network service.
0.12.1.0 MNs are legit, 0.12.1.1 just has some bug fixes and performance improvements.
It could stop mixing on its own in 2 cases:
1) not enough space (~50MB free disk space is required)
2) wasn't able to create autobackup for whatever reason when wallet ran out of keys - could be permissions or (1)
You should really check logs next time it happens.
camosoul
Well-known member
I did, but since neither of those cases are true, I didn't mention.
1) Plenty of disk space.
2) I run with keypool=100000 because I have an extraordinarily huge amount of DASH, and I like my backups to actually be good for something. The crash/stop mix are happening far more frequently than the ability to run out of keys. I never run out of keys because it re-fills every time I have to restart the client.
I'm seeing nothing useful in the debug.log, but will report anyway (using -debug=privatesend on this session, so maybe we'll see something).
I also run a variety of tail -f debug | grep XXX to alert me to things I'm specifically watching for.
Speaking of, it bombed again as I was typing this.
This is the end of debug.log for 0.12.1.1 running -debug=privatesend CLI option:
Code:
2017-02-22 16:04:16 CDarksendPool::DoAutomaticDenominating -- nLowestDenom: 0.010000, nBalanceNeedsAnonymized: 999.999023
2017-02-22 16:04:16 ThreadSocketHandler -- removing node: peer=369 addr=188.40.62.22:9999 nRefCount=3 fNetworkNode=1 fInbound=0 fMasternode=1
2017-02-22 16:04:16 CDarksendPool::DoAutomaticDenominating -- 'nBalanceNeedsDenominated > 0' (999.999023 - (0.000000 + 2029.310303 - 979.899780 = 1049.410522) ) = -49.411491
2017-02-22 16:04:16 CDarksendPool::IsCollateralValid -- CTransaction(hash=d7a1e33fd8, ver=1, vin.size=1, vout.size=1, nLockTime=0)
CTxIn(COutPoint(70d5bbd9b43d4a501ff6ab48ef9c4a3b877245569b12f0fbfadf73691f6ef4c5, 0), scriptSig=47304402205926a771abe795)
CTxOut(nValue=0.00300000, scriptPubKey=76a91447951f22405304e1e0bcb7b3)
2017-02-22 16:04:16 Checking vecMasternodesUsed: size: 58, threshold: 3220
2017-02-22 16:04:16 CMasternodeMan::FindRandomNotInVec -- 3578 enabled masternodes, 3520 masternodes to choose from
2017-02-22 16:04:16 CDarksendPool::DoAutomaticDenominating -- Too early to mix on this masternode! masternode=a9778ef7410843a4634887f6cffbaa4adac05be71fb8e5ba4571ecedde217eb9-1 addr=109.235.65.95:9999 nLastDsq=44771 CountEnabled/5=715 nDsqCount=45369
2017-02-22 16:04:16 CMasternodeMan::FindRandomNotInVec -- 3578 enabled masternodes, 3519 masternodes to choose from
2017-02-22 16:04:16 CDarksendPool::DoAutomaticDenominating -- attempt 1 connection to Masternode 185.69.52.122:9999
2017-02-22 16:04:16 SOCKS5 connecting 185.69.52.122
2017-02-22 16:04:17 SOCKS5 connecting 188.227.75.148
2017-02-22 16:04:17 SOCKS5 connected 185.69.52.122
2017-02-22 16:04:20 SOCKS5 connected 188.227.75.148
dash-qt: /home/ubuntu/build/dash/depends/x86_64-unknown-linux-gnu/share/../include/boost/thread/pthread/recursive_mutex.hpp:113: void boost::recursive_mutex::lock(): Assertion `!pthread_mutex_lock(&m)' failed.
2017-02-22 16:04:20 CDarksendPool::DoAutomaticDenominating -- connected, addr=185.69.52.122:9999
2017-02-22 16:04:20 ThreadSocketHandler -- removing node: peer=370 addr=185.69.52.122:9999 nRefCount=2 fNetworkNode=1 fInbound=0 fMasternode=1You can see that PS quantity is maxed above 2k (line 3). This seems relevant to me because sessions which have PS quantity below 2k never crash. I have never seen PS pick exactly 2k, so I can only report my observations > and <, but not =. I doubt many people encounter this condition, so are not experiencing it...
I'm also using SOCKS5 proxy, but, it seems to be working perfectly fine and not relevant.
Other users might not be doing those things.
The terminal failure appears to be reported in the 3rd line from the bottom.
Last edited:
The crash is actually this failed assert
Code:
dash-qt: /home/ubuntu/build/dash/depends/x86_64-unknown-linux-gnu/share/../include/boost/thread/pthread/recursive_mutex.hpp:113: void boost::recursive_mutex::lock(): Assertion `!pthread_mutex_lock(&m)' failed.
qwizzie
Well-known member
Maybe its a Dash wallet compilation error somehow ? (assuming Camosoul compiled his Dash wallet from source), it could be interesting to see if grabbing an already pre-compiled binary would help in his case ?
It could also be interesting to see if this behaviour is only limited to that specific Ubuntu systeem, maybe try the Dash mixing of that specific wallet in a clean Ubuntu environment ? (a new virtual Ubuntu instance for example).
One last suggestion : maybe starting a new wallet and have your funds transferred to it helps ?
I'm just thinking outloud here..
It could also be interesting to see if this behaviour is only limited to that specific Ubuntu systeem, maybe try the Dash mixing of that specific wallet in a clean Ubuntu environment ? (a new virtual Ubuntu instance for example).
One last suggestion : maybe starting a new wallet and have your funds transferred to it helps ?
I'm just thinking outloud here..
Last edited:
camosoul
Well-known member
Fresh 16.04 using the official distributed binaries (my gentoo machines annoy the hell out of me already, I can't be asked to build something unless I absolutely have to).
Now that I think of it, looks like the exact same thing I reported on 0.12.1.0
I've got it going on two machines... I set them both to 2000/8. the one that keeps crashing is the one that reports overshoot above 2000. The other one is just shy of 2000 and never crashes.
Maybe those two conditions are not actually related, but I figured I'd report it.
Under what conditions is "!pthread_mutex_lock(&m)" used by dash-qt? What's it trying to do when this is called? Maybe an unexpected/out of range/unhandled/wrong type "%m" (whatever it is) is making it blow up?
Also, mixing absolutely SUCKS on 0.12.1.1... Was hauling ass on 0.12.1.0. I was unaware that anything relating to mixing was altered. Just reporting observation.
Also, an interesting observation... Even with two clients on two different machines sitting right next to each other mixing... You'd expect you might be polluting the mix by being 2 out of the 3 needed parties. I've been watching them sitting next to me as I work for a week now. I've never seen them join in on the same mix. So, it might actually not hurt anything to split your stack and denom/mix in multiple clients to speed up the process.
Now that I think of it, looks like the exact same thing I reported on 0.12.1.0
I've got it going on two machines... I set them both to 2000/8. the one that keeps crashing is the one that reports overshoot above 2000. The other one is just shy of 2000 and never crashes.
Maybe those two conditions are not actually related, but I figured I'd report it.
Under what conditions is "!pthread_mutex_lock(&m)" used by dash-qt? What's it trying to do when this is called? Maybe an unexpected/out of range/unhandled/wrong type "%m" (whatever it is) is making it blow up?
Also, mixing absolutely SUCKS on 0.12.1.1... Was hauling ass on 0.12.1.0. I was unaware that anything relating to mixing was altered. Just reporting observation.
Also, an interesting observation... Even with two clients on two different machines sitting right next to each other mixing... You'd expect you might be polluting the mix by being 2 out of the 3 needed parties. I've been watching them sitting next to me as I work for a week now. I've never seen them join in on the same mix. So, it might actually not hurt anything to split your stack and denom/mix in multiple clients to speed up the process.
Last edited:
- Status