Julia v1.3.0-rc4 is now available

My current assumption: Is CSV using threads in 1.3 but not in Julia 1.2? This could explain the failure and it could be bug in Julia or in the CSV package.

To check if this is linked to the calling of the functions itself, you can run the CxxWrap tests, and look for output like this:

Julia test:
  0.102698 seconds (128 allocations: 7.938 KiB)
  0.063683 seconds (4 allocations: 160 bytes)
  0.053773 seconds (4 allocations: 160 bytes)
C test:
  0.123567 seconds (135 allocations: 8.203 KiB)
  0.118030 seconds (4 allocations: 160 bytes)
  0.116455 seconds (4 allocations: 160 bytes)
C++ test:
  0.180980 seconds (7 allocations: 384 bytes)
  0.187293 seconds (4 allocations: 160 bytes)
  0.217453 seconds (4 allocations: 160 bytes)
C++ lambda test:
  2.567566 seconds (7 allocations: 384 bytes)
  2.514374 seconds (4 allocations: 160 bytes)
  2.470426 seconds (4 allocations: 160 bytes)

Here, Julia test is a pure Julia loop, C test is a loop using ccall directly, C++ test calls a C++ function pointer using ccall and C++ lambda passes through a C++ std::function (very slow here because I ran on a debug build).

1 Like

I’m seeing a small difference in the C++ test, 0.188 s with rc4 vs. 0.177 s with rc3. Not enough to explain what I was seeing before.
Wrapping my package test cases in a @btime doesn’t show any difference between the two releases.
I’d have to benchmark my original script in pieces to find the culprit, but I won’t get to it for probably two weeks.

Again, I would suggest bisecting. There are 11 commits between rc3 and rc4, so it would take about 4-5 runs to pin down the relevant commit.

Travis log here: https://travis-ci.com/JuliaFEM/UMAT.jl/jobs/247565737

Please submit a bug report with steps to reproduce this fault, and any error messages that follow (in their entirety). Thanks.
Exception: EXCEPTION_ACCESS_VIOLATION at 0x6b5f32b8 -- gc_try_setmark at /home/Administrator/buildbot/worker/package_win64/build/src/home/Administrator/buildbot/worker/package_win64/build/src\gc.c:1557 [inlined]
gc_mark_scan_objarray at /home/Administrator/buildbot/worker/package_win64/build/src/home/Administrator/buildbot/worker/package_win64/build/src\gc.c:1669 [inlined]
gc_mark_loop at /home/Administrator/buildbot/worker/package_win64/build/src/home/Administrator/buildbot/worker/package_win64/build/src\gc.c:1960

Only Windows 1.3 tests fails in Travis, all others passes.

xref: 1.3-RC4 Windows EXCEPTION_ACCESS_VIOLATION at 0x6b5f32b8 -- gc_try_setmark · Issue #33616 · JuliaLang/julia · GitHub

Do I need to open an issue or is the above sufficient bug report? Nightly build passes maybe the issue is already fixed at master.

I think you should open an issue. That makes sure the right people see it and the fix gets backported. Otherwise you might have to wait for 1.4 for the fix.

Thanks. I did: https://github.com/JuliaLang/julia/issues/33616

1 Like

It’s very likely a user error, especially since there’s a warning for you.

Do you mean this one:
WARNING: Method definition isotropic_elasticity_tensor(Any, Any) in module Materials at C:\Users\travis\.julia\packages\Materials\mSWeT\src\idealplastic.jl:5 overwritten at C:\Users\travis\.julia\packages\Materials\mSWeT\src\chaboche.jl:5.
I believe it’s unrelated, because it’s coming from different package. Of course, that should be fixed because it’s really annoying to wait Materials.jl building when running the tests.

Is anyone getting frequent freezes in the REPL? I was not seeing this in rc3, not sure what it’s related to (seems to happen when I am using the CSV package).

1 Like

@yuyichao was right, after fixing JuliaFEM/Materials.jl#55 the build passes on all platforms, see JuliaFEM/UMAT.jl#14.

Windows 10 1903 build 18362.418. Atom 1.40.1.
I’ve experienced irreproducible memory leakages, endless task spawns at stage of package compilation. At times i switched from rc2 to rc4 without killing Julia session and memory leakage started.

Julia Version 1.3.0-rc4.1
Commit 8c4656b97a (2019-10-15 14:08 UTC)
Platform Info:
  OS: Windows (x86_64-w64-mingw32)
  CPU: AMD A8-6410 APU with AMD Radeon R5 Graphics
  WORD_SIZE: 64
  LIBM: libopenlibm
  LLVM: libLLVM-6.0.1 (ORCJIT, btver2)
Environment:
  JULIA_EDITOR = "C:\Users\acer\AppData\Local\atom\app-1.40.1\atom.exe"  -a
  JULIA_NUM_THREADS = 4

 [c52e3926] Atom v0.11.1
  [6e4b80f9] BenchmarkTools v0.4.3
  [e5e0dc1b] Juno v0.7.2
  [37b6cedf] Traceur v0.3.0
  [b8865327] UnicodePlots v1.1.0

I’ve just executed versioninfo() and status at Pkg prompt and everything is nominal. No such erroneus behaviour is observed at Ubuntu Mate 18.04.5 with rc4. Today i’ve observed, REPL hasn’t quit being busy at the latter system without any evident task assigned. But sole press on “Enter” freed the REPL.

I am really curious how you did that.

1 Like

I’m sorry. I set particular Julia executable through ‘julia-client’ package settings. v1.3.0-rc2 session wasn’t killed automatically, nor, i assume, v1.3.0-rc4.1 was patched through, which was highly unlikely, just as you stated, but memory leakage had pronounced itself at that time.

I would like to emphasize that as much as reporting and discussing issues here is appreciated, it is not a substitute for filing an issue on github with a reproducer. Bugs that are only posted here are unlikely to get fixed.

16 Likes

What about precompilation times or first run times?
I’ve read it’s going to be faster but I haven’t found more details.

Yes, it’s “going to” as in “not yet (in this release), but in the nearish future (maybe even next release), now that threading is getting closer to being finished”.

I had a trouble adding several packages at once (starting with 1.3-rc1), resulting in the following error. I then break the set of packages to install into smaller subsets and all went ok, and now I do no longer have this error.
In julia-1.2 I did manage to get the whole set at once.:

(v1.3) pkg> update
  Updating registry at `~/.julia/registries/General`
  Updating git-repo `https://github.com/JuliaRegistries/General.git`
 Resolving package versions...
  Updating `~/.julia/environments/v1.3/Project.toml`
 [no changes]
  Updating `~/.julia/environments/v1.3/Manifest.toml`
 [no changes]

(v1.3) pkg> add JSON2 XLSX Cxx PyCall RCall DataFrames BenchmarkTools IndexedTables Pipe Plots StatsPlots CSV JuMP GLPK Ipopt SymPy LsqFit Weave ZipFile Interact Plots Mux
 Resolving package versions...
ERROR: MethodError: Cannot `convert` an object of type Pkg.Types.VersionSpec to an object of type VersionNumber
Closest candidates are:
  convert(::Type{T}, ::T) where T at essentials.jl:168
Stacktrace:
 [1] convert(::Type{Union{Nothing, VersionNumber}}, ::Pkg.Types.VersionSpec) at ./some.jl:34
 [2] Pkg.Types.PackageEntry(::String, ::Pkg.Types.VersionSpec, ::Nothing, ::Bool, ::Pkg.Types.GitRepo, ::Nothing, ::Dict{String,Base.UUID}, ::Nothing) at /buildworker/worker/package_linux64/build/usr/share/julia/stdlib/v1.3/Pkg/src/Types.jl:259
 [3] #PackageEntry#26(::String, ::Pkg.Types.VersionSpec, ::Nothing, ::Bool, ::Pkg.Types.GitRepo, ::Nothing, ::Dict{String,Base.UUID}, ::Nothing, ::Type{Pkg.Types.PackageEntry}) at ./util.jl:722
 [4] (::Core.var"#kw#Type")(::NamedTuple{(:name, :version, :pinned, :tree_hash, :path, :repo),Tuple{String,Pkg.Types.VersionSpec,Bool,Nothing,Nothing,Pkg.Types.GitRepo}}, ::Type{Pkg.Types.PackageEntry}) at ./none:0
 [5] update_manifest!(::Pkg.Types.Context, ::Array{Pkg.Types.PackageSpec,1}) at /buildworker/worker/package_linux64/build/usr/share/julia/stdlib/v1.3/Pkg/src/Operations.jl:93
 [6] #add#102(::Bool, ::Pkg.BinaryPlatforms.Linux, ::typeof(Pkg.Operations.add), ::Pkg.Types.Context, ::Array{Pkg.Types.PackageSpec,1}, ::Array{Base.UUID,1}) at /buildworker/worker/package_linux64/build/usr/share/julia/stdlib/v1.3/Pkg/src/Operations.jl:977
 [7] #add at ./none:0 [inlined]
 [8] #add#25(::Bool, ::Pkg.BinaryPlatforms.Linux, ::Base.Iterators.Pairs{Union{},Union{},Tuple{},NamedTuple{(),Tuple{}}}, ::typeof(Pkg.API.add), ::Pkg.Types.Context, ::Array{Pkg.Types.PackageSpec,1}) at /buildworker/worker/package_linux64/build/usr/share/julia/stdlib/v1.3/Pkg/src/API.jl:102
 [9] add(::Pkg.Types.Context, ::Array{Pkg.Types.PackageSpec,1}) at /buildworker/worker/package_linux64/build/usr/share/julia/stdlib/v1.3/Pkg/src/API.jl:72
 [10] do_add!(::Dict{Symbol,Any}, ::Array{Pkg.Types.PackageSpec,1}, ::Dict{Symbol,Any}) at /buildworker/worker/package_linux64/build/usr/share/julia/stdlib/v1.3/Pkg/src/REPLMode.jl:505
 [11] #invokelatest#1(::Base.Iterators.Pairs{Union{},Union{},Tuple{},NamedTuple{(),Tuple{}}}, ::typeof(Base.invokelatest), ::Any, ::Any, ::Vararg{Any,N} where N) at ./essentials.jl:709
 [12] invokelatest(::Any, ::Any, ::Vararg{Any,N} where N) at ./essentials.jl:708
 [13] do_cmd!(::Pkg.REPLMode.Command, ::REPL.LineEditREPL) at /buildworker/worker/package_linux64/build/usr/share/julia/stdlib/v1.3/Pkg/src/REPLMode.jl:412
 [14] #do_cmd#23(::Bool, ::typeof(Pkg.REPLMode.do_cmd), ::REPL.LineEditREPL, ::String) at /buildworker/worker/package_linux64/build/usr/share/julia/stdlib/v1.3/Pkg/src/REPLMode.jl:391
 [15] do_cmd at /buildworker/worker/package_linux64/build/usr/share/julia/stdlib/v1.3/Pkg/src/REPLMode.jl:387 [inlined]
 [16] (::Pkg.REPLMode.var"##28#31"{REPL.LineEditREPL,REPL.LineEdit.Prompt})(::REPL.LineEdit.MIState, ::Base.GenericIOBuffer{Array{UInt8,1}}, ::Bool) at /buildworker/worker/package_linux64/build/usr/share/julia/stdlib/v1.3/Pkg/src/REPLMode.jl:619
 [17] #invokelatest#1 at ./essentials.jl:709 [inlined]
 [18] invokelatest at ./essentials.jl:708 [inlined]
 [19] run_interface(::REPL.Terminals.TextTerminal, ::REPL.LineEdit.ModalInterface, ::REPL.LineEdit.MIState) at /buildworker/worker/package_linux64/build/usr/share/julia/stdlib/v1.3/REPL/src/LineEdit.jl:2306
 [20] run_frontend(::REPL.LineEditREPL, ::REPL.REPLBackendRef) at /buildworker/worker/package_linux64/build/usr/share/julia/stdlib/v1.3/REPL/src/REPL.jl:1039
 [21] run_repl(::REPL.AbstractREPL, ::Any) at /buildworker/worker/package_linux64/build/usr/share/julia/stdlib/v1.3/REPL/src/REPL.jl:201
 [22] (::Base.var"##774#776"{Bool,Bool,Bool,Bool})(::Module) at ./client.jl:390
 [23] #invokelatest#1 at ./essentials.jl:709 [inlined]
 [24] invokelatest at ./essentials.jl:708 [inlined]
 [25] run_main_repl(::Bool, ::Bool, ::Bool, ::Bool, ::Bool) at ./client.jl:374
 [26] exec_options(::Base.JLOptions) at ./client.jl:312
 [27] _start() at ./client.jl:468
1 Like

As noted above, unless you open an issue there is a significant chance that this will be lost in the noise. (If you already opened an issue, then please disregard).