Dale Richardson created YUNIKORN-3416:
-----------------------------------------
Summary: UserGroupCache cleanup locks the singleton instead of the
receiver; nil dereference after Stop()
Key: YUNIKORN-3416
URL: https://issues.apache.org/jira/browse/YUNIKORN-3416
Project: Apache YuniKorn
Issue Type: Bug
Components: core - common
Reporter: Dale Richardson
{{cleanUpCache}} and {{resetCache}} lock the package-global {{instance}} while
mutating the receiver's map {{c.ugs}}. In production the two are the same
object, so the map is protected by accident. Where it goes wrong is {{Stop()}}:
it sets {{instance = nil}}, and a cleaner run that has already picked its timer
branch dereferences nil in {{cleanUpCache}}. That is a crash at shutdown (or on
an in-process restart, YUNIKORN-3370). The non-singleton constructors are
exported too, and such a cache mutates its map under a different cache's lock.
Reproduced on the fork fix branch (the nil dereference and the non-singleton
case both fail before the fix; the {{Stop()}} versus cleaner ordering shows
under {{-race}}).
Fix: lock the receiver ({{c.lock}}) in both functions. A fix exists on the
tigerquoll fork ({{fix/usergroup-cache-receiver-locking}}, PR #18 there) and
will be filed once this has a number. Not covered by it and left with
YUNIKORN-3370: {{stopped}} is never cleared, and {{GetUserGroupCache}}'s
{{return instance}} still races the nil write.
Marker: three {{+checklocksignore}} sites in {{usergroup.go}} carry this JIRA;
the fix removes them.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
