-
Notifications
You must be signed in to change notification settings - Fork 152
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
fatal error: index out of range #626
Comments
Thanks for the reporting. Have you started a fresh sync or it happened on long running nodes? We will try to reproduce it and report back. |
It seems to come back even after fresh syncs. It's in snap sync mode. Start file
And config toml
I think it maybe has something to do with running in a container. But of course could also be some hardware fault on my pc. |
We were still not able to reproduce. We will try again using the config you give above.
|
I tested snap sync on 3 different machines using the v1.12.19 and your provided TOML config file and went smooth. Probably it has to do with the proxmox lxc containers. If you provide more info on how to setup the same config, I will try to reproduce it. |
Just wanted to add into this Issue, Several Users from our Community report the same, no special config or anything, after a while they run into
here another user, Till now only Windows Users are Affected, windows defender off, these we not affected, nodes 5-8 defender still on, these were all affected |
Thanks for your report @Nowalski. Does this happen on geth start or later? We will have a look |
it happens later after some time, some report after 10 Hours of running some say after a few hours but never on start, |
After continued investigation and feedback from the community, we’ve decided to revert back to v1.12.19 in the next. Two weeks, The issue we’re facing seems to be worsening, and despite our efforts to identify the root cause, it remains elusive. Some users have suggested that Windows Defender might be involved, but even after excluding it and disabling other third-party applications, the problem persists in a random manner. Maybe u guys found the root cause we have over 6500 nodes running it if u need some sort of testing let us know, |
Are these machines running pre-compiled binaries, or building geth independently? Your original trace indicates using Go All 3 stack traces you've shared point to different code locations, which suggests to me that if there is a single underlying issue for them, it's likely environmental. |
Pre compiled from https://github.com/etclabscore/core-geth/releases/tag/v1.12.20 I get u an output in the next few days when i get home, but i assure it's the latest version mine and those of the community, I did not manually update go, since the binaries are pre compiled i don't see why i would need doing that anyways, i could try doing that and compiling myself, The last point yes the errors are all a little different but comes back as somewhere deeper down the line and nobody had any issue before this release, since allot report it i can't pin point exactly what it's causing it, i had it randomly myself as others too, out of nowhere at some point after a while killing geth.exe and starting it up again was the only solution, |
I am running a few etc nodes in proxmox lxc containers on a minisforum um480 and they all seem to fail with the same error at some point. Already checked ram wit memtest even replace ram resynced database but it keeps happening.
Core-geth version is latest release.
I wonder if it has to do with the chain reorg detected a few times before the crash.
The text was updated successfully, but these errors were encountered: