Closed noel2004 closed 1 year ago
Several days ago, I found this function doesn't use the RWLock (https://github.com/scroll-tech/go-ethereum/blob/staging/trie/database.go#L365-L376). Wonder if this place is helpful for this issue.
Several days ago, I found this function doesn't use the RWLock (https://github.com/scroll-tech/go-ethereum/blob/staging/trie/database.go#L365-L376). Wonder if this place is helpful for this issue.
Many thanks for your discovery. It is the caller's responsibility to lock the db outside of this function. (So we lock the db when calling it). I think the issue is infact caused by Commit
function do not lock the preimage map
Several days ago, I found this function doesn't use the RWLock (https://github.com/scroll-tech/go-ethereum/blob/staging/trie/database.go#L365-L376). Wonder if this place is helpful for this issue.
Many thanks for your discovery. It is the caller's responsibility to lock the db outside of this function. (So we lock the db when calling it). I think the issue is infact caused by
Commit
function do not lock the preimage map
You are right Bro. In geth, they extracted this part into a new function with a RWMutex lock (https://github.com/ethereum/go-ethereum/blob/master/trie/preimages.go#L73-L87).
Looking into the stacks and we found the issue should be cause by prefetching. By disabling it, the node can sync smoothly, under ~10mgasps, or ~100tps, everything works well and app can exit and restart normally. The memory usage is kept under 2GB
I am afraid we do not handle prefetch for skip any actions in trie's Commit
, moreover I guess we would make no benefit from enabling prefetch so I advise disabling it permantly when zktrie is used.
Currently, prefetch can be disabled by --cache.noprefetch=true
options
System information
Geth version:
pre-alpha 2.2
OS & Version: Linux/OSXExpected behaviour
Run l2geth with
--gcmode=archive
, which enforce preimage being enabled and start syncing tomain
network. App would crash while syncing at random time.Actual behaviour
No crashing and successfully syncing
Steps to reproduce the behaviour
Following the instruction in running your own l2geth node, then wait for syncing finishing
Also notice that some 'addLeaf:GetNode err key not found in ZkTrieImpl' debug messages are being printed.
Backtrace
When submitting logs: please submit them as text and not screenshots.