 Show Posts
|
|
Pages: [1]
|
|
Thanks for the explanation, that makes sense. The error message made me suspect some issue with Segwit implementation but I did not know or understand the details. You've made it clear.
The latest interpreter-fix branch synced up immediately without crashing and has been running for a while now. So it seems to be fixed at least as far as I can tell. If it crashes again I will post but it has not behaved this well (staying connected, receiving new blocks over time) in all my tests so far. Good work figuring that one out.
Edit:
Still works fine. Also built fine with updated makefile. Problems resolved.
Cannot send you BCT message because newbie status. Cannot send discord message as your server requires phone verification; I won't provide that.
Ultimately you fixed the bug, I just reported it, so PHoKcBCcoWCToPyzh3AFDj1qQ3zZxwYgve (I think solicited non-incentivized non-giveaway address is fine?) or faucet it. thanks =)
|
|
|
|
|
What I am saying is, is if -reindex is specified at all, Actiniumd will crash at the same block height posted above. txindex does not matter, on or off it will crash. Sometimes I can get an initial sync to work with it but usually it will crash. After initial sync, any future run of the software even without -reindex (as should normally be done) will crash.
I have tried initial sync with -reindex -txindex, only running -txindex later, it eventually crashes / quits shortly after launch just like before.
|
|
|
|
|
Was able to build the Synchronization-Fix tag on my system (with shared libs, had to specify LIBS="-lcap -lcrypto -llzma -lseccomp" with Actinium to build with shared Tor), tested, and it works fine after a sync from network. However any use of reindex will cause it to fail again, or fail initially if specified. I am up and running at the moment, but anything that could cause reindexing (daemon crash or unexpected stop, unexpected system reboot, etc) will trigger this again.
Thanks for looking into this.
EDIT: spoke too soon, after a while it crashed with the same error again, with no corresponding debug entries - just connection logs.
|
|
|
|
But, we are not here to discuss how we have to talk to our users. Until now every user that had problems with syncing the chain could solve this problem by following the solution I gave you:
a) delete everything in .actinium folder except your wallet.dat (not even Actinium.conf should remain there).
Done b) Start the Daemon with the flags -daemon -server -txindex -reindex -port=4334 -rpcport=2300 -rpcuser=user1 -rpcpassword=blah -rpcallowip=127.0.0.1 Done c) Wait for the sync to complete (you can run tail -f $HOME/.actinium/debug.log to watch the sync) 2018-08-20 07:41:58 UpdateTip: new best=157ae2747c02ea67ebd21fcd16efd3f0ce1dd4a306f106e20ee7971105a6f510 height=64516 version=0x60000000 log2_work=59.373545 tx=76017 date='2018-08-03 11:03:48' progress=0.839189 cache=13.3MiB(102548txo)
2018-08-20 07:41:58 UpdateTip: new best=8997d42b7d6a098984d455bd2c7b0b2ad797c59e31f04423c96ce208e9e1d65d height=64517 version=0x60000000 log2_work=59.373546 tx=76018 date='2018-08-03 11:05:55' progress=0.839202 cache=13.3MiB(102549txo)
2018-08-20 07:41:58 UpdateTip: new best=42682530d0db8b6de2eac6da7a0ce8f606ead1f0330de2ee9ccf9f8f66fdefb9 height=64518 version=0x60000000 log2_work=59.373546 tx=76019 date='2018-08-03 11:06:58' progress=0.839210 cache=13.3MiB(102550txo)
2018-08-20 07:41:58 UpdateTip: new best=a9db26b1a2b69b5ebb7d611002ff147f541a0086482c2590a2ddcbe874e054a1 height=64519 version=0x60000000 log2_work=59.373547 tx=76020 date='2018-08-03 11:08:01' progress=0.839218 cache=13.3MiB(102551txo)
2018-08-20 07:41:58 UpdateTip: new best=b310c459e0d09caa49eafe455a4659641ac99fb6bce3993dd13e77a5e58c5c77 height=64520 version=0x60000000 log2_work=59.373547 tx=76021 date='2018-08-03 11:09:47' progress=0.839229 cache=13.3MiB(102552txo)
2018-08-20 07:41:58 UpdateTip: new best=57246d84152fe24e61b76e70256bc3ec49d9f6750536dd0ca06a5d4dfd705ff5 height=64521 version=0x60000000 log2_work=59.373548 tx=76022 date='2018-08-03 11:12:14' progress=0.839245 cache=13.3MiB(102553txo)
Actiniumd: script/interpreter.cpp:1551: size_t CountWitnessSigOps(const CScript&, const CScript&, const CScriptWitness*, unsigned int): Assertion `(flags & SCRIPT_VERIFY_P2SH) != 0' failed. After the sync completes you can send commands to the daemon with Actinium-cli (this is the reason I wrote extra RPC flags, so you can still command the daemon as there is no Actinium.conf). I understand what a command line argument is, and what Actinium.conf is for; regardless, following the above still results in the same outcome: Actiniumd has crashed Have you executed all steps exactly?
Yes, I don't know how I can be any more clear. I would not be posting saying I have done it for several posts now if it worked. |
|
|
|
I have started Actinium with no flags, with any flags, with no other config - though this should not matter, ultimately it does not matter, it will always crash / quit at the same point. Upon scan of the chain, once this height is reached, the software crashes. This happens from the bootstrap, from the network, or from my old previously working chain. The software does not remain running. Upon relaunching Actiniumd the same issue will occur. The daemon cannot be used with the active chain. Debug entries before crash: 2018-08-20 07:41:58 UpdateTip: new best=157ae2747c02ea67ebd21fcd16efd3f0ce1dd4a306f106e20ee7971105a6f510 height=64516 version=0x60000000 log2_work=59.373545 tx=76017 date='2018-08-03 11:03:48' progress=0.839189 cache=13.3MiB(102548txo)
2018-08-20 07:41:58 UpdateTip: new best=8997d42b7d6a098984d455bd2c7b0b2ad797c59e31f04423c96ce208e9e1d65d height=64517 version=0x60000000 log2_work=59.373546 tx=76018 date='2018-08-03 11:05:55' progress=0.839202 cache=13.3MiB(102549txo)
2018-08-20 07:41:58 UpdateTip: new best=42682530d0db8b6de2eac6da7a0ce8f606ead1f0330de2ee9ccf9f8f66fdefb9 height=64518 version=0x60000000 log2_work=59.373546 tx=76019 date='2018-08-03 11:06:58' progress=0.839210 cache=13.3MiB(102550txo)
2018-08-20 07:41:58 UpdateTip: new best=a9db26b1a2b69b5ebb7d611002ff147f541a0086482c2590a2ddcbe874e054a1 height=64519 version=0x60000000 log2_work=59.373547 tx=76020 date='2018-08-03 11:08:01' progress=0.839218 cache=13.3MiB(102551txo)
2018-08-20 07:41:58 UpdateTip: new best=b310c459e0d09caa49eafe455a4659641ac99fb6bce3993dd13e77a5e58c5c77 height=64520 version=0x60000000 log2_work=59.373547 tx=76021 date='2018-08-03 11:09:47' progress=0.839229 cache=13.3MiB(102552txo)
2018-08-20 07:41:58 UpdateTip: new best=57246d84152fe24e61b76e70256bc3ec49d9f6750536dd0ca06a5d4dfd705ff5 height=64521 version=0x60000000 log2_work=59.373548 tx=76022 date='2018-08-03 11:12:14' progress=0.839245 cache=13.3MiB(102553txo)
Actiniumd: script/interpreter.cpp:1551: size_t CountWitnessSigOps(const CScript&, const CScript&, const CScriptWitness*, unsigned int): Assertion `(flags & SCRIPT_VERIFY_P2SH) != 0' failed. The issue with the release notes is the language of "weird error" which does not really reflect an actual error. The error is not weird. It is understandable and that is why I am writing about it here, because I have not developed this coin or worked with any Segwit code. |
|
|
|
|
For the record, there is nothing to "click" here - the daemon Actiniumd crashes, and does not post crash information in debug log. The software is not acting normally, it is crashing / quitting. This is not an annoyance; rather, the software is not functioning at all. Just thought I would further clarify, I thought it was clear in the original bug report.
And again, this is a Segwit-enabled tag, with no existing blockchain. This happens on initial sync. This also happened with an existing chain.
Following your instructions, and the FAQ instructions, poses the same problem: the software still crashes, it is still unusable.
Attempting to load with bootstrap.dat, Actiniumd still continues to crash at 64521 height reliably.
Please see the bug report I posted, and let me know if there is anything further I can try / debug. I am competent and willing, do not fear using technical language or tools.
I did not originally notice any instructions regarding this situation, thus my post. I do see now the FAQ entry "My wallet is crashing with a weird message!" but I did not notice because it was not the error message, I am not expecting to look for "weird message" for this issue. Considering the software will not work with the live chain at all (at least on my platform), this seems serious enough to warrant a larger notification surface than the last "FAQ" entry, or figuring out what anomaly is present here.
|
|
|
|
I can no longer run Actinium on Linux amd64. I do not know when this issue started happening, but troubleshooting I have not found a solution. This happens from fresh blockchain sync around ~55K blocks. Have also tried with new wallet with same issue. Have tried GCC 6.4 and 7.3. Code from github tag v0.17.4.0. Problem:Actiniumd crashes while syncing blockchain Steps to reproduce
git clone <actinium github>
git checkout tags/v0.17.4.0
./autogen.sh
./configure
make
src/Actiniumd
Actiniumd does not crash Actual outcomeAfter a while Actinium crashes with the following error Actiniumd: script/interpreter.cpp:1551: size_t CountWitnessSigOps(const CScript&, const CScript&, const CScriptWitness*, unsigned int): Assertion `(flags & SCRIPT_VERIFY_P2SH) != 0' failed. |
|
|
|
|
Less fuzzy is a stat reset. Why did that happen?
|
|
|
|
|
I have tested on an S9i, and perhaps some things are different, because I noticed:
1) Fans run slower, even when forced 100%, they do not hit the same speeds as with stock bmminer
2) Temps are much hotter, so it seems this is not being set correctly for S9i
|
|
|
|
No problem, though not expecting a reward for using low hashrate pool. Just want to show support to the little guys with my little rig when the big guys are unresponsive. Hoping for luck, honesty, and more hashes  |
|
|
|
|
Sorry about the late reply.
I had two of these failed PSUs, and repaired one this weekend. (The other was used for spare parts.)
The problem is a failed MOSFET on the secondary, which fails short. Thankfully the PSU has short circuit protection, that's why you hear the click. Check the output with a multimeter, you will likely see a shorted output. If so then the fault is most likely one of these MOSFETs.
This can be repaired pretty easily with a hot air rework station, some experience doing these sort of repairs, and some patience as the MOSFETs are pretty solidly soldered to the board and surrounded by large copper planes. An easy way to check to see which MOSFET failed is to probe between the gate and the drain or source (just use a nearby heatsink); the failed MOSFET will show ~4.4ohms lower, as the working units will pass through two 2.2ohm resistors in series, the failed one will be low impedence to the source and drain. I took a working MOSFET from one failed PSU and transplanted it into another, and now I have a working PSU and another PSU for spares.
If you don't want these PSUs and still have them I can buy them, or if you have multiples I can repair them but cannot guarantee how long they will work with the stock MOSFETs, they seem to be trash. I haven't checked for what replacements will work for quality MOSFETs or the cost. Other than the shoddy MOSFETs the PSU is built decently enough.
|
|
|
|
|
