bitcoin-mine segfault when receiving SubmitSolution on release sv2-tp-0.1.11-ipc
#72
Comments
|
since |
|
actually, the fact that Pool sent multiple I raised tProxy downstream difficulty on -min_individual_miner_hashrate=10_000_000_000_000.0
+min_individual_miner_hashrate=50_000_000.0 # relatively high diff for CPU mining on a Macbook Pro M2 doing 12 kH/sas soon as Pool sends |
|
ahh, message above is also not too accurate I was able to propagate multiple blocks before breaking |
|
Thanks, I hadn't tested SubmitSolution in the "wild" myself with the last release because I had not had time to setup a custom signet. Will connect to yours and try it. |
|
I'm using |
|
It also seems like it finds one valid share |
|
I used https://github.com/pooler/cpuminer with the translator instead. It seems to work a little bit better and mine faster, though not dramatically fast. Getting about two blocks per minute. No crashes. Maybe I should try my S9 again... though last time I tried that it had difficulty with signet. |
|
Yup, my S9 with ancient BraiinsOS still trips over signet work, it just keeps rebooting. Let's try the BitAxe... |
|
make sure you get tProxy to set reasonable difficulties according to the different hashrates by tweaking otherwise you could unintentionally skew your testing and create blindspots |
|
I ended setting it to Managed to produce a crash: It seems like miner sent a solution for an earlier block here. |
|
is that related to the segfault that was originally reported on this issue? |
|
Please use That said, the "no longer in cache" message is at the |
|
So it might be a different error, though I wouldn't be surprised if it's related. I think this cache clearer prematurely. |
|
This is odd though... It seems that either the pool or the translator role is holding on to outdated templates much too long. Twenty minutes went by as I shut down the S9 and connected a BitAxe to the pool instead. It looks like it gave the same template to the BitAxe. Maybe that makes sense. The TP then creates two templates (which is strange): Four seconds later it gets a solution that references the old template:
(no that makes no sense either) In any case this shouldn't crash the TP. |
|
I restarted the node, template provider, pool, translator and the restarted the BitAxe. Now it doesn't seem to start mining. The translator occastionally logs: But AxeOS shows a hash rate of zero. |
|
When I restart the BitAxe once more I get another "[sv2] Template with id=1 is no longer in cache" crash. Again it's two The TP shouldn't crash. But I'm also suprised the BitAxe doesn't start working Maybe this is a case of the operating system or either application keeping something in the send / receive buffer a bit too long. I noticed a similar problem recently in the tests on the Bitcoin Core side. |
|
@vasild this might be the same problem I encountered here: #49 (comment) |
|
@plebhash the However you'll get a lot of stale blocks on a "fast" miner. I still need to look into what's causing the delay in new templates getting sent to the pool. Will bake a new release once that's also fixed. |
|
There's definitely something weird going on. Not sure if it's networking code though. If I run with It takes the node only two milliseconds to update the tip, plus another millisecond to construct a new template and return it via But it waits a full second before actually sending it. During that second it send a 30 seconds happens to be the default |
|
Narrowed it down a bit, the And we're holding |
|
I pushed another commit to #73 which should fix this concurrency issue. Running some more tests before baking a new release. I was able to mine 15 blocks in a row with my BitAxe without stales. I suspect it will also fix the test slowness, which I'm also checking now. |
|
@plebhash looking at your log again, I suspect you did have the same issue. It's submitting two difference nonces for the same template id, which would cause a crash. That should no longer happen, and the node should now be quicker at giving you a new template. |
|
The |
|
I found a solution for the slow tests as well, though not related to this crash. I needed to add a 1ms sleep to the main loop in |
|
Let me know if you're still seeing crashes on the last release and/or the |
|
Perfection? |
after moving on from #71 by building release tag
sv2-tp-0.1.11-ipc, I was able to successfully launchbitcoin-nodeandbitcoin-mineand connect a SRI Pool to itthen, I launched a tProxy with
config-examples/tproxy-config-local-pool-example.tomlconfig file, while changing the following:only a few seconds after launching
minerd, I could see that MULTIPLE blocks were found on Pool logs, and then Pool lost connection with TP:and
bitcoin-minebroke with a segfault:The text was updated successfully, but these errors were encountered: