Julia crash on `using BLISBLAS`

[droodman]

I'm getting On entry to DPOTRF parameter number 4 had an illegal value and then a crash out of Julia when I do using BLISBLAS. Below is a log in which I uninstall and reinstall Julia 1.11, launch it, create a new package environment, add BLISBLAS and Vcov (an econometrics package), and then do using BLISBLAS, which crashes Julia.

If I don't add Vcov, there is no problem. Or if I do add BLISBLAS@0.1.1, there is no problem.

I'm running Windows 11 on an Intel i9-13900H.

Please let me know if there's any other info I can provide. Thank you.

PS C:\Users\drood> juliaup rm 1.11
      Tidyup Removed Julia 1.11.7+0.x64.w64.mingw32
      Remove Julia channel '1.11' successfully removed.
PS C:\Users\drood> juliaup add 1.11
    Checking for new Julia versions
  Installing Julia 1.11.7+0.x64.w64.mingw32
         Add Installed Julia channel '1.11'
PS C:\Users\drood> julia +1.11
               _
   _       _ _(_)_     |  Documentation: https://docs.julialang.org
  (_)     | (_) (_)    |
   _ _   _| |_  __ _   |  Type "?" for help, "]?" for Pkg help.
  | | | | | | |/ _` |  |
  | | |_| | | | (_| |  |  Version 1.11.7 (2025-09-08)
 _/ |\__'_|_|_|\__'_|  |  Official https://julialang.org/ release
|__/                   |

(@v1.11) pkg> activate C:\Users\drood\.julia\environments\v1.11\test2
  Activating new project at `C:\Users\drood\.julia\environments\v1.11\test2`

(@test2) pkg> add BLISBLAS
   Resolving package versions...
    Updating `C:\Users\drood\.julia\environments\v1.11\test2\Project.toml`
  [6f275bd8] + BLISBLAS v0.2.0
    Updating `C:\Users\drood\.julia\environments\v1.11\test2\Manifest.toml`
  [6f275bd8] + BLISBLAS v0.2.0
  [692b3bcd] + JLLWrappers v1.7.1
  [21216c6a] + Preferences v1.5.0
⌅ [17f450c3] + LAPACK32_jll v3.12.0+1
⌅ [51474c39] + LAPACK_jll v3.12.0+3
  [1d63c593] + LLVMOpenMP_jll v18.1.8+0
  [e47b3055] + blis32_jll v2.0.0+2
  [6136c539] + blis_jll v2.0.0+2
  [56f22d72] + Artifacts v1.11.0
  [ade2ca70] + Dates v1.11.0
  [8f399da3] + Libdl v1.11.0
  [37e2e46d] + LinearAlgebra v1.11.0
  [de0858da] + Printf v1.11.0
  [fa267f1f] + TOML v1.0.3
  [4ec0a83e] + Unicode v1.11.0
  [e66e0078] + CompilerSupportLibraries_jll v1.1.1+0
  [4536629a] + OpenBLAS_jll v0.3.27+1
  [8e850b90] + libblastrampoline_jll v5.11.0+0
        Info Packages marked with ⌅ have new versions available but compatibility constraints restrict them from upgrading. To see why use `status --outdated -m`

(@test2) pkg> add Vcov
   Resolving package versions...
    Updating `C:\Users\drood\.julia\environments\v1.11\test2\Project.toml`
  [ec2bfdc2] + Vcov v0.8.1
    Updating `C:\Users\drood\.julia\environments\v1.11\test2\Manifest.toml`
  [66dad0bd] + AliasTables v1.1.3
  [861a8166] + Combinatorics v1.0.3
  [9a962f9c] + DataAPI v1.16.0
  [864edb3b] + DataStructures v0.19.1
  [e2d170a0] + DataValueInterfaces v1.0.0
  [ffbed154] + DocStringExtensions v0.9.5
  [6407cd72] + GroupedArrays v0.3.4
  [92d709cd] + IrrationalConstants v0.2.6
  [82899510] + IteratorInterfaceExtensions v1.0.0
  [2ab3a3ac] + LogExpFunctions v0.3.29
  [e1d29d7a] + Missings v1.2.0
  [bac558e1] + OrderedCollections v1.8.1
  [43287f4e] + PtrArrays v1.3.0
  [a2af1166] + SortingAlgorithms v1.2.2
  [10745b16] + Statistics v1.11.1
  [82ae8749] + StatsAPI v1.7.1
  [2913bbd2] + StatsBase v0.34.7
  [3783bdb8] + TableTraits v1.0.1
  [bd369af6] + Tables v1.12.1
  [ec2bfdc2] + Vcov v0.8.1
  [9a3f8284] + Random v1.11.0
  [ea8e919c] + SHA v0.7.0
  [9e88b42a] + Serialization v1.11.0
  [2f01184e] + SparseArrays v1.11.0
  [bea87d4a] + SuiteSparse_jll v7.7.0+0

julia> using BLISBLAS
 ** On entry to DPOTRF parameter number  4 had an illegal value
PS C:\Users\drood>

[ViralBShah]

@imciner2 I suspect this is only explained by LBT doing some tests - but I believe the printing is actually from LAPACK itself and not a bug here. I suppose it is calling abort somewhere, but I am quite sure that LAPACK is not badly behaved like that at all.

Also, I don't see the behaviour on mac which is what I am using.

[ViralBShah]

@droodman Any specific reason you are using BLISBLAS (out of curiosity - we should still fix this)? I have generally found it to be slow.

[droodman]

Thanks @ViralBShah. For a package developer wanting to optimize performance across multiple platforms, the landscape is tricky--when to use the default BLAS vs MKL vs BLISBLAS vs AppleAccelerate... Can't remember the exact reasoning but I had settled on BLISBLAS for non-MacOS. But because of this problem I have changed my software to load MKL on Intel CPUs, AppleAccelerate on MacOS, and nothing extra otherwise.

[droodman]

I should explain that my context is unusual. I have embedded Julia in the commercial statistical software called Stata. Using that bridge, I've given users access to a much faster, Julia-based implementation of a popular method while wrapping it in a interface familiar to Stata users. In this context, the user is not expected to know much about Julia, and certainly not think about BLAS libraries, so my software tries to do that for them.

[ViralBShah]

@droodman The challenge currently we have is that picking a BLAS is a global change. So it doesn't just change the BLAS for your package, but for everything else.

My recommendation would be to ask the end users to make the change should they want higher BLAS performance. We need to improve the whole mechanism in general - but this is where we are at.

[imciner2]

Looking at this, I don't think this is actually a crash, but an exit from the LAPACK dpotrf routine in the error handler. Running under WinDBG, this is the strack trace I get

The LAPACK implementation used here is the Reference LAPACK, which has a STOP statement in its default error handler (https://github.com/Reference-LAPACK/lapack/blob/9f4032ec97dcd130be68ecf325b1f2b086d5299c/SRC/xerbla.f#L88). Since the error string is being output, it would seem to be in this error handler. What I don't quite understand is why we aren't seeing this on either the CI runs or on Linux (I can recreate this on Windows locally though). So maybe something in the test runner is more tolerant of the STOP intrinsic and either captures that or ignores it?

The main thing that should fix this will be this PR in Ygg: JuliaPackaging/Yggdrasil#12493. That removes the STOP call (but it will be Julia 1.12 only, due to the LAPACK version being used).

[ViralBShah]

The PR in Ygg should have fixed this. Please reopen if still crashing.

[droodman]

@ViralBShah Ha, I just remembered why I had switched to BLISBLAS.