-
Notifications
You must be signed in to change notification settings - Fork 897
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
Unable to copy layered worldstate on 22.10.2 - Snapshots=False #4784
Comments
Yep ran into this. Restart doesn't fix it; no bonsai snapshots. Running bonsai tries with snap sync.
Frequency: Reasonably frequent. Saw it in 2 out of 4 fresh syncs so far. |
I ran into this today as well. Same hashes and block number as @yorickdowne |
I am having this exact issue following a proper shutdown and reboot. Prior to this, I had deleted the Besu DB and completed a fresh sync. Following the sync, everything was normal until the reboot. Running 22.10.3. Dec 22 15:31:26 GHBeelink2 besu[4272]: 2022-12-22 15:31:26.971-08:00 | vert.x-worker-thread-0 | INFO | MainnetBlockValidator | Optional[Unable to copy Layered Worldstate for 0x3bc82334b7902026f2e9ed64122ccf224899f014dc25823a8b30568e588f20cd]. Block 16243159 (0xd25d6b550954f0b0358297170861224b6136e17d54180fb3ddfa0b04c7964f06), caused by org.hyperledger.besu.plugin.services.exception.StorageException: Unable to copy Layered Worldstate for 0x3bc82334b7902026f2e9ed64122ccf224899f014dc25823a8b30568e588f20cd |
Experiencing the same issue after having to transfer validators to a different machine earlier this week because of an unrelated issue. Running 22.10.3 combined with Teku. Have deleted db and trying to resync currently. |
This issue is mitigated in the 23.1.0-beta release coming on the 28th. The underlying data problem that is the cause of this issue persists, but 23.1.0 should be able to recover from these kinds of errors via backward sync of subsequent blocks. |
I started getting this issue and tried the 23.1.0 release candidate docker image (
|
@timjrobinson - can you provide us your config? |
@timjrobinson, 23.1.0 mitigates the issue by preventing database corruption when this error occurs. If you have run into it on 22.10.x, the database is in an inconsistent state. I am working on a standalone cli tool that can repair the state, if you still have a besu database in an inconsistent state (i.e. you have not tried to resync) |
@non-fungible-nelson the config is all rocketpool defaults but with snap sync enabled. I deleted my besu data to switch back to geth so unfortunately I don't have that database any more. |
I ran into the same issue a few weeks back and admittedly switched to geth at the time. But I still have the corrupted database. If there is something I can try, let me know (could also share). |
I also ran into the same issue today:
I am using 22.10.3 with bonsai with checkpoint. Is there a way to fix this using command line yet? Thanks! |
Hi folks - this bug is a "symptom" of three underlying issues we have patched: We will be testing these over the weekend for a release next week. This upcoming release will also have a check at boot to check for these types of errors and correct them or resync the worldstate (much shorter than a full resync). But if your node is experiencing this on 22.10.3, a resync is the best way for now to address. The trigger for the majority of these bugs is very rare (fixed in #4906), and a resync should fix it. If you happen to be unlucky and complete your snap sync with the narrow conditions for this bug, it wont manifest immediately, and should be rectified when we release 22.10.4. Thanks for the patience. |
I'm not sure about the experience of others who have seen this issue but I
thought I would share my specific case. Right around Christmas, Gary from
the Besu team and I spent a few hours looking at this on my setup here.
This issue only started happening after a proper clean shutdown and restart
for me. This was the first shutdown I had had after a fresh sync of Besu.
Prior to shut-down, I was fully synced and logs were clean. When it came
back up, it got stuck on a particular block with these errors. Gary and I
kicked off a fresh sync that night and it is back to normal. Point being,
it did not occur during regular runtime; only after a restart and that was
with a fresh database. Maybe that's why it is hard to reproduce this issue.
Now that I did yet another resync, I am afraid to take Besu down for
maintenance until we have the patch.
…On Thu, Jan 12, 2023, 11:38 AM Matt Nelson ***@***.***> wrote:
Hi folks - this bug is a "symptom" of three underlying issues we have
patched:
#4786 <#4786> Bugfix snapshot
transaction segfaults after storage truncation
#4862 <#4862> Bugfix potential
chain head and worldstate inconsistency
#4906 <#4906> Bugfix for
selfdestruct and bonsai during heal step.
We will be testing these over the weekend for a release next week. This
upcoming release will also have a check at boot to check for these types of
errors and correct them or resync the worldstate (much shorter than a full
resync). But if your node is experiencing this on 22.10.3, a resync is the
best way for now to address. The trigger for the majority of these bugs is
very rare (fixed in #4906 <#4906>),
and a resync should fix it. If you happen to be unlucky and complete your
snap sync with the narrow conditions for this bug, it wont manifest
immediately, and should be rectified when we release 22.10.4. Thanks for
the patience.
—
Reply to this email directly, view it on GitHub
<#4784 (comment)>,
or unsubscribe
<https://github.com/notifications/unsubscribe-auth/AYPVR2POB5VYI6X6ZJ7EMYDWSBMRVANCNFSM6AAAAAASXEGAIQ>
.
You are receiving this because you commented.Message ID:
***@***.***>
|
Definitely leave your node running. The problem actually can begin during the sync phase (i.e. one of the bugs we patched was in the "heal" step of sync, it improperly filled the database, leading to these worldstate errors). If your node is running fine for now, definitely let it run while we get the release ready for next week. |
This happened to me twice in 1 week. The first time it was triggered by a full SSD. Second time around there was enough storage and it occured 2 days after a successful resync. Bonsai with snapshots. Edit: I hace updated to the 23.1-SNAPSHOT image from Dockerhub and started a resync. Hope there is no problem with this. |
tracking in multiple other locations. closing here |
Description
Besu user experiencing the following bug:
022-12-07 08:38:20.491-07:00 | vert.x-worker-thread-0 | INFO | MainnetBlockValidator | Optional[Unable to copy Layered Worldstate for 0x3c2a249675dca59a4477c9a3ffdcc51e203617266f1a0f6434fa1a1dc5fec3f0]. Block 16130345 (0xa8b549ea57d83df60aec71c6fb40ab8391b0f640d7a2d2a013fce3a296800ad0), caused by org.hyperledger.besu.plugin.services.exception.StorageException: Unable to copy Layered Worldstate for 0x3c2a249675dca59a4477c9a3ffdcc51e203617266f1a0f6434fa1a1dc5fec3f0...
Directly after a restart and their node is stuck. Restart does not fix. Initially the user experienced the error below, then upon restart, the error above.
2022-12-07 08:09:44.904-07:00 | vert.x-worker-thread-0 | WARN | EngineNewPayload | Invalid new payload: number: 16130345, hash: 0xa8b549ea57d83df60aec71c6fb40ab8391b0f640d7a2d2a013fce3a296800ad0, parentHash: 0x3c2a249675dca59a4477c9a3ffdcc51e203617266f1a0f6434fa1a1dc5fec3f0, latestValidHash: 0x3c2a249675dca59a4477c9a3ffdcc51e203617266f1a0f6434fa1a1dc5fec3f0, status: INVALID, validationError: Unable to process block because parent world state 0x3b34cb5ab01b1b590a73ac002acbf60790360952ed1679bd6d9f9b608856b29a is not available
User does not have snapshots enabled. User is on 22.10.2.
Discord context
Acceptance Criteria
Steps to Reproduce (Bug)
Expected behavior: [What you expect to happen]
Continues normally.
Actual behavior: [What actually happens]
Bonsai resumes as normal
Frequency: [What percentage of the time does it occur?]
Infrequent
Versions (Add all that apply)
Additional Information (Add any of the following or anything else that may be relevant)
The text was updated successfully, but these errors were encountered: