Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

tasks: Don't set parent's sticky bit when in a finalizer #48919

Merged
merged 1 commit into from
Mar 13, 2023

Conversation

jpsamaroo
Copy link
Member

When spawning a child task via @async, we "poison" the parent by setting their sticky flag to true to ensure that parent and child are co-scheduled on the same thread. This is obviously unideal, and also is potentially incorrect when this happens within a GC finalizer (which co-opts an unsuspecting task to run itself). This PR uses the GC.in_finalizer query added in #48857 to ensure that this does not happen when the parent is running within a GC finalizer.

@jpsamaroo jpsamaroo requested a review from vtjnash March 6, 2023 18:53
@jpsamaroo jpsamaroo added the multithreading Base.Threads and related functionality label Mar 6, 2023
@jpsamaroo jpsamaroo force-pushed the jps/finalizer-parent-no-sticky branch from 12e34e1 to dbd8802 Compare March 8, 2023 17:59
@jpsamaroo jpsamaroo added the merge me PR is reviewed. Merge when all tests are passing label Mar 11, 2023
@aviatesk
Copy link
Member

Could you resolve the conflict in base/task.jl?

@jpsamaroo jpsamaroo force-pushed the jps/finalizer-parent-no-sticky branch from dbd8802 to d3d1d32 Compare March 13, 2023 18:26
@jpsamaroo
Copy link
Member Author

Could you resolve the conflict in base/task.jl?

Done

@vchuravy vchuravy merged commit 9f997fc into JuliaLang:master Mar 13, 2023
@giordano giordano removed the merge me PR is reviewed. Merge when all tests are passing label Mar 21, 2023
Xnartharax pushed a commit to Xnartharax/julia that referenced this pull request Apr 19, 2023
Keno added a commit that referenced this pull request Jul 19, 2023
In #48919, the tid selection logic inside `enq_task` gained a
`!GC.in_finalizer()` condition. However, this made it possible
for `workqueue_at` to be reached with `tid==0`, which would
attempt and out-of-bounds write under `@inbounds`, corrupting
memory. This was not caught in the test suite despite
`--check-bounds=yes`, because our `--check-bounds=yes` is currently
best effort. That would be fixed by #50239, which exposed this
bug.
Keno added a commit that referenced this pull request Jul 19, 2023
In #48919, the tid selection logic inside `enq_task` gained a
`!GC.in_finalizer()` condition. However, this made it possible for
`workqueue_at` to be reached with `tid==0`, which would attempt and
out-of-bounds write under `@inbounds`, corrupting memory. This was not
caught in the test suite despite `--check-bounds=yes`, because our
`--check-bounds=yes` is currently best effort. That would be fixed by
#50239, which exposed this bug. This PR attempts to
fix this by marking any tasks launched inside a finalizer as not sticky.
Finalizers don't have any thread they run on
semantically, so i don't think there's a meaningful sense in which tasks
launched inside finalizers could be sticky.
KristofferC pushed a commit that referenced this pull request Jul 24, 2023
In #48919, the tid selection logic inside `enq_task` gained a
`!GC.in_finalizer()` condition. However, this made it possible for
`workqueue_at` to be reached with `tid==0`, which would attempt and
out-of-bounds write under `@inbounds`, corrupting memory. This was not
caught in the test suite despite `--check-bounds=yes`, because our
`--check-bounds=yes` is currently best effort. That would be fixed by
#50239, which exposed this bug. This PR attempts to
fix this by marking any tasks launched inside a finalizer as not sticky.
Finalizers don't have any thread they run on
semantically, so i don't think there's a meaningful sense in which tasks
launched inside finalizers could be sticky.

(cherry picked from commit bd8350b)
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
multithreading Base.Threads and related functionality
Projects
None yet
Development

Successfully merging this pull request may close these issues.

5 participants