-
Notifications
You must be signed in to change notification settings - Fork 20.6k
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
core: fix canonical hash marker update #24996
Changes from 1 commit
File filter
Filter by extension
Conversations
Jump to
Diff view
Diff view
There are no files selected for viewing
Original file line number | Diff line number | Diff line change |
---|---|---|
|
@@ -2063,6 +2063,11 @@ func (bc *BlockChain) reorg(oldBlock, newBlock *types.Block) error { | |
for _, tx := range newChain[i].Transactions() { | ||
addedTxs = append(addedTxs, tx.Hash()) | ||
} | ||
// Collect reborn logs due to chain reorg | ||
logs := bc.collectLogs(newChain[i].Hash(), false) | ||
if len(logs) > 0 { | ||
rebirthLogs = append(rebirthLogs, logs) | ||
} | ||
} | ||
|
||
// Delete useless indexes right now which includes the non-canonical | ||
|
@@ -2071,8 +2076,13 @@ func (bc *BlockChain) reorg(oldBlock, newBlock *types.Block) error { | |
for _, tx := range types.HashDifference(deletedTxs, addedTxs) { | ||
rawdb.DeleteTxLookupEntry(indexesBatch, tx) | ||
} | ||
// Delete any canonical number assignments above the new head | ||
number := bc.CurrentBlock().NumberU64() | ||
// Delete all hash markers that are not part of the new canonical chain. | ||
// Because the reorg function does not handle new chain head, all hash | ||
// markers greater than or equal to new chain head should be deleted. | ||
number := commonBlock.NumberU64() | ||
if len(newChain) > 1 { | ||
number = newChain[1].NumberU64() | ||
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. This is the same as So this PR only makes any change if the There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. But I don't quite get why it is the way it is,
Why not write out the head block too? There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. Because the semantic of There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more.
Yes exactly. It mostly for this case There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more.
Sounds good to me (just need to get the linter silent) |
||
} | ||
for i := number + 1; ; i++ { | ||
hash := rawdb.ReadCanonicalHash(bc.db, i) | ||
if hash == (common.Hash{}) { | ||
|
@@ -2084,14 +2094,6 @@ func (bc *BlockChain) reorg(oldBlock, newBlock *types.Block) error { | |
log.Crit("Failed to delete useless indexes", "err", err) | ||
} | ||
|
||
// Collect the logs | ||
for i := len(newChain) - 1; i >= 1; i-- { | ||
// Collect reborn logs due to chain reorg | ||
logs := bc.collectLogs(newChain[i].Hash(), false) | ||
if len(logs) > 0 { | ||
rebirthLogs = append(rebirthLogs, logs) | ||
} | ||
} | ||
// If any logs need to be fired, do it now. In theory we could avoid creating | ||
// this goroutine if there are no events to fire, but realistcally that only | ||
// ever happens if we're reorging empty blocks, which will only happen on idle | ||
|
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@MariusVanDerWijden Is it OK to move this logic back into this for loop?
I saw you moved it out in your last PR, I'm not sure if this is accidental behavior or intentional. Please correct me if there is a reason for it and I can change it back. Just for cleaning up the code.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Yes the reason is memory consumption. If we do it here, the peak memory consumption is way higher since we need to keep the logs in memory at the same time as we keep the transactions in memory, moving it out allows the gc to collect the transaction ls before allocating the logs
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
reverted.