Assertion failed: Connection reset by peer (../zeromq-4.2.3/src/signaler.cpp:357) #3540
Comments
|
The same thing just happened again. Time to turn on logging. |
|
I'm working on trying to reproduce this issue while logging at higher levels of granularity. At the default level of logging, the assertion failed errors don't even make it into the log file, for whatever reason. We've had some power outages in the area lately (but I'm running with a battery backup), so I thought it might be caused by the Internet connection dropping while the daemon is running. So, I tried yanking the Ethernet cable, but no immediate crash following that, so, still trying to determine what specifically is causing it AND get enough granularity on the log. |
|
Just crashed again, here's a snippet of log level 2 just before the crash, but nothing about ZeroMQ in the console this time, so that could be a coincidence, and nothing obviously wrong here:
|
|
Those assertion failures don't get into the log because it's the 0mq code printing those. |
|
Here's what the Windows application log says: Faulting application name: monerod.exe, version: 0.0.0.0, time stamp: 0x5aba638b |
|
I've been commenting about this issue over on another bug thread, but here's the latest info: Using gdb, it looks like the issue starts at line 46 of daemon/main.cpp, which is the include for "blockchain_db/db_types.h". I don't know how helpful that is. I tried to do a backtrace, but it says: |
|
For visibility purposes, someone else affected by the same issue: |
|
@dEBRUYNE-1 , I'm able to consistently reproduce it on one machine, but haven't been able to reproduce it on a different machine, using the same source blockchain files, which could mean that it may not be anything corrupt in the copy of the blockchain, but something specific to the hardware of the machines. (I will continue to try to reproduce it on other machines in the next few days.) Off the top of my head, specs that might matter are the differing processors -- the machine with the issue is an AMD E-350 (Windows 10 64-bit, 6GB RAM), whereas one that I haven't yet reproduced it on is an Intel i7-3635QM (Windows 10 64-bit, 8GB RAM). |
|
The other user that's experiencing this that was on Reddit states that his CPU is an Intel Core 2 Quad Q9550, so that strikes down the idea that it's some sort of Intel versus AMD processor issue. It was a shot in the dark by me. |
|
I may have found the cause and a workaround. Last night, I coincidentally discovered that my network monitoring utility, NetWorx, was acting up and affecting another application, so I closed it, and thought to run the Monero daemon to see if it might've also been interfering with it. It ran all night without crashing. I've since come across the following, where someone mentions at the bottom of the thread that NetWorx was causing this same error in a different program, where it was also somehow interfering with ZeroMQ. I don't know why this would be, and it still isn't a fix, as I'd like to be able to continue to monitor my network bandwidth usage with NetWorx while using the latest version of monero, but at least this is an area for further investigation: |
|
Also, see here, it may have to do with a TDI or WFP filter driver being used by NetWorx and other programs: microsoft/WSL#1554 (comment) They're saying that the Windows Insider preview build 17046 may contain a workaround for developers for the TDI driver, which would probably arrive in the Windows 10 April 2018 Update (already in the Insider preview), but I don't really see it as a fix, which may need to come in zeromq itself. |
|
Also, see here: zeromq/libzmq#1808 |
|
The other user on Reddit was also using NetWorx. This seems very likely to be the trigger. Hopefully, we can get some sort of fix in the zeromq libraries for this. |
|
Since it seems to be due to some network software breaking connections, it seems unrelated to monero and I'll close this. Seems OK ? |
|
Yeah, I'll close it. It's also going to take a while to get fixed on zeromq. I don't know that there's anything that Monero could do to work around it. |
|
@moneromooo-monero, this is finally said to be fixed as of yesterday in zeromq: zeromq/libzmq#1808 Is @luigi1111 the one handling Monero builds currently? Just wanted to give people a heads up. Whenever this fix gets into the zeromq release channel, I'll be interested to test it in Monero. I'll keep tabs on this and follow-up. |
|
@luigi1111 , I thought I'd come back and test this issue, as it's been a few years, and I can still reproduce the crashing with the latest version of monero. The bug was supposedly fixed in zeromq, but I have no idea what version of the zeromq libraries is currently being used in monero to rule out old libraries. |
|
We still use v4.1.7 for zeromq for release binaries. I can update it to the latest version for the next release. |
|
@selsta , did this make it into v0.17.3.0? I'm testing it, and, unfortunately, still seeing the associated crashing, so I just wanted to make sure. |
|
@mmortal03 Yes. Did you download the binary from getmonero.org? |
|
Yep, monero-win-x64-v0.17.3.0.zip. I'll have to see if I can get a screen capture of the last screen output before it crashes, as I don't believe the log, at any granularity, has ever captured these errors. |
|
I'm out of ideas regarding this issue, we definitely used 4.3.4 in v0.17.3.0: https://github.com/monero-project/monero/blob/v0.17.3.0/contrib/depends/packages/zeromq.mk#L2 |
|
Thanks, no worries. Once I have more evidence, I'm going to post to the zeromq thread about it. |
Trying out the 0.12.0.0 official binaries from monero-win-x64-v0.12.0.0.zip on GitHub. After some syncing, I got the following messages and then the monerod process crashed, on Windows 10 64-bit:
I wasn't logging anything, so I've got nothing else to report on this at the present. Might be something with ZeroMQ, but might be coincidental. I'll report back if I continue to see it.
The text was updated successfully, but these errors were encountered: