Fix intermittent cache unit test segfault in Fedora CI - #13527
Merged
bneradt merged 1 commit intoAug 12, 2026
Merged
Conversation
The Fedora CI job fails every so often with a SIGSEGV in one of the cache unit tests, always with the same stack: strrchr() called from SourceLocation::str(), from lock_waiting(), from Mutex_trylock(). In DEBUG builds a thread that fails to acquire a mutex reports the holder's srcloc and handler, but those fields belong to whichever thread holds the mutex, and a waiter that just failed to acquire it holds nothing. That read races with the holder publishing the fields on acquire and clearing them in Mutex_unlock(). Because SourceLocation::str() loads file once for valid() and again for strrchr(), and because the clear happens before the mutex is released, a waiter can pass the validity check and then dereference a null file. The cache unit tests are the only ones that enable the locks debug tag, so they are the only ones that reach this code at all. This patch addresses this by reporting the waiting site rather than the holder's. That SourceLocation is a MakeSourceLocation() temporary owned by the caller, so nothing else can mutate it, and a holder snapshot is stale the instant it is taken in any case. The holder is still reported by lock_holding(), which runs from Mutex_unlock() where the caller owns those fields. Fixes: apache#13524 Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
bneradt
force-pushed
the
fix-lock-waiting-holder-srcloc-race
branch
from
August 10, 2026 22:01
16834b8 to
4176d83
Compare
masaori335
approved these changes
Aug 12, 2026
masaori335
left a comment
Contributor
There was a problem hiding this comment.
Makes sense. These variables are defined when it's DEBUG is defined.
#ifdef DEBUG
const SourceLocation &location, const char *ahandler,
#endif
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
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.
The Fedora CI job fails every so often with a SIGSEGV in one of the
cache unit tests, always with the same stack: strrchr() called from
SourceLocation::str(), from lock_waiting(), from Mutex_trylock(). In
DEBUG builds a thread that fails to acquire a mutex reports the
holder's srcloc and handler, but those fields belong to whichever
thread holds the mutex, and a waiter that just failed to acquire it
holds nothing. That read races with the holder publishing the fields
on acquire and clearing them in Mutex_unlock(). Because
SourceLocation::str() loads file once for valid() and again for
strrchr(), and because the clear happens before the mutex is
released, a waiter can pass the validity check and then dereference a
null file. The cache unit tests are the only ones that enable the
locks debug tag, so they are the only ones that reach this code at
all.
This patch addresses this by reporting the waiting site rather than
the holder's. That SourceLocation is a MakeSourceLocation() temporary
owned by the caller, so nothing else can mutate it, and a holder
snapshot is stale the instant it is taken in any case. The holder is
still reported by lock_holding(), which runs from Mutex_unlock()
where the caller owns those fields.
Fixes: #13524
Co-Authored-By: Claude Opus 5 noreply@anthropic.com