[release-1.9] Backports for Julia 1.9 #50977
Merged
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
|
@IanButterworth: Is it common to add I wanted to add:
since backporting #48720 should close that issue. |
|
Oh and actually, wait, huh, #48720 isn't in the list in this PR anymore. I see that it was at some point, since you tagged it and removed the label?: But it's not there now. Did you end up backing it out? |
|
@NHDaly it's in the queue for 1.9.3 already, see https://github.com/JuliaLang/julia/commits/release-1.9 |
|
I'll rebase this as 1.9.3 has been tagged on release-1.9 now and it would be confusing if these commits came before that |
…3fa4 (#50976) Co-authored-by: Dilum Aluthge <[email protected]> fix inference of PackageSpec constructor in presence of imprecise input types (#3585)
If two processes attempt to recursively delete a directory at the same time, then we can end up in a state where the initial `isdir` is `true`, but by the time it actually deletes the directory it is already gone. e.g. - https://buildkite.com/clima/climacore-ci/builds/2460#0189d254-76a9-474b-ad25-e5b16440d629/140-142 which is triggered by https://github.com/cjdoris/PackageExtensionCompat.jl/blob/636eb5a14ddf9134d004c93f598515903af26443/src/PackageExtensionCompat.jl#L59 - https://buildkite.com/clima/climacore-ci/builds/2457#0189c7fe-8872-40c5-9106-da2e621ff55a/139-150 which is triggered by https://github.com/JuliaGPU/GPUCompiler.jl/blob/06e670657d7ceebc1845d7c9534a8352c33490de/src/rtlib.jl#L152 I've been conservative and only applied this when `force=true`, but perhaps it should apply generally? (cherry picked from commit cbd3c89)
Without this, the task created by a `Channel` will run in the threadpool
of the creating task; in the REPL, this could be the interactive
threadpool.
On 1.8, without threadpools:
```julia
% julia +1.8 -t 8
_
_ _ _(_)_ | Documentation: https://docs.julialang.org
(_) | (_) (_) |
_ _ _| |_ __ _ | Type "?" for help, "]?" for Pkg help.
| | | | | | |/ _` | |
| | |_| | | | (_| | | Version 1.8.5 (2023-01-08)
_/ |\__'_|_|_|\__'_| | Official https://julialang.org/ release
|__/ |
julia> for _ in 1:10
Channel{Int}(1; spawn=true) do _
Core.print("threadid=$(Threads.threadid())\n")
end
end
threadid=2
threadid=5
threadid=2
threadid=2
threadid=1
threadid=6
threadid=7
threadid=8
threadid=3
threadid=4
```
On 1.9, with no interactive threads:
```julia
% julia +1.9 -t 8
_
_ _ _(_)_ | Documentation: https://docs.julialang.org
(_) | (_) (_) |
_ _ _| |_ __ _ | Type "?" for help, "]?" for Pkg help.
| | | | | | |/ _` | |
| | |_| | | | (_| | | Version 1.9.2 (2023-07-05)
_/ |\__'_|_|_|\__'_| | Official https://julialang.org/ release
|__/ |
julia> for _ in 1:10
Channel{Int}(1; spawn=true) do _
Core.print("threadid=$(Threads.threadid())\n")
end
end
threadid=4
threadid=4
threadid=4
threadid=2
threadid=3
threadid=1
threadid=7
threadid=5
threadid=8
threadid=6
```
On 1.9, with an interactive thread:
```julia
% julia +1.9 -t 7,1
_
_ _ _(_)_ | Documentation: https://docs.julialang.org
(_) | (_) (_) |
_ _ _| |_ __ _ | Type "?" for help, "]?" for Pkg help.
| | | | | | |/ _` | |
| | |_| | | | (_| | | Version 1.9.2 (2023-07-05)
_/ |\__'_|_|_|\__'_| | Official https://julialang.org/ release
|__/ |
julia> for _ in 1:10
Channel{Int}(1; spawn=true) do _
Core.print("threadid=$(Threads.threadid())\n")
end
end
threadid=1
threadid=1
threadid=1
threadid=1
threadid=1
threadid=1
threadid=1
threadid=1
threadid=1
threadid=1
```
With this PR, the `:default` threadpool is used instead.
```julia
% julia +master -t7,1
_
_ _ _(_)_ | Documentation: https://docs.julialang.org
(_) | (_) (_) |
_ _ _| |_ __ _ | Type "?" for help, "]?" for Pkg help.
| | | | | | |/ _` | |
| | |_| | | | (_| | | Version 1.11.0-DEV.244 (2023-08-09)
_/ |\__'_|_|_|\__'_| | Commit d99f249* (0 days old master)
|__/ |
julia> for _ in 1:10
Channel{Int}(1; spawn=true) do _
Core.print("threadid=$(Threads.threadid())\n")
end
end
threadid=7
threadid=6
threadid=7
threadid=7
threadid=6
threadid=3
threadid=5
threadid=2
threadid=4
threadid=8
```
And, the behavior can be overridden.
```julia
% julia +master -t7,1
_
_ _ _(_)_ | Documentation: https://docs.julialang.org
(_) | (_) (_) |
_ _ _| |_ __ _ | Type "?" for help, "]?" for Pkg help.
| | | | | | |/ _` | |
| | |_| | | | (_| | | Version 1.11.0-DEV.244 (2023-08-09)
_/ |\__'_|_|_|\__'_| | Commit d99f249* (0 days old master)
|__/ |
julia> for _ in 1:10
Channel{Int}(1; spawn=true, threadpool=:interactive) do _
Core.print("threadid=$(Threads.threadid())\n")
end
end
threadid=1
threadid=1
threadid=1
threadid=1
threadid=1
threadid=1
threadid=1
threadid=1
threadid=1
threadid=1
```
---------
Co-authored-by: Nathan Daly <[email protected]>
(cherry picked from commit 555cd23)
Ensure that `isapprox` gives correct results when comparing an integer with another integer or with a float. For comparison between integers, the fix only works when keeping default values for `rtol` and `norm`, and with `atol < 1`. It is not possible to handle the (atypical) case where `norm !== abs`, but that's OK since the user is responsible for providing a safe function. It would be possible to handle the case where `rtol > 0` or `atol >= 1`, but with complex code which would check for overflow and handle all possible corner cases; it would work only for types defined in Base and would not be extensible by packages. So I'm not sure that's worth it. At least with PR fixes the most common case. Fixes #50380. (cherry picked from commit 5f03a18)
Update the docs for `Task` to mention the fact that they default to sticky. Co-authored-by: Gabriel Baraldi <[email protected]> (cherry picked from commit 5466d3d)
Trying for cross-compile and disabling CSL and realized both of those configurations were broken now. (cherry picked from commit d080fe6)
…ba42 (#50979) Co-authored-by: Dilum Aluthge <[email protected]>
IanButterworth
force-pushed
the
backports-release-1.9
branch
from
02f1738 to
fd3a971
Compare
|
Aha. Thanks! I had been assuming we'd close/merge the PR and create a new one for each patch release. Sorry for the noise! |
…857f (#51473) Co-authored-by: Dilum Aluthge <[email protected]>
|
There's quite a lot of Pkg fixes lined up here. Maybe worth going for 1.9.4 soon? @KristofferC |
Checksum changed as OpenBLAS moved from https://github.com/xianyi/OpenBLAS to https://github.com/OpenMathLib/OpenBLAS. Closes #51408.
(cherry picked from commit ff7b8eb)
`unsafe_trunc(UInt, -1.0)` is unspecified behavior but worked fine on apple and AMD so we didn't notice??? This has been very broken since 1.7. (cherry picked from commit 61ebaf6)
Co-authored-by: Gabriel Baraldi <[email protected]> Co-authored-by: Dilum Aluthge <[email protected]> (cherry picked from commit 8be469e)
…or in distributed message processing (#51019) There is a use of `oldstate` on line 244 which has the possibility of being undefined. This bug seems to have been introduced in 40c622b#diff-39fa44ff86c5b38bd6b9e7f60733b25724a9efd9221ca38f776ed3f3ab01dec2. I don't have a repro for this but this PR reverts back to the situation where `oldstate` is defined at the topmost level of the catch block as it was before the offending commit. (cherry picked from commit 777b784)
This can cause segfaults when exiting julia. Co-authored-by: Valentin Churavy <[email protected]> (cherry picked from commit b3741c0)
The guard instruction for unreachables and other crashes in aarch64 is `brk`, in macos there isn't a distinction between a brk for a breakpoint and one for a crash, as an attempt we check the value of `pc` when the signal is triggered, if it is `brk #0x1` we say that it is a crash and go into the sigdie_handler. We should probably do the same in aarch64 linux, though I haven't dug too deep into what values it uses for traps, and if what compiler used matters, on apple I assumed we use clang/LLVM It might be possible to test this by calling some inline assembly. This means that something like #51267 actually crashes with ```c [16908] signal (5): Trace/BPT trap: 5 in expression starting at /Users/gabrielbaraldi/julia/test.jl:2 _collect at ./array.jl:768 collect at ./array.jl:757 top-level scope at /Users/gabrielbaraldi/julia/test.jl:5 _jl_invoke at /Users/gabrielbaraldi/julia/src/gf.c:2892 jl_toplevel_eval_flex at /Users/gabrielbaraldi/julia/src/toplevel.c:925 jl_toplevel_eval_flex at /Users/gabrielbaraldi/julia/src/toplevel.c:877 ijl_toplevel_eval at /Users/gabrielbaraldi/julia/src/toplevel.c:943 [inlined] ijl_toplevel_eval_in at /Users/gabrielbaraldi/julia/src/toplevel.c:985 eval at ./boot.jl:383 [inlined] include_string at ./loading.jl:2070 _jl_invoke at /Users/gabrielbaraldi/julia/src/gf.c:2873 ijl_apply_generic at /Users/gabrielbaraldi/julia/src/gf.c:3074 _include at ./loading.jl:2130 include at ./Base.jl:494 jfptr_include_46486 at /Users/gabrielbaraldi/julia/usr/lib/julia/sys.dylib (unknown line) _jl_invoke at /Users/gabrielbaraldi/julia/src/gf.c:2873 ijl_apply_generic at /Users/gabrielbaraldi/julia/src/gf.c:3074 exec_options at ./client.jl:317 _start at ./client.jl:552 jfptr__start_83179 at /Users/gabrielbaraldi/julia/usr/lib/julia/sys.dylib (unknown line) _jl_invoke at /Users/gabrielbaraldi/julia/src/gf.c:2873 ijl_apply_generic at /Users/gabrielbaraldi/julia/src/gf.c:3074 jl_apply at /Users/gabrielbaraldi/julia/src/./julia.h:1970 [inlined] true_main at /Users/gabrielbaraldi/julia/src/jlapi.c:582 jl_repl_entrypoint at /Users/gabrielbaraldi/julia/src/jlapi.c:731 Allocations: 570978 (Pool: 570031; Big: 947); GC: 1 fish: Job 1, './julia test.jl' terminated by signal SIGTRAP (Trace or breakpoint trap) ``` instead of hanging silently --------- Co-authored-by: Jameson Nash <[email protected]> (cherry picked from commit d51ad06)
(cherry picked from commit 66fe51f)
(cherry picked from commit ca862df)
(cherry picked from commit abf5d9e)
deps/curl: Remove "without-ssl" because of configure error (cherry picked from commit 3254e62)
KristofferC
force-pushed
the
backports-release-1.9
branch
2 times, most recently
from
3352ca7 to
4f07359
Compare
added 2 commits
October 18, 2023 19:25
KristofferC
force-pushed
the
backports-release-1.9
branch
from
4f07359 to
926a060
Compare
(cherry picked from commit 37611b4)
|
@nanosoldier |
|
PkgEval didnt run/report back? |
|
There was an outage due to a revoked AWS key. @nanosoldier |
|
The package evaluation job you requested has completed - possible new issues were detected. |
This shouldn't be needed because `ldd` should do it itself. (cherry picked from commit 5b34cdf)
KristofferC
force-pushed
the
backports-release-1.9
branch
from
f6ff2aa to
1a09ea5
Compare
|
@nanosoldier |
|
The package evaluation job you requested has completed - possible new issues were detected. |
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Backported PRs:
threadpoolparameter toChannelconstructor #50858isapprox#50730Taskabout sticky bit #50915expm1(::Union{Float16, Float32})#50989_tryonce_download_from_cache(busybox.exe download error) #51531Need manual backport:
Contains multiple commits, manual intervention needed:
Non-merged PRs with backport label:
cwstringwhen used for env lookup / modification on Windows #51371ispath(f)#50919--heap-size-hintarg handling #48050