Manually Banning Peers Results in Crash #29916
Comments
|
2024-04-19T18:42:06Z Bitcoin Core version v27.0.0 (release build) |
I'll try to reproduce the issue. Meanwhile, would you please be more specific regarding
If you're using pre-built binaries, where they were downloaded from? |
I downloaded them directly from https://bitcoincore.org/bin/bitcoin-core-27.0/ I also thought maybe it was something with those so I then compiled on my own as well using WSL and encountered the same issue. Both give the same error, the prebuilt binary was also blocked by Windows Defender in the latest build of Windows 11 for containing a "keylogger" so I whitelisted it in Defender but haven't seen an issue like that in a really long time. It doesn't happen 100% of the time so it might take a while to reproduce, it is a strange one. |
Then I suggest to remove the word "Serious" from the issue title :) |
I can do that but it pretty serious when it requires a restart every few hours because I have to ban a very serious bad actor from causing a massive DDOS against my node, but I will remove it for the time being. I imagine others will be reporting the same issue. |
iotamega
changed the title
|
Your log shows a non-default number of connections:
However, it does not mention the |
I am passing a higher maxconnections option because I operate a large number of nodes. I can likely lower that if we believe it is having an impact as I just selected an arbitrary high number because usually I just let these run endlessly until the next release and it was common to eventually hit the 125 limit and for my nodes to not be able to connect back on this one. Not every node I am operating is running this passed option. I'm not sure if it actually will even go as high as 422 to be frank with you. |
Is the issue reproducible when you're using
How? |
I haven't tried from the console but will next time I come across one of these fake clients trying to overwhelm my node which seemingly happens every few hours. After I had issues with the binary I downloaded the source and compiled and changed the option in the source for maxconnections. The issue existed in both the binary and my recompiled version so I don't believe this option is having an impact but if you think it is, I can switch back to the binary one (which also throws a virus warning now that it didn't before but I know that is a false positive) and not have this option as I don't believe I really need that many connections but when I come back to this node and find tons of fake connections from known bad ASNs taking the slots it seemed easier to just increase the number in the source. Could that be having this impact? I'm not sure how it would to be honest with you, but this was the thing I changed to solve another issue I have been having for months with these bad "nodes". I was having this same issue with the prebuilt binaries as well. |
|
Just updating to add that using the RPC method does not cause a crash further making me think this is QT related somehow. Edit: Will use the RPC method for the time being to avoid the crash across all clients and will see about testing on more machines to see if I can track down anything additional that might help with troubleshooting. |
|
Having this same issue. Where do I find my logs? |
|
It could make sense to run this in a debugger (such as gdb) to get a stacktrace, but I am not sure what debuggers exist on Windows. |
|
Hate to be the deliverer of bad news but I am also experiencing this issue on my Ubuntu installations after extensive testing. Edit: Editing title to reflect. |
iotamega
changed the title
|
On Ubuntu it should be trivial to run in gdb, can you try that please? |
I just tried in out under ubuntu, and banning both single and multiple peers worked fine. |
I'd say it happens perhaps 10% of the time, I can ban 100 peers without an issue before it crops up. I operate more than fifty nodes at this point and pruning them daily gives me some insight to this issue. It isn't a frequent occurrence but it is an occurrence that was not happening in the previous version of Core. |
|
I decided to try on my ubuntu machine as well and had this same issue but I am not a power user by any means. I will look up this gdb thing to see if I can get a log. |
|
That screenshot looks like a CPU-eating bug in the gui code. I think "not responding" is different from "crash". In any case, if this really is a crash, you can get the traceback with something like: Then recreate the crash and check the output in the terminal. |
|
Does the issue happen with Bitcoin Core v26.1, v25.2? |
I don't know, I can download one of those. I am likely just giving up though as this network seems to be full of spam trash nodes that seem intent on just overwhelming machines. I have spent all day banning peers that are sending gigs of data even though I am fully synced and wasting my bandwidth. Edit: They are all the same "satoshi finance" which seems like an outright scam based on the website. |
|
Could this be a race between "clicking on the peer to ban it in the GUI" and "the peer disconnecting"? |
I thought the same last week and tried to reproduce it with node by adding a sleep after a node disconnected, but didn't manage to reproduce the crash (I might have put the sleep in the wrong place though...). |
|
Did anyone that could reproduce, try to reproduce in gdb? #29916 (comment) |
Is there an existing issue for this?
Current behaviour
Both the pre-built binaries and manually compiling from source give the same issues with v27.
Very serious crashes that entirely lockup the client and require a force restart across both Windows 10 and Windows 11 across multiple machines. The issue does not happen on my Ubuntu machines and it seems to only be happening with my Windows based machines.
Have tried opening this ticket many times now but my logs never fit. Can provide them but they provide nothing of note anyways as the client crashes and Windows closes Core before it can write to the log the issue, but the issue seems QT driven so I'm not sure it would even show up in the log anyways.
Issue seems to happen the most when banning bad behaving peers manually.
Expected behaviour
To be able to right click and ban known bad acting peers without a crash.
Steps to reproduce
Right click on a bad actor peer and ban them, immediate lockup across MULTIPLE systems and both Windows 10 and Windows 11.
Relevant log output
Can include in a comment as each time I have tried to make this issue (more than ten times now) I am unable to include the log because it exceeds the comment length.
How did you obtain Bitcoin Core
Other
What version of Bitcoin Core are you using?
v27 both pre-built and manually compiled, same issue.
Operating system and version
Windows 10 and Windows 11
Machine specifications
No response
The text was updated successfully, but these errors were encountered: