[
https://issues.apache.org/jira/browse/YUNIKORN-3420?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=18110316#comment-18110316
]
jimmycmlin commented on YUNIKORN-3420:
--------------------------------------
Thanks to [~Yu-Lin Chen] advise, I ran some checks and here are what I found.
I traced every call site of {{.String()}} / {{zap.Stringer(x)}} /
{{{}%v{}}}/{{{}%s{}}} across the whole repo, then followed each caller chain to
see if the type's own write lock could be held at that point.
For Application, I found that {{zap.Stringer("app", app)}} is reachable while
{{sa.Lock()}} is held. But the lock scenario will not happen because of the
nil-check beforehand. i.e. {{node}} and {{ask}} are guaranteed non-nil before
the lock is even taken.
See here :
https://github.com/apache/yunikorn-core/blob/master/pkg/scheduler/objects/application.go#L984-L987
{{{}TrackedResource{}}}, {{{}Queue{}}}, and {{Allocation}} came back clean — no
production call site logs them while their own write lock is held.
So yeah... I guess it is a trap rather than a bug. For now I think I will just
retract the PR unless there is any further update.
> 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: jimmycmlin
> 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: [email protected]
For additional commands, e-mail: [email protected]
