You are viewing a plain text version of this content. The canonical link for it is here.
Posted to issues@yunikorn.apache.org by "Dale Richardson (Jira)" <ji...@apache.org> on 2026/09/07 10:36:00 UTC
[jira] [Comment Edited] (YUNIKORN-3420) String() methods that take their own lock
[ https://issues.apache.org/jira/browse/YUNIKORN-3420?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=18112282#comment-18112282 ]
Dale Richardson edited comment on YUNIKORN-3420 at 9/7/26 10:35 AM:
--------------------------------------------------------------------
I went back over this and I agree with the conclusion: none of the four String() methods can deadlock today. The pattern (passing references of string routines which use a lock), is one which is present in the code, but as noted above nothing (yet) is using that calling pattern (other then the unreachable nil checking code). I am happy to mark this ticket as "not a problem", and I will see if I can enhance the lockvet tool to do additional call-site analysis so it will only flag this pattern when it detect an actual caller that will trigger the issue.
was (Author: tigerquoll):
I went back over this and I agree with the conclusion: none of the four String() methods can deadlock today. The pattern (passing references of string routines which use a lock), is one which could suffer from that issue, but as noted above nothing (yet) is using that calling pattern (other then the unreachable nil checking code). I am happy to mark this ticket as "not a problem", and I will see if I can enhance the lockvet tool to do additional call-site analysis so it will only flag this pattern when it detect an actual caller that will trigger the issue.
> String() methods that take their own lock
> -----------------------------------------
>
> Key: YUNIKORN-3420
> URL: https://issues.apache.org/jira/browse/YUNIKORN-3420
> Project: Apache YuniKorn
> Issue Type: Sub-task
> Components: core - common, core - scheduler
> Reporter: Dale Richardson
> Assignee: Dale Richardson
> Priority: Minor
> Labels: pull-request-available
>
> {{TrackedResource.String}}, {{Queue.String}}, {{Allocation.String}} (through {{GetAllocatedResource}} / {{IsAllocated}}) and {{Application.String}} (through {{GetSubmissionTime}}) take the read lock of the object they print. {{fmt}} and {{zap}} evaluate a {{Stringer}} whenever the log line is built, which the type does not control; if that happens while the caller holds the object's write lock, the goroutine deadlocks on itself.
> No such caller was found in the current tree, so this is a trap rather than a bug that fires today. It is filed because a log line added under the write lock in future would hang silently, and because the fix is small.
> Fix: print only fields fixed at construction, or have the caller take a snapshot under the lock and print that. Note that {{Application}}'s submission time is not construction-fixed (it is reassigned on the recovery and placeholder paths), so it needs the snapshot treatment rather than a direct read.
> Marker: four {{+lockstringerignore}} sites carry this JIRA; the fix removes them.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
---------------------------------------------------------------------
To unsubscribe, e-mail: issues-unsubscribe@yunikorn.apache.org
For additional commands, e-mail: issues-help@yunikorn.apache.org