Heavy contention in filestore could result in underflow and panic. #2959
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Under heavy contention skipMsg combined with removeMsg and writeIndexInfo could result in index being stamped with underflow for number of messages. This would lead to possible panic when using mb.msgs to allocate a block buffer.
We had a report of a panic on server restart with 2.8.0-beta.1 (Thanks to Derek Wang!). The panic was trying to malloc/make the size of a load block based off of the number of messages we thought the block had from the index file. Before, SkipMsg would decrement and when we added the record via writeMsgRecord we would add it back in. However we did release the lock, meaning other things could run in between under load. If in between the decrement, say to 0 (we did protect against underflow there), then a remove and subsequent writeIndexInfo would stamp an underflow.
Signed-off-by: Derek Collison derek@nats.io
/cc @nats-io/core