Segfault during handle finalization

[iamfedoroff]

The issue was originally reported here:
https://discourse.julialang.org/t/cuarrays-v2-0-1-results-in-segmentation-fault-for-linearalgebra-mul

The following code with CuArrays v2.0.1 results in segmentation fault on my computer:

import CuArrays
import LinearAlgebra

N = 1024

y = CuArrays.zeros(N)
x = CuArrays.zeros(N)
A = CuArrays.zeros((N, N))

LinearAlgebra.mul!(y, A, x)

signal (11): Segmentation fault
in expression starting at none:0
unknown function (ip: 0x7f353fd6d319)
unknown function (ip: 0x846075f)
Allocations: 25167531 (Pool: 25160529; Big: 7002); GC: 23
Segmentation fault (core dumped)

With previous version of CuArrays v1.7.3 everything works well.
Additional info:

julia> versioninfo()
Julia Version 1.4.0
Commit b8e9a9ecc6 (2020-03-21 16:36 UTC)
Platform Info:
  OS: Linux (x86_64-pc-linux-gnu)
  CPU: Intel(R) Core(TM) i7-8750H CPU @ 2.20GHz
  WORD_SIZE: 64
  LIBM: libopenlibm
  LLVM: libLLVM-8.0.1 (ORCJIT, skylake)

julia> import CUDAnative
julia> CUDAnative.version()
v"10.2.89"

$ nvcc --version
nvcc: NVIDIA (R) Cuda compiler driver
Copyright (c) 2005-2019 NVIDIA Corporation
Built on Fri_Feb__8_19:08:17_PST_2019
Cuda compilation tools, release 10.1, V10.1.105

Usually I run the code from the terminal, passing the filename as the argument to "julia" command. Then the segfault appears after all commands in the file are finished, that is, the code does not interrupts at "mul!" line.
When I use REPL the segfault appears after I close the REPL session.

The gdb backtrace:

julia> exit()

Thread 1 "julia" received signal SIGSEGV, Segmentation fault.
0x00007fff85d6d319 in ?? ()
   from /home/fedoroff/.julia/artifacts/93956fcdec9ac5ea76289d25066f02c2f4ebe56e/lib/libcublas.so
(gdb) bt
#0  0x00007fff85d6d319 in ?? ()
   from /home/fedoroff/.julia/artifacts/93956fcdec9ac5ea76289d25066f02c2f4ebe56e/lib/libcublas.so
JuliaGPU/CuArrays.jl#1  0x00007fff85d6de36 in ?? ()
   from /home/fedoroff/.julia/artifacts/93956fcdec9ac5ea76289d25066f02c2f4ebe56e/lib/libcublas.so
JuliaGPU/CuArrays.jl#2  0x00007fff85dfbf87 in cublasDestroy_v2 ()
   from /home/fedoroff/.julia/artifacts/93956fcdec9ac5ea76289d25066f02c2f4ebe56e/lib/libcublas.so
JuliaGPU/CuArrays.jl#3  0x00007fffcb192345 in ?? ()
JuliaGPU/CuArrays.jl#4  0x00007fffcb192270 in ?? ()
JuliaGPU/CuArrays.jl#5  0x00007fffb7501ec0 in ?? ()
JuliaGPU/CuArrays.jl#6  0x00007fffca9f2a80 in ?? ()
JuliaGPU/CuArrays.jl#7  0x00007ffff7fc54a0 in ?? ()
JuliaGPU/CuArrays.jl#8  0x00007fffca9f2c18 in ?? ()
JuliaGPU/CuArrays.jl#9  0x00007fffb7501ec0 in ?? ()
JuliaGPU/CuArrays.jl#10 0x00007fffca9f2bd0 in ?? ()
JuliaGPU/CuArrays.jl#11 0x00007fffcb192518 in ?? ()
JuliaGPU/CuArrays.jl#12 0x00007fffca9f2a30 in ?? ()
JuliaGPU/CuArrays.jl#13 0x0000000000799608 in ?? ()
JuliaGPU/CuArrays.jl#14 0x00007fffca9f2ab0 in ?? ()
JuliaGPU/CuArrays.jl#15 0x00007fffb7501ec0 in ?? ()
JuliaGPU/CuArrays.jl#16 0x000000000000000c in ?? ()
JuliaGPU/CuArrays.jl#17 0x00007fffca9f2be0 in ?? ()
JuliaGPU/CuArrays.jl#18 0x00007fffb7501ec0 in ?? ()
JuliaGPU/CuArrays.jl#19 0x00007fffb7501ec0 in ?? ()
JuliaGPU/CuArrays.jl#20 0x0000000000000000 in ?? ()

[maleadt]

As I suspected, this happens during handle finalization. Is this when exiting the process? I wouldn't expect tasks, or handles, getting destroyed during normal REPL operation (unless you're using @async?).

[iamfedoroff]

Is this when exiting the process?

I guess so.
Just a normal REPL session with only the above commands.
As soon as exit it by typing "exit()" I see the segfault message.

[maleadt]

As soon as exit it by typing "exit()" I see the segfault message.

OK, but that's an important distinction. It doesn't happen when performing other computations, only when exiting. We could probably skip finalization then, as the process is being torn down anyway.

[iamfedoroff]

Yeah. It seems that the calculations are not affected. But if I use such code in tests they fail. And in general, segfaults look scary.

[maleadt]

There's been a lot of fixes wrt. how handles and data is freed during finalization, please test with current master and (re)open an issue if this still occurs.