Backports for 1.11.0-beta2 #54112
Merged
Backports for 1.11.0-beta2 #54112
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
(cherry picked from commit 7099bdd)
(cherry picked from commit 97ac3ec)
…reters (#54069) Partially reverts #49391 PrecompileTools uses the timing infrastructure to snoop on the inference process. The reason for #49391 was that this could lead to accidental pollution of the caches with foreign results (timholy/SnoopCompile.jl#338) After #52233 and especially #53336 we now filter results by cache owner and don't try to cache foreign code using the native pipeline. Motivated by JuliaGPU/GPUCompiler.jl#567 which demonstrated that a foreign code instance would not be cached without PrecompileTools. (cherry picked from commit c0611e8)
Particularly under precompilation, fields and globals can revert to being undef, which is heavily relied upon by many `__init__` methods in the ecosystem (because JLL emits this pattern, so we cannot simply disallow it). While here, also fix and improve several places where we compute or use the isdefined check poorly. (cherry picked from commit fb3ae01)
Followup to #53833 Fixes a failure seen in #53974 (below) I believe this is the more correct check to make? The heapsnapshot generated from this PR is viewable in vscode. ``` 2024-04-06 09:33:58 EDT From worker 7: ERROR: Base.InvalidCharError{Char}('\xc1\xae') 2024-04-06 09:33:58 EDT From worker 7: Stacktrace: 2024-04-06 09:33:58 EDT From worker 7: [1] throw_invalid_char(c::Char) 2024-04-06 09:33:58 EDT From worker 7: @ Base ./char.jl:86 2024-04-06 09:33:58 EDT From worker 7: [2] UInt32 2024-04-06 09:33:58 EDT From worker 7: @ ./char.jl:133 [inlined] 2024-04-06 09:33:58 EDT From worker 7: [3] category_code 2024-04-06 09:33:58 EDT From worker 7: @ ./strings/unicode.jl:339 [inlined] 2024-04-06 09:33:58 EDT From worker 7: [4] isassigned 2024-04-06 09:33:58 EDT From worker 7: @ ./strings/unicode.jl:355 [inlined] 2024-04-06 09:33:58 EDT From worker 7: [5] isassigned 2024-04-06 09:33:58 EDT From worker 7: @ /cache/build/tester-amdci5-14/julialang/julia-master/julia-41d026beaf/share/julia/stdlib/v1.12/Unicode/src/Unicode.jl:138 [inlined] 2024-04-06 09:33:58 EDT From worker 7: [6] print_str_escape_json(stream::IOStream, s::String) 2024-04-06 09:33:58 EDT From worker 7: @ Profile.HeapSnapshot /cache/build/tester-amdci5-14/julialang/julia-master/julia-41d026beaf/share/julia/stdlib/v1.12/Profile/src/heapsnapshot_reassemble.jl:239 2024-04-06 09:33:59 EDT From worker 7: [7] (::Profile.HeapSnapshot.var"#5#6"{IOStream})(strings_io::IOStream) 2024-04-06 09:33:59 EDT From worker 7: @ Profile.HeapSnapshot /cache/build/tester-amdci5-14/julialang/julia-master/julia-41d026beaf/share/julia/stdlib/v1.12/Profile/src/heapsnapshot_reassemble.jl:192 ``` (cherry picked from commit c557636)
|
@nanosoldier |
|
The package evaluation job you requested has completed - possible new issues were detected. |
|
@tecosaur, I'm confused, annotate! is new, but public, not exported so why: Failed to precompile InMemoryDatasets [5c01b14b-ab03-46ff-b164-14c663efdd9f] to "/home/pkgeval/.julia/compiled/v1.11/InMemoryDatasets/jl_TqjVub". I'm concerned how many packages are failing [EDIT: it seems because PkgEval doesn't test latest version such as in this case (I've now reported that at #54150): , and why, e.g. QML, because of CxxWrap seemingly. It's bad the CxxWrap gets broken repeatedly by Julia. I'm not exactly sure why (each time), I just understand it happens... And we now have a brand-new competitor to it, not sure if it's immune to such. Can we declare the C API (at least) CxxWrap depends on stable, or at least not keep breaking it?] |
It is easy to accidentally call these functions (they are used by vcat, which is syntax) with very long lists of values, causing inference to crash and take a long time. The `afoldl` function can handle that very well however, while naive recursion did not. Fixes #53585 (cherry picked from commit df28bf7)
|
@PallHaraldsson I don't see what
has to do with |
|
Regarding @PallHaraldsson, please try to keep on topic for this PR, if you want to discuss stability of the C-API, this is not the place. |
For GPUCompiler we would like to support a native on disk cache of LLVM IR. One of the longstanding issues has been the cache invalidation of such an on disk cache. With #52233 we now have an integrated cache for the inference results and we can rely on `CodeInstance` to be stable across sessions. Due to #52119 we can also rely on the `objectid` to be stable. My inital thought was to key the native disk cache in GPUCompiler on the objectid of the corresponding CodeInstance (+ some compilation parameters). While discussing this with @rayegun yesterday we noted that having a CodeInstance with the same objectid might not be enough provenance. E.g we are not gurantueed that the CodeInstance is from the same build artifact and the same precise source code. For the package images we are tracking this during loading and validate all contents at once, and we keep explicitly track of the provenance chain. This PR adds a lookup up table where we map from "external_blobs" e.g. loaded images, to the corresponding top module of each image, and uses this to determine the build_id of the package image. (cherry picked from commit d47cbf6)
… to bfdb4c3 (#54127) Stdlib: StyledStrings URL: https://github.com/JuliaLang/StyledStrings.jl.git Stdlib branch: main Julia branch: backports-release-1.11 Old commit: e0ca0f8 New commit: bfdb4c3 Julia version: 1.11.0-beta1 StyledStrings version: 1.11.0 Bump invoked by: @tecosaur Powered by: [BumpStdlibs.jl](https://github.com/JuliaLang/BumpStdlibs.jl) Diff: JuliaLang/StyledStrings.jl@e0ca0f8...bfdb4c3 ``` $ git log --oneline e0ca0f8..bfdb4c3 bfdb4c3 Modify tests to also pass when run as stdlib c084718 Fix return type of AnnotatedString write 180ab6c Try fixing the non-stdlib tests via refactor 528f245 Docs: minor index copyedits, and americanizations 9c015e2 Docs: create an examples page a9772d4 Markup annot keys cannot contain null character 243d959 Allow interpolation of underline properties fd2adcc Docs: tweak face description for clarity 4b06b79 Docs: clarify that AbstractString is wrapped 7f07b1b Docs: second paragraph reads better as not a note a3d15cb Docs: forgot to mention font attribute 9c10614 Show colour and styling in docs 59fd944 Add docs previews to PR CI 9709612 Mark styled and withfaces functions as public API a4c7678 Make withfaces behave more consistently 50d4198 Add speculative consideration of future face keys 04b5031 Add fuzzing to the tests set 7dc3c26 Allow color strings as in Face constructor c419317 Don't annotate interpolated empty strings dfef96d Adjust prioritisation of composed styling in parse 9a23e9e Test the display of parsing errors 1d7f42a Test parsing of each and every inline face attr 84ba211 No need to escape a string when parsing e3c0453 Add missing is-macro check to face value interp db006ed Mistyped font attribute as "face" in the parser 230fa8e Test errors emitted with various malformed stystrs 31f4c1d Overly aggressive color names check in styled strs bec9216 Expand on faces tests 093385e Improve showing of RGB SimpleColors without MIME d60d545 Test the show methods of SimpleColor and Face cb05225 Test the AnnotatedIOBuffer printstyled method c36911c Test the (legacy) loading of colors from envvars 14b4c6e Reduce test code verbosity by importing more names 3db948f Add a battery of HTML encoding tests 316bdd5 Remove extranious spaces from HTML underline style 62a7d25 Adjust named HTML colours to be not-garish 81e031e Add a battery of ANSI encoding tests a14c3b1 Check the Smulx termcap instead of Su b9d4aea Use the redmean colour distance in 8-bit approx f9976ad More careful comma handling with inline face specs 24e10e4 Accept a style symbol as the sole underline value 2ba234a Use the hardcoded bold ANSI code ab4f681 Refactro termcolor8bit to be less magic a8b8aaf Fix off-by-one errors in termcolor8bit 21e127a Introduce fuzzer for styled markup a3b40b7 Mention the loading of faces.toml in the docs 16c0e4f Fix functional parsing of inline face weight 7da631f Consolidate use of "ws" and "whitespace" in EBNF b76c1ce Introduce ismacro convenience func to parser b1cb60c Fix handling of space around inline face attrs e22d058 Clarification in styled markup grammar docs 701d29f Introduce isnextchar convenience func to parser 6efb352 Fix edge-case parsing of empty face construct 10f6839 Implement new functional styled markup interpreter e2d2d5f Refactor stylemacro into a submodule 11c5bd9 Introduce specialised write for AnnotatedIOBuffer ``` Co-authored-by: Dilum Aluthge <dilum@aluthge.com>
This is an alternative to #53642 The `dom_edges()` for an exit block in the CFG are empty when computing the PostDomTree so the loop below this may not actually run. In that case, the right semidominator is the ancestor from the DFSTree, which is the "virtual" -1 block. This resolves half of the issue in #53613: ```julia julia> let code = Any[ # block 1 GotoIfNot(Argument(2), 3), # block 2 ReturnNode(Argument(3)), # block 3 (we should visit this block) Expr(:call, throw, "potential throw"), ReturnNode(), # unreachable ] ir = make_ircode(code; slottypes=Any[Any,Bool,Bool]) visited = BitSet() @test !Core.Compiler.visit_conditional_successors(CC.LazyPostDomtree(ir), ir, #=bb=#1) do succ::Int push!(visited, succ) return false end @test 2 ∈ visited @test 3 ∈ visited end Test Passed ``` This needs some tests (esp. since I don't think we have any DomTree tests at all right now), but otherwise should be good to go.
) This commit fixes the first problem that was found while digging into #53613. It turns out that the post-domtree constructed from regular `IRCode` doesn't work for visiting conditional successors for post-opt analysis in cases like: ```julia julia> let code = Any[ # block 1 GotoIfNot(Argument(2), 3), # block 2 ReturnNode(Argument(3)), # block 3 (we should visit this block) Expr(:call, throw, "potential throw"), ReturnNode(), # unreachable ] ir = make_ircode(code; slottypes=Any[Any,Bool,Bool]) visited = BitSet() @test !Core.Compiler.visit_conditional_successors(CC.LazyPostDomtree(ir), ir, #=bb=#1) do succ::Int push!(visited, succ) return false end @test 2 ∉ visited @test 3 ∈ visited end Test Failed at REPL[14]:16 Expression: 2 ∉ visited Evaluated: 2 ∉ BitSet([2]) ``` This might mean that we need to fix on the `postdominates` end, but for now, this commit tries to get around it by using the augmented post domtree in `visit_conditional_successors`. Since the augmented post domtree is enforced to have a single return, we can keep using the current `postdominates` to fix the issue. However, this commit isn't enough to fix the NeuralNetworkReachability segfault as reported in #53613, and we need to tackle the second issue reported there too (#53613 (comment)).
…54219) When an inconsistent statement doesn’t affect the return value, post-opt analysis will try to refine it to `:consistent`. However this refinement is invalid if the statement could throw, as `:consistent` requires consistent termination. For the time being, this commit implements the most conservative fix. There might be a need to analyze `:nothrow` in a data-flow sensitive way in the post-opt analysis as like we do for `:consistent`. - closes #53613
Previously, any case changes to Annotated{String,Char} types triggered
"fall back to non-annotated type" non-specialised methods. It would be
nice to keep the annotations though, and that can be done so long as we
keep track of any potential changes to the number of bytes taken by each
character on case changes. This is unusual, but can happen with some
letters (e.g. the upper case of 'ſ' is 'S').
To handle this, a helper function annotated_chartransform is introduced.
This allows for efficient uppercase/lowercase methods (about 50%
overhead in managing the annotation ranges, compared to just
transforming a String). The {upper,lower}casefirst and titlecase
transformations are much more inefficient with this style of
implementation, but not prohibitively so. If somebody has a bright idea,
or they emerge as an area deserving of more attention, the performance
characteristics can be improved.
As a bonus, a specialised textwidth method is implemented to avoid the
generic fallback, providing a ~12x performance improvement.
To check that annotated_chartransform is accurate, as are the
specialised case-transformations, a few million random collections of
strings were pre- and post-annotated and checked to be the same in a
fuzzing check performed with Supposition.jl.
const short_str = Data.Text(Data.Characters(), max_len=20)
const short_strs = Data.Vectors(short_str, max_size=10)
const case_transform_fn = Data.SampledFrom((uppercase, lowercase))
function annot_caseinvariant(f::Function, strs::Vector{String})
annot_strs =
map(((i, s),) -> AnnotatedString(s, [(1:ncodeunits(s), :i => i)]),
enumerate(strs))
f_annot_strs =
map(((i, s),) -> AnnotatedString(s, [(1:ncodeunits(s), :i => i)]),
enumerate(map(f, strs)))
pre_join = Base.annotated_chartransform(join(annot_strs), f)
post_join = join(f_annot_strs)
pre_join == post_join
end
@check max_examples=1_000_000 annot_caseinvariant(case_transform_fn, short_strs)
This helped me determine that in annotated_chartransform the "- 1" was
needed with offset position calculation, and that in the "findlast"
calls that less than *or equal* was the correct equality test.
(cherry picked from commit 38a9725)
The AnnotatedString(::AnnotatedChar) constructor actually does not exist. Considering that String(::Char) is not defined, and we don't try this anywhere else, the obvious fix is to just construct the appropriate AnnotatedString here. We can think about more properly Char-optimised writes in the future if it comes up. (cherry picked from commit 42b3134)
(cherry picked from commit 148330e)
* `IdSet{T}` has values of type `T`, not `V`
* Test the example
* Properly format the example
(cherry picked from commit a84ed82)
This reverts part of 67b8ac0 (#47596 (comment)). That change broke `make install` from tarballs due to building docs again, which fails as there's no git repo (and also requires Internet access to download UnicodeData.txt. Fixes #54037. (cherry picked from commit d6dda7c)
…k adj/trans (#54151) Fixes the following issue on master, where the zero element is computed incorrectly (but subsequent terms are computed correctly): ```julia julia> using LinearAlgebra julia> x = [1 2 3; 4 5 6]; julia> A = reshape([x,2x,3x,4x],2,2); julia> b = fill(x, 2); julia> A' * b ERROR: DimensionMismatch: matrix A has axes (Base.OneTo(2),Base.OneTo(3)), matrix B has axes (Base.OneTo(2),Base.OneTo(3)) Stacktrace: [1] _generic_matmatmul!(C::Matrix{Int64}, A::Matrix{Int64}, B::Matrix{Int64}, _add::LinearAlgebra.MulAddMul{true, true, Bool, Bool}) @ LinearAlgebra ~/.julia/juliaup/julia-nightly/share/julia/stdlib/v1.12/LinearAlgebra/src/matmul.jl:849 [2] generic_matmatmul! @ ~/.julia/juliaup/julia-nightly/share/julia/stdlib/v1.12/LinearAlgebra/src/matmul.jl:834 [inlined] [3] _mul! @ ~/.julia/juliaup/julia-nightly/share/julia/stdlib/v1.12/LinearAlgebra/src/matmul.jl:287 [inlined] [4] mul! @ ~/.julia/juliaup/julia-nightly/share/julia/stdlib/v1.12/LinearAlgebra/src/matmul.jl:285 [inlined] [5] mul! @ ~/.julia/juliaup/julia-nightly/share/julia/stdlib/v1.12/LinearAlgebra/src/matmul.jl:253 [inlined] [6] * @ ~/.julia/juliaup/julia-nightly/share/julia/stdlib/v1.12/LinearAlgebra/src/matmul.jl:114 [inlined] [7] _generic_matvecmul!(C::Vector{Matrix{…}}, tA::Char, A::Matrix{Matrix{…}}, B::Vector{Matrix{…}}, _add::LinearAlgebra.MulAddMul{true, true, Bool, Bool}) @ LinearAlgebra ~/.julia/juliaup/julia-nightly/share/julia/stdlib/v1.12/LinearAlgebra/src/matmul.jl:797 [8] generic_matvecmul! @ ~/.julia/juliaup/julia-nightly/share/julia/stdlib/v1.12/LinearAlgebra/src/matmul.jl:755 [inlined] [9] _mul! @ ~/.julia/juliaup/julia-nightly/share/julia/stdlib/v1.12/LinearAlgebra/src/matmul.jl:73 [inlined] [10] mul! @ ~/.julia/juliaup/julia-nightly/share/julia/stdlib/v1.12/LinearAlgebra/src/matmul.jl:70 [inlined] [11] mul! @ ~/.julia/juliaup/julia-nightly/share/julia/stdlib/v1.12/LinearAlgebra/src/matmul.jl:253 [inlined] [12] *(A::Adjoint{Adjoint{Int64, Matrix{Int64}}, Matrix{Matrix{Int64}}}, x::Vector{Matrix{Int64}}) @ LinearAlgebra ~/.julia/juliaup/julia-nightly/share/julia/stdlib/v1.12/LinearAlgebra/src/matmul.jl:60 [13] top-level scope @ REPL[10]:1 Some type information was truncated. Use `show(err)` to see complete types. ``` After this PR, ```julia julia> A' * b 2-element Vector{Matrix{Int64}}: [51 66 81; 66 87 108; 81 108 135] [119 154 189; 154 203 252; 189 252 315] ``` (cherry picked from commit 2b878f0)
- fix #52355 using option 4 (round to nearest representable integer) - update docstrings *including documenting convert to Inf behavior even though Inf is not the "closest" floating point value* - add some assorted tests --------- Co-authored-by: mikmoore <95002244+mikmoore@users.noreply.github.com> (cherry picked from commit e7a1def)
(cherry picked from commit 65f74bc)
Co-authored-by: Lilith Orion Hafner <lilithhafner@gmail.com> (cherry picked from commit c28a9de)
Memo to self: * update version number in `stdlib/OpenBLAS_jll/Project.toml` * update version number and sha in `deps/openblas.version` * refresh checksums with `make -f contrib/refresh_checksums.mk -j openblas` See the [release notes of v0.3.27](https://github.com/OpenMathLib/OpenBLAS/releases/tag/v0.3.27). (cherry picked from commit 8423426)
A common idiom used throughout the codebase is to get a pointer to thread-local-state through `jl_current_task->ptls`. Create a phantom task for GC threads so that we can make use of this idiom when running in the GC threads as well. Idea originally suggested by @vchuravy, bugs are mine. (cherry picked from commit 9636ef7)
I checked and updated the three related files to make sure command-line documentations are the same in all of them. Previously mentioned in #52645 (comment) --------- Co-authored-by: Matt Bauman <mbauman@gmail.com> (cherry picked from commit a931fbe)
…ar. (#53675) Noticed when working on 02f27c2. The substitution and re-sorting of inner vars are incomplete on master. This commit re-organized the code by: 1. Flatten the inner vars into a reversed list and handling them just like vars in norm bindings. 2. Then perform a global re-sorting on all vars. 3. After that, the inner vars get frozen and dependent bounds are refreshed. (cherry picked from commit 3d34f11)
…ation (#54514) Adopt suggestions from #54465 (review) and fix various added regession & residual MWE. (cherry picked from commit af545b9)
KristofferC
force-pushed
the
backports-release-1.11
branch
from
d67cc7d to
5b15ed7
Compare
|
If it's merged in time, could #54571 be backported too? It's pretty important for developing Distributed on 1.11. |
This reverts commit fcad4b9.
TL;DR: we changed to loading stdlibs exclusively from the default sysimg in #53326, and this breaks developing Distributed.jl because the workers will load the builtin version instead of the development version. I think this should be backported to 1.11? CC @jpsamaroo --- `Base.require_stdlib()` will exclusively load a stdlib from whatever was shipped with Julia. The problem is that when developing Distributed.jl this will cause the workers to always load the builtin Distributed module instead of the development version, which can break everything because now the master and worker are running different (potentially incompatible) versions of Distributed. This commit changes Base and LinearAlgebra to use `Base.require()` instead, which will respect `Base.LOAD_PATH`. I argue that this is safe because unlike the other stdlibs like REPL or Pkg, Distributed is only loaded if explicitly requested by the user with `-p` or through `addprocs()` or something, so it shouldn't be possible to get into quite the same tools-are-broken-because-I-broke-my-tools situation that motivated using `Base.require_stdlib()` in the first place. An alternative design would be to: 1. Move the if-block loading Distributed in `exec_options()` below the for-loop where it will execute `-e` options. 2. Require any implementation of `Distributed.launch(::ClusterManager)` to pass `-e 'using Distributed'` in their command to ensure that Distributed is loaded in a way respecting `Base.LOAD_PATH`. This would be more consistent with how the other stdlibs must be developed, but it requires implementers (i.e. Distributed and ClusterManagers.jl) to opt-in to allowing development versions of Distributed, which feels very annoying and easy to miss so I decided not to implement that. (cherry picked from commit 3b922b0)
|
@nanosoldier |
… package precompilation (#53972) In the parallel package precompilation code we are mapping what packages depend on what other packages so that we precompile things in the correct order ("bottom up") and so what we can also detect cycles and avoid precompiling packages in those cycles. However, we fail to detect one type of dependency which is that an extension can "indirectly" depend on another extension. This happens when the transitive dependencies of the extension (it's parent + triggers) are a superset of the dependencies of another extension. In other words, this means that the other extension will get loaded into the first extension once it gets loaded, effectively being a dependency. The failure to model this leads to some issues, for example using one of the examples in our own tests: ```julia julia> Base.active_project() "/home/kc/julia/test/project/Extensions/HasDepWithExtensions.jl/Project.toml" (HasDepWithExtensions) pkg> status --extensions Project HasDepWithExtensions v0.1.0 Status `~/julia/test/project/Extensions/HasDepWithExtensions.jl/Project.toml` [4d3288b3] HasExtensions v0.1.0 `../HasExtensions.jl` ├─ ExtensionFolder [ExtDep, ExtDep2] ├─ Extension [ExtDep] └─ LinearAlgebraExt [LinearAlgebra] julia> Base.Precompilation.precompilepkgs(; timing=true) Precompiling all packages... 196.1 ms ✓ HasExtensions 244.4 ms ✓ ExtDep2 207.9 ms ✓ SomePackage 201.6 ms ✓ ExtDep 462.5 ms ✓ HasExtensions → ExtensionFolder 200.1 ms ✓ HasExtensions → Extension 173.1 ms ✓ HasExtensions → LinearAlgebraExt 222.2 ms ✓ HasDepWithExtensions 8 dependencies successfully precompiled in 2 seconds julia> Base.Precompilation.precompilepkgs(; timing=true) Precompiling all packages... 213.4 ms ✓ HasExtensions → ExtensionFolder 1 dependency successfully precompiled in 0 seconds. 7 already precompiled. julia> Base.Precompilation.precompilepkgs(; timing=true) julia> ``` We can see here that `ExtensionFolder` gets precompiled twice which is due to `Extension` actually being an "indirect dependency" of `ExtensionFolder` and therefore should be precompiled before it. With this PR we instead get: ```julia julia> Precompilation.precompilepkgs(; timing=true) Precompiling all packages... 347.5 ms ✓ ExtDep2 294.0 ms ✓ SomePackage 293.2 ms ✓ HasExtensions 216.5 ms ✓ HasExtensions → LinearAlgebraExt 554.9 ms ✓ ExtDep 580.9 ms ✓ HasExtensions → Extension 593.8 ms ✓ HasExtensions → ExtensionFolder 261.3 ms ✓ HasDepWithExtensions 8 dependencies successfully precompiled in 2 seconds julia> Precompilation.precompilepkgs(; timing=true) julia> ``` `Extension` is precompiled after `ExtensionFolder` and nothing happens on the second call. Also, with this PR we get for the issue in #53081 (comment): ```julia (jl_zuuRGt) pkg> st Status `/private/var/folders/tp/2p4x9ygx48sgsdl1ccg1mp_40000gn/T/jl_zuuRGt/Project.toml` ⌃ [d236fae5] PreallocationTools v0.4.17 ⌃ [0c5d862f] Symbolics v5.16.1 Info Packages marked with ⌃ have new versions available and may be upgradable. julia> Precompilation.precompilepkgs(; timing=true) ┌ Warning: Circular dependency detected. Precompilation will be skipped for: │ SymbolicsPreallocationToolsExt │ SymbolicsForwardDiffExt ``` and we avoid precompiling the problematic extensions. This should also allow extensions to precompile in parallel which I think was prevented before (from the code that is removed in the beginning of the diff). (cherry picked from commit df89440)
Fixes #54439. - Lock around concurrent accesses to .logs, .message_limits, and .shouldlog_args. - Copy the vector out of the logger at the end, to shield against dangling Tasks. Before: ```julia julia> Threads.nthreads() 8 julia> function foo(n) @info "Doing foo with n=$n" @sync for i=1:n Threads.@Spawn @info "Iteration $i" end 42 end foo (generic function with 1 method) julia> for _ in 1:1000 @test_logs (:info,"Doing foo with n=10000") match_mode=:any foo(10_000) end julia+RAI(56155,0x1f5157ac0) malloc: double free for ptr 0x128248000 julia+RAI(56155,0x1f5157ac0) malloc: *** set a breakpoint in malloc_error_break to debug [56155] signal (6): Abort trap: 6 in expression starting at REPL[8]:1 signal (6) thread (1) __pthread_kill at /usr/lib/system/libsystem_kernel.dylib (unknown line) Allocations: 54370881 (Pool: 54363911; Big: 6970); GC: 119 [1] 56154 abort julia -tauto ``` After: ```julia julia> Threads.nthreads() 8 julia> function foo(n) @info "Doing foo with n=$n" @sync for i=1:n Threads.@Spawn @info "Iteration $i" end 42 end foo (generic function with 1 method) julia> for _ in 1:1000 @test_logs (:info,"Doing foo with n=10000") match_mode=:any foo(10_000) end ``` (no crash) :) (cherry picked from commit 0437210)
(cherry picked from commit 0c65f6f)
|
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:
view(::Memory, ::Colon)produce a Vector #54005Base.literal_powforAbstractQ#54010skip(s::IOBuffer, typemax(Int64))#54070partialsortperm#54137make installfrom tarballs #54143_generic_matvecmul!for block adj/trans #54151publicstatement toBase.GC#54213_checked_mul_dimsin the presence of 0s and overflow. #54255readuntil#54259Hermitianwith non-vanishing imaginary part on diagonal #54276package_callbacksto run multiple time for a single package #54243fieldcountconstant-folds forTuple{...}#54239main(args)instead ofmain(ARGS)#54288LimitedAccuracyinhandle_global_assignment!#54130finish_unionall#54465@doc xwork without REPL loaded #54499mmapto the correct object #54210pkg_modelookup #54359Non-merged PRs with backport label:
String(::Memory)copy #54457@consistent_overlaymacro #54322AbstractPipepublic #54191jl_getaffinityandjl_setaffinity#53402include_dependencywith non-existent file or directory #53286