You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Geth version: 1.14.5-stable
CL client & version: Lighthouse v5.1.3-3058b96
OS & Version: Amazon Linux (4.14.314-237.533.amzn2.x86_64)
Commit hash: own tiny custom patch
Expected behaviour
We have a few nodes running as public RPCs on Mainnet. Our RPC nodes have a tiny custom patch that has not changed for the past few months. We serve quite a large number of requests.
Actual behaviour
Some nodes started to crash serving eth_call on June 7, crashing about once every day or two. The crash occurs when copying the state of a pending block. All requests that crash the node are targeted at the latest block and seem nothing special otherwise. Backtrace always looks the same.
Steps to reproduce the behaviour
I cannot effectively reproduce it with my own eth_call requests.
vitalii427
changed the title
Crash at eth_call when copying the state of a pending block
Panic on eth_call when copying the state of a pending block
Jun 13, 2024
As for why this might have triggered now, we've received a number of PRs that kept replacing literal map copyings with these maps.Clone calls, so that might be the reason it started happening just now for you.
System information
Geth version: 1.14.5-stable
CL client & version: Lighthouse v5.1.3-3058b96
OS & Version: Amazon Linux (4.14.314-237.533.amzn2.x86_64)
Commit hash: own tiny custom patch
Expected behaviour
We have a few nodes running as public RPCs on Mainnet. Our RPC nodes have a tiny custom patch that has not changed for the past few months. We serve quite a large number of requests.
Actual behaviour
Some nodes started to crash serving
eth_call
on June 7, crashing about once every day or two. The crash occurs when copying the state of a pending block. All requests that crash the node are targeted at the latest block and seem nothing special otherwise. Backtrace always looks the same.Steps to reproduce the behaviour
I cannot effectively reproduce it with my own
eth_call
requests.Backtrace
The text was updated successfully, but these errors were encountered: