I believe this might be the cause of the assertion failures in the EXPENSIVE_CHECKS bot on GreenDragon. See build #16770. I can't reproduce that failure myself, but this ought to be more precise, even if it's not what's triggering that particular issue.
Details
Diff Detail
- Repository
- rG LLVM Github Monorepo
Unit Tests
Event Timeline
I think it would be great if we would have a reproducer to see exactly what's going on.
If the block is already set for deletion, whoever added it should take care of dropping references & co and there should be nothing to do for us here.
So it might be more straight forward to not include blocks already pending deletion in DeadBlockSet. That way, we could have an early bail out if the deadblockset is empty. Otherwise we know we are going to make changes (mark a new block for deletion at least) and we can always return true at that point I think.
Technically, the function might not actually delete any blocks there and then, but the blocks marked for deletion here will eventually be deleted (Once the DTU flushes the updates).
Great, thanks for confirming. As mentioned earlier, we shouldn't have to make any changes for blocks already marked as deleted. It still might be worthwhile to simplify the code as suggested.