fix(qwp): prevent JVM crash when closing a QWP sender [DO NOT MERGE]#43
Open
jerrinot wants to merge 2 commits into
Open
fix(qwp): prevent JVM crash when closing a QWP sender [DO NOT MERGE]#43jerrinot wants to merge 2 commits into
jerrinot wants to merge 2 commits into
Conversation
Closing a QWP sender while its background segment manager was mid-tick could crash the whole process. The manager's worker thread persists the acknowledged-FSN watermark into a memory-mapped file on each tick; if a sender closed and unmapped that file in the same instant, a stale worker could write to the now-unmapped address and abort the JVM with a SIGSEGV. The worker now re-checks, under the manager lock, whether the ring is still registered before it touches the watermark or the byte accounting. deregister() flips a lock-guarded `registered` flag, so once close() returns the worker can no longer write through the unmapped watermark. The watermark write and the totalBytes subtraction are both gated on the flag; drainTrimmable() and the segment close/unlink stay unconditional, so a stale snapshot still unlinks fully-acked segments as before. The O(1) flag replaces the previous O(n) scan of the rings list.
jerrinot
changed the title
Keep the bounded close wait, but only free worker-owned native state after the segment-manager worker is observed dead. A timed-out or interrupted join can leave the worker alive inside a service tick. In that state pathScratch may still be used for spare path creation or native-path cleanup, so closing it immediately risks a native use-after-free. Leave workerThread set and pathScratch allocated when the worker is still alive, allowing a later close() to retry cleanup.
Contributor
[PR Coverage check]😍 pass : 60 / 63 (95.24%) file detail
|
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
2 participants
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.
Closing a QWP sender while its background segment manager was mid-tick could crash the whole process. The manager's worker thread persists the acknowledged-FSN watermark into a memory-mapped file on each tick; if a sender closed and unmapped that file in the same instant, a stale worker could write to the now-unmapped address and abort the JVM with a SIGSEGV.
The worker now re-checks, under the manager lock, whether the ring is still registered before it touches the watermark or the byte accounting. deregister() flips a lock-guarded
registeredflag, so once close() returns the worker can no longer write through the unmapped watermark. The watermark write and the totalBytes subtraction are both gated on the flag; drainTrimmable() and the segment close/unlink stay unconditional, so a stale snapshot still unlinks fully-acked segments as before. The O(1) flag replaces the previous O(n) scan of the rings list.