Gridcoin-research: 3.5.9.2 crashes when running in full node mode

[moisespr123]

The latest version crashes on Windows randomly but mostly during the first hours of opening it. This is while having listen=1. Has been like this since the 3.5.9.0 release. Previous versions didn't crashed as often and were rare. Now they are frequent.

[SCCMAdmin]

I can also confirm mine crashes too (Windows 10 x64 and v3.5.9.2-g-research). It seems to be after a random period of time. I return to my computer, say in the morning from overnight and the wallet is no longer running. Or if i go to the notification area icon and hover over it in an attempt to access it, it disappears as it is no longer running (and previously crashed out).

Let me know if I can assist with log collection near such an event. Thanks.

PS. I don't know what full node mode is.

[Quezacoatl1]

I think it has to do with the number of connections. When adding maxconnections=10 and maxoutboundconnnections=5 my Win node ran much more stable.
Probably a duplicate of #356.
A fix has already been proposed by @denravonska

[moisespr123]

Hope it gets fixed so that I can resume using my full node which is currently limited to just 10 connections instead of the hundreds I was getting.

[SCCMAdmin]

I usually only have 7 or 8 connections.
So what is full node mode and why would one use it?
Thanks @Quezacoatl1 @moisesmcardona

[tomasbrod]

Full node is every wallet that is reachable from public Internet (port forwarding), preferably has a domain name, and has increased limit of incoming connections.
This may be caused by some race conditions.

[denravonska]

@tomasbrod It's a socket error 10014 when doing select on Windows IIRC. I need to capture it in the debugger to see why this happens.

[dopeshitnetworks-irc-dopeshit-net]

I am having the same issue , before reading this i thought it may be something like that as seattle-2.gridcoin.stablenode.net sits around 130-137 connections in windows 7 so i moved from an Intel D920 with 4gb ram dedicated laptop over to one of my blades , as I had testnet running on 2 HP Proliant BL460c gen 6's already and random on restart since 3.5.9.x when starting testnet I get invalid block index file error and have to redownload the blockchain ( its fast so no problem really just annoying ) anyways one downloadblocks --testnet runs it restarted as the real network and before i knew it had downloaded the blockchain from block 0 overnight so moved to that node to one of the 16 core x5550's and 44gb ram 2 x 76gb 15k sas drives assuming that would be a solution and same problem also trying to provide something decent spec'ed vs the vps's most nodes are ran on especially the 15k sas drives and I wish I could run more as nodes to help support users and help the NN issues especially since we are ordering 1/1gbps as its not much more than my 285/20mbps I have at home. Thanks to bullshark linking me this post I tried max connections @ 50 and was ok then @ 75 and it crashed before hitting 75 , as I said in windows I am used to seeing 130ish stable weeks/months on end with that dedicated machine I have been using as a full node in windows.. So my solution , move over to 1 of my BL480's running ubuntu for now till this issue is resolved. I wish we used a block of ports and could have within a NAT network and 1 ipv4 address multiple nodes and it would just go incrementally and in the firewall allow a block of ports vs 1 and the wallet clients use upnp to punch the hole needed in their firewall to connect to 32749 , 32750 , 32751 etc as it searched for gridcoin wallets on the seednodes or nodes in the config file dns/ip on that block of ports and if not found moves on , same with testnet so you could run multiple clients especially if connection count is going to be an issue and windows clients max @ 50-60 clients when you have us running Linux nodes capable of of 100s of connections ( i have 2 linux full nodes we use too 124 and 97 connections ) and with testnet using 32760 then 32761 32762 etc vs only the ability to run 1 full node server per ipv4 address and then multiple ipv6 only nodes since most end users are stuck with 1 ipv4 address and a /48 or /64 and we have many active ipv6 connections. I assume there is some hardening that would have to happen as it opens more doors into the gridcoinresearchd daemon but it would be nice.. Also according http://www.gridcoin.us/Dev/daemon-cmd.htm " -maxconnections= Maintain at most connections to peers (default: 125) " has this been changed and the default value of N is now different and this documentation needs to be updated and this is why the wallets crash?

[SCCMAdmin]

I can confirm I don't use full node mode, so my comments can be ignored in this thread's subject. However, as above, I do have crashes in terms of after a period of time, I can return to my online PC and the wallet has quit by itself. I will monitor on 3.5.9.4 (version change since posting) and report if I need to in future. Thanks All. :-)

[iFoggz]

related to #461 ?

[RoboticMind]

can we close this @denravonska

[tomasbrod]

No, it still crashes.

[RoboticMind]

Is this still an issue now?

[SCCMAdmin]

Hi All, hi @RoboticMind. Per my comments above, I never used full node mode and still don't know what it is, though I did have crashes on the version noted. Have been using latest for some time and no crashes for me. So take it as a positive. Perhaps I will let the original poster @moisesmcardona respond. Thank you.

[tomasbrod]

Full node mode is where you configure your router (or not disable it there, lot of routers have it enabled already), to allow remote nodes to connect to your.

[G-UK]

I have a prod wallet and testnet wallet port forwarded on the default ports (although I have not added them to the node list as yet) and do not seem to suffer from this crashing.

Prod Wallet - Rasp-Pi 3B, Pi-64 Debian Buster
Testnet Wallet - Windows 10 x64

Any crashes I have had previously have been related to memory and swap usage before I was able to pin down my stable settings on the R-Pi. I haven't seen any crashes relating to running as a full node even on the Pi's limited hardware.

My other machines running testnet clients are port forwarded as well but on non-standard ports so get limited inbound connections.

[denravonska]

Closing as we have not seen this in a very long time.