"Please submit a bug report" - How to proceed?

General Usage
1

Hi everyone,

I was working on a project, during which eventually Julia crashed and asked me to

“Please submit a bug report with steps to reproduce this fault, and any error messages that follow (in their entirety). Thanks.”

The error messages were very lengthy and I include it (together with a version info) at the end of the post. Before that happened, Julia also ended up crashing at the same place displaying the error message:

The terminal process "C:\Users\matth\AppData\Local\Microsoft\WindowsApps\julia.exe '-i', '--banner=no', '--project=c:\Users\matth\Documents\[path_to_project]', 'c:\Users\matth\.vscode\extensions\julialang.language-julia-1.79.2\scripts\terminalserver\terminalserver.jl', '\\.\pipe\vsc-jl-repl-03a47384-b5af-432a-b3e4-3b88f251d4d0', '\\.\pipe\vsc-jl-cr-44e41773-6d03-4706-85b3-cdfb1bbf4c9e', 'USE_REVISE=true', 'USE_PLOTPANE=true', 'USE_PROGRESS=true', 'ENABLE_SHELL_INTEGRATION=false', 'DEBUG_MODE=false'" terminated with exit code: -1073740940.

([path_to_project] is the location of the local module I was working on).

I understand that you should submit a MWE. However, the error occured in a function that is part of a big local module and I couldn’t easily reproduce it outside it.
Thus, I am wondering what is the recommended procedure in such a case?
I don’t want to make said module publicly available at this point.

Below is a versioninfo() and the error message:

Julia Version 1.10.2
Commit bd47eca2c8 (2024-03-01 10:14 UTC)
Build Info:
  Official https://julialang.org/ release
Platform Info:
  OS: Windows (x86_64-w64-mingw32)
  CPU: 16 × 11th Gen Intel(R) Core(TM) i7-11800H @ 2.30GHz
  WORD_SIZE: 64
  LIBM: libopenlibm
  LLVM: libLLVM-15.0.7 (ORCJIT, tigerlake)
Threads: 4 default, 0 interactive, 2 GC (on 16 virtual cores)
Environment:
  JULIA_NUM_THREADS = 4
  JULIA_EDITOR = code

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 0x7fff5afcbe8d -- RtlGetCurrentServiceSessionId at C:\WINDOWS\SYSTEM32\ntdll.dll (unknown line)
in expression starting at REPL[6]:1
RtlGetCurrentServiceSessionId at C:\WINDOWS\SYSTEM32\ntdll.dll (unknown line)
RtlFreeHeap at C:\WINDOWS\SYSTEM32\ntdll.dll (unknown line)
free at C:\WINDOWS\System32\msvcrt.dll (unknown line)
aligned_free at C:\WINDOWS\System32\msvcrt.dll (unknown line)
jl_free_aligned at C:/workdir/src\gc.c:262 [inlined]
jl_gc_free_array at C:/workdir/src\gc.c:1200 [inlined]
sweep_malloced_arrays at C:/workdir/src\gc.c:1226 [inlined]
gc_sweep_other at C:/workdir/src\gc.c:1507 [inlined]
_jl_gc_collect at C:/workdir/src\gc.c:3393
ijl_gc_collect at C:/workdir/src\gc.c:3538
maybe_collect at C:/workdir/src\gc.c:937 [inlined]
jl_gc_pool_alloc_inner at C:/workdir/src\gc.c:1293 [inlined]
jl_gc_pool_alloc_noinline at C:/workdir/src\gc.c:1350
jl_gc_alloc_ at C:/workdir/src\julia_internal.h:476 [inlined]
_new_array_ at C:/workdir/src\array.c:144 [inlined]
_new_array at C:/workdir/src\array.c:198 [inlined]
ijl_alloc_array_2d at C:/workdir/src\array.c:443
Array at .\boot.jl:479 [inlined]
Array at .\boot.jl:487 [inlined]
zeros at .\array.jl:636 [inlined]
zeros at .\array.jl:632 [inlined]
#Hetblock_objective#158 at c:\Users\matth\Documents\Research\[location_of_function]\get_Hetblock.jl:129
Hetblock_objective at c:\Users\matth\Documents\Research\[location_of_function]\get_Hetblock.jl:115 [inlined]
obj_fun at c:\Users\matth\Documents\Research\[location_of_function]\get_Hetblock.jl:50 [inlined]
#164 at c:\Users\matth\Documents\Research\[location_of_function]\get_Hetblock.jl:75
derivative at C:\Users\matth\.julia\packages\ForwardDiff\vXysl\src\derivative.jl:14 [inlined]
#get_Hetblock#163 at c:\Users\matth\Documents\Research\[location_of_function]\get_Hetblock.jl:75
get_Hetblock at c:\Users\matth\Documents\Research\[location_of_function]\get_Hetblock.jl:5
unknown function (ip: 0000020079dba863)
jl_apply at C:/workdir/src\julia.h:1982 [inlined]
do_call at C:/workdir/src\interpreter.c:126
eval_value at C:/workdir/src\interpreter.c:223
eval_stmt_value at C:/workdir/src\interpreter.c:174 [inlined]
eval_body at C:/workdir/src\interpreter.c:635
jl_interpret_toplevel_thunk at C:/workdir/src\interpreter.c:775
jl_toplevel_eval_flex at C:/workdir/src\toplevel.c:934
jl_toplevel_eval_flex at C:/workdir/src\toplevel.c:877
jl_toplevel_eval_flex at C:/workdir/src\toplevel.c:877
jl_toplevel_eval_flex at C:/workdir/src\toplevel.c:877
ijl_toplevel_eval at C:/workdir/src\toplevel.c:943 [inlined]
ijl_toplevel_eval_in at C:/workdir/src\toplevel.c:985
eval at .\boot.jl:385 [inlined]
eval at .\Base.jl:88 [inlined]
repleval at c:\Users\matth\.vscode\extensions\julialang.language-julia-1.79.2\scripts\packages\VSCodeServer\src\repl.jl:229
#112 at c:\Users\matth\.vscode\extensions\julialang.language-julia-1.79.2\scripts\packages\VSCodeServer\src\repl.jl:192
unknown function (ip: 000002007f00bd3b)
with_logstate at .\logging.jl:515
with_logger at .\logging.jl:627 [inlined]
#111 at c:\Users\matth\.vscode\extensions\julialang.language-julia-1.79.2\scripts\packages\VSCodeServer\src\repl.jl:193
unknown function (ip: 000002007f00ba5b)
jl_apply at C:/workdir/src\julia.h:1982 [inlined]
jl_f__call_latest at C:/workdir/src\builtins.c:812
#invokelatest#2 at .\essentials.jl:892 [inlined]
invokelatest at .\essentials.jl:889
unknown function (ip: 000002007f00a68b)
jl_apply at C:/workdir/src\julia.h:1982 [inlined]
do_apply at C:/workdir/src\builtins.c:768
#64 at c:\Users\matth\.vscode\extensions\julialang.language-julia-1.79.2\scripts\packages\VSCodeServer\src\eval.jl:34
unknown function (ip: 000002007efeb474)
jl_apply at C:/workdir/src\julia.h:1982 [inlined]
start_task at C:/workdir/src\task.c:1238
Allocations: 88375548 (Pool: 88171395; Big: 204153); GC: 158

Note: get_Hetblock.jl is the code file which contains the function that makes Julia crash. I again removed the specific path on my PC.

2 Likes
2

Hi, Matthias! I suspect there is not enough information here to figure out how to proceed. You are right that MWE are best – if you can not create the MWE yourself, community members probably will try to help create one if they have the time. Thus, to proceed I will basically list things that can help us figure out how to make a MWE:

  • I am not sure whether what you have posted is actually the whole error message. You said that something reported “Please submit a bug report with steps to reproduce this fault, and any error messages that follow (in their entirety). Thanks”, but I do not see that in the stack trace you have copied at the bottom.

  • Was the “please submit bug report” from julia, from a julia standard library, or from some other library in your julia install? Or maybe it was from the terminal or IDE that was running your julia session?

  • Any particular julia libraries that you have installed and working with when this happened? Reporting the output of Pkg.status() could help.

3

This is going tk be tricky. Julia appears to be trying to free some memory that was already freed. This is unusual.

Do you or any of the packages you use invoke unsafe_wrap at all? Are you using a C library?

1 Like
4

Thanks for the replies!

I am not sure whether what you have posted is actually the whole error message.

I think it should be, I just omitted the initial line asking to submit the bug report. Will edit the above post to include it for the sake of completeness. The Pkg.staus() is as follows:

Project Name_of_module v1.0.0-DEV
Status `C:\Users\matth\Documents\[Path_to_module]\Project.toml`
⌃ [0a1fb500] BlockDiagonals v0.1.41
⌃ [052768ef] CUDA v4.4.0
⌃ [944b1d66] CodecZlib v0.7.2
⌃ [31c24e10] Distributions v0.25.99
⌃ [7a1cc6ca] FFTW v1.7.1
⌃ [5789e2e9] FileIO v1.16.1
⌃ [f6369f11] ForwardDiff v0.10.35
⌃ [033835bb] JLD2 v0.4.33
⌃ [ba0b0d4f] Krylov v0.9.2
⌃ [bdcacae8] LoopVectorization v0.12.165
⌃ [33e6dc65] MKL v0.6.0
  [0c723cd3] MKLSparse v1.1.0
  [2774e3e8] NLsolve v4.5.1
  [d96e819e] Parameters v0.12.3
⌃ [91a5bcdd] Plots v1.38.17
⌃ [f2b01f46] Roots v2.0.17
  [efcf1570] Setfield v1.1.1
⌃ [47a9eef4] SparseDiffTools v2.4.1
  [37e2e46d] LinearAlgebra
  [2f01184e] SparseArrays v1.10.0
Info Packages marked with ⌃ have new versions available and may be upgradable.

I don’t call C or unsafe_wrap explicitly.

I actually have more details on what is causing the crash, I just find it hard to make sense of it. As you can see in the above report, there is a function called get_Hetblock that causes the crash. Inside the function, there is a part that calls the following function:

function get_Exp(Λ,y_ss::Vector,T_final::Int)

	Exp = zeros(length(y_ss),T_final+1)
	Exp[:,1] = y_ss

	for tt = 2:(T_final+1)
		Exp[:,tt] = Λ*Exp[:,tt-1]
	end

	return Exp
	
end

Λ is a big sparse matrix (think size 100.000 x 100.000 with density of approx 1e-4) and y_ss a vector of appropriate length. Both have Float64 numbers. Right now I am choosing T_final=20 for testing purposes.
Now, inside the function get_Hetblock, if I replace the line calling that function get_Exp with something producing a matrix of the same size, e.g. Exp = zeros(length(y_ss),T_final+1)) instead of Exp = get_Exp(Λ,y_ss,T_final) the whole function runs without problem (although I get nonsense results of course).
But I don’t understand how a function as simple as get_Exp can cause Julia to crash. There does not seem to be a memory issue (although the involved arrays are large, I don’t seem close to running out).

For context, mostly I am seeing the shorter crash message

The terminal process "C:\Users\matth\AppData\Local\Microsoft\WindowsApps\julia.exe '-i', '--banner=no', '--project=c:\Users\matth\Documents\[path_to_project]', 'c:\Users\matth\.vscode\extensions\julialang.language-julia-1.79.2\scripts\terminalserver\terminalserver.jl', '\\.\pipe\vsc-jl-repl-03a47384-b5af-432a-b3e4-3b88f251d4d0', '\\.\pipe\vsc-jl-cr-44e41773-6d03-4706-85b3-cdfb1bbf4c9e', 'USE_REVISE=true', 'USE_PLOTPANE=true', 'USE_PROGRESS=true', 'ENABLE_SHELL_INTEGRATION=false', 'DEBUG_MODE=false'" terminated with exit code: -1073740940.

instead of the longer one above. I think I have seen similar errors previously when allocating out of bounds elsewhere, but neither the function get_Hetblock or get_Exp use @inbounds or @turbo.

5

The above line seems particularly problematic. You are allocating a lot on every iteration of the loop. Consider the following.

@views Exp[:,tt] .= Λ*Exp[:,tt-1]
6

I actually had @view there initially but ended up removing it when I tried various things when figuring out what is wrong. It doesn’t make a difference for the problem

Spending some more time of finding out whatever is going on, it seems that the problem is connected to the sparse matrix Λ.

When I shorten the function and just have it return Λ, the following happens:

Λ = get_Hetblock(function_input)

size(Λ)
(102400, 102400)

test = ones(102400)

Λ*test

102400-element Vector{Float64}:
     1.0646220664720984
     0.9630386291956388
     0.2904952117541547
     0.1922509957005939
     ⋮
     0.0
     0.0
 26004.400214252935

Λ*test

102400-element Vector{Float64}:
     1.0646220664720984
     0.9630386291956388
     0.2904952117541547
     0.1922509957005939
     ⋮
     0.0
     0.0
 26056.354945458777

So my sparse Λ matrix is somehow unstable, as indicated by the fact that multiplying it with the same vector twice doesn’t yield the same result.

7

How did you create your sparse matrix?

8

Now I shortened the get_Hetblock function further to return the elements from which Λ is constructed. I proceed as follows: (I added some “sanity check”-steps in between).

julia> S_a, T_a, W_a  = get_Hetblock(inputs);

julia> length(W_a) == length(S_a) == length(T_a)
true

julia> typeof(S_a)
Vector{Int64} (alias for Array{Int64, 1})

julia> typeof(W_a)
Vector{Float64} (alias for Array{Float64, 1})

julia> typeof(T_a)
Vector{Int64} (alias for Array{Int64, 1})

julia> maximum(T_a)
102394

julia> maximum(S_a)
102400

julia> Λ = sparse(S_a,T_a,W_a,102400,102400);

julia> size(Λ)
(102400, 102400)

julia> test = ones(102400);

julia> Λ*test
102400-element Vector{Float64}:
     0.7220915902035762
     0.6868098793764592
     0.798046499487902
     0.3585766186796838
     ⋮
     0.01454902331378176
     0.017083893699063
 18942.108581276374

julia> Λ*test
102400-element Vector{Float64}:
     0.7220915902035762
     0.6868098793764592
     0.798046499487902
     0.3585766186796838
     ⋮
     0.01454902331378176
     0.017083893699063
 25915.496996299524

julia> sum(Λ,dims = 2)
102400×1 Matrix{Float64}:
 1.0000000000000002
 1.0000000000000002
 1.0000000000000002
 1.0000000000000002
 ⋮
 1.0
 1.0
 1.0

I added the last step as it also indicates something is weird. By construction, the rows of matrix Λ are supposed to add up to 1 (up to numerical error). This what you see at the end. So Λ multiplied with a vector of ones should also give a vector of ones (up to numerical precision). But somehow it doesn’t.

I then ran get_Hetblock again and again received a similar error message as posted initially:

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 0x7fff5afcbe8d -- RtlGetCurrentServiceSessionId at C:\WINDOWS\SYSTEM32\ntdll.dll (unknown line)
in expression starting at REPL[26]:1
RtlGetCurrentServiceSessionId at C:\WINDOWS\SYSTEM32\ntdll.dll (unknown line)
RtlFreeHeap at C:\WINDOWS\SYSTEM32\ntdll.dll (unknown line)
free at C:\WINDOWS\System32\msvcrt.dll (unknown line)
aligned_free at C:\WINDOWS\System32\msvcrt.dll (unknown line)
jl_free_aligned at C:/workdir/src\gc.c:262 [inlined]
jl_gc_free_array at C:/workdir/src\gc.c:1200 [inlined]
sweep_malloced_arrays at C:/workdir/src\gc.c:1226 [inlined]
gc_sweep_other at C:/workdir/src\gc.c:1507 [inlined]
_jl_gc_collect at C:/workdir/src\gc.c:3379
ijl_gc_collect at C:/workdir/src\gc.c:3524
maybe_collect at C:/workdir/src\gc.c:937 [inlined]
jl_gc_pool_alloc_inner at C:/workdir/src\gc.c:1293 [inlined]
jl_gc_pool_alloc_noinline at C:/workdir/src\gc.c:1350
jl_gc_alloc_ at C:/workdir/src\julia_internal.h:476 [inlined]
_new_array_ at C:/workdir/src\array.c:144
_new_array at C:/workdir/src\array.c:198 [inlined]
ijl_alloc_array_1d at C:/workdir/src\array.c:436
Array at .\boot.jl:477 [inlined]
similar at .\array.jl:419 [inlined]
getindex at .\array.jl:987
MakeTransition at c:\Users\matth\Documents\Research\[path_to_project]\distribution_utils.jl:135
#get_Hetblock#144 at c:\Users\matth\Documents\Research\[path_to_project]\get_Hetblock.jl:42
get_Hetblock at c:\Users\matth\Documents\Research\[path_to_project]\get_Hetblock.jl:5
unknown function (ip: 000001f6aa8524c1)
jl_apply at C:/workdir/src\julia.h:1982 [inlined]
do_call at C:/workdir/src\interpreter.c:126
eval_value at C:/workdir/src\interpreter.c:223
eval_stmt_value at C:/workdir/src\interpreter.c:174 [inlined]
eval_body at C:/workdir/src\interpreter.c:635
jl_interpret_toplevel_thunk at C:/workdir/src\interpreter.c:775
jl_toplevel_eval_flex at C:/workdir/src\toplevel.c:934
jl_toplevel_eval_flex at C:/workdir/src\toplevel.c:877
jl_toplevel_eval_flex at C:/workdir/src\toplevel.c:877
jl_toplevel_eval_flex at C:/workdir/src\toplevel.c:877
ijl_toplevel_eval at C:/workdir/src\toplevel.c:943 [inlined]
ijl_toplevel_eval_in at C:/workdir/src\toplevel.c:985
eval at .\boot.jl:385 [inlined]
eval at .\Base.jl:88 [inlined]
repleval at c:\Users\matth\.vscode\extensions\julialang.language-julia-1.79.2\scripts\packages\VSCodeServer\src\repl.jl:229
#112 at c:\Users\matth\.vscode\extensions\julialang.language-julia-1.79.2\scripts\packages\VSCodeServer\src\repl.jl:192
unknown function (ip: 000001f6aa6d10cb)
with_logstate at .\logging.jl:515
with_logger at .\logging.jl:627 [inlined]
#111 at c:\Users\matth\.vscode\extensions\julialang.language-julia-1.79.2\scripts\packages\VSCodeServer\src\repl.jl:193
unknown function (ip: 000001f6aa6d0f4b)
jl_apply at C:/workdir/src\julia.h:1982 [inlined]
jl_f__call_latest at C:/workdir/src\builtins.c:812
#invokelatest#2 at .\essentials.jl:892 [inlined]
invokelatest at .\essentials.jl:889
unknown function (ip: 000001f6d7155d5b)
jl_apply at C:/workdir/src\julia.h:1982 [inlined]
do_apply at C:/workdir/src\builtins.c:768
#64 at c:\Users\matth\.vscode\extensions\julialang.language-julia-1.79.2\scripts\packages\VSCodeServer\src\eval.jl:34
unknown function (ip: 000001f6d713b484)
jl_apply at C:/workdir/src\julia.h:1982 [inlined]
start_task at C:/workdir/src\task.c:1238
Allocations: 55876845 (Pool: 55815510; Big: 61335); GC: 72
9

Another update: It seems the culprit was MKLSparse.

After changing using MKL, MKLSparse to just using MKL in my module, the issue appears to have vanished.

Apparently, the MKLSparse package has also faced other (related?) bugs recently.

I commented on their most recent issue discussing the bugs, was not sure whether I should open an issue myself.

2 Likes