-
-
Notifications
You must be signed in to change notification settings - Fork 5.7k
bpart: Fix a hang in a particular corner case #58271
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
Conversation
The `jl_get_binding_partition_with_hint` version of the bpart lookup did not properly set the `max_world` of the gap, leaving it at `~(size_t)0`. Having a `gap` with that `max_world`, but with `gap.replace` set is inconsistent and ended up causing an integer overflow downstream in the computation of `expected_prev_min_world`, which looked like a concurrent modification causing an infinite retry.
| ## The sequence of events is critical here. | ||
| A58257.get! # Creates binding partition in A, N+1:∞ | ||
| A58257.B58257.get! # Creates binding partition in A.B, N+1:∞ | ||
| Base.invoke_in_world(UInt(38678), getglobal, A58257, :get!) # Expands binding partition in A through <N |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Why are you using random numbers as worlds? This will break very badly someday...
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Was supposed to be captured earlier, just forgot to commit the change. will fix.
The `jl_get_binding_partition_with_hint` version of the bpart lookup did not properly set the `max_world` of the gap, leaving it at `~(size_t)0`. Having a `gap` with that `max_world`, but with `gap.replace` set is inconsistent and ended up causing an integer overflow downstream in the computation of `expected_prev_min_world`, which looked like a concurrent modification causing an infinite retry. Fixes JuliaLang#58257
The `jl_get_binding_partition_with_hint` version of the bpart lookup did not properly set the `max_world` of the gap, leaving it at `~(size_t)0`. Having a `gap` with that `max_world`, but with `gap.replace` set is inconsistent and ended up causing an integer overflow downstream in the computation of `expected_prev_min_world`, which looked like a concurrent modification causing an infinite retry. Fixes #58257 (cherry picked from commit fc8e6e7)
The `jl_get_binding_partition_with_hint` version of the bpart lookup did not properly set the `max_world` of the gap, leaving it at `~(size_t)0`. Having a `gap` with that `max_world`, but with `gap.replace` set is inconsistent and ended up causing an integer overflow downstream in the computation of `expected_prev_min_world`, which looked like a concurrent modification causing an infinite retry. Fixes JuliaLang#58257
The
jl_get_binding_partition_with_hintversion of the bpart lookup did not properly set themax_worldof the gap, leaving it at~(size_t)0. Having agapwith thatmax_world, but withgap.replaceset is inconsistent and ended up causing an integer overflow downstream in the computation ofexpected_prev_min_world, which looked like a concurrent modification causing an infinite retry. Fixes #58257