I’ve run into the following error which I’ve been unable to fix. Whenever I try to run “using *” for any packages (I’ve tried Plots, CSV, JSON, QuadGK, and a few others), it fails to precompile.
The top line of the error is below, following “using Plots”. I’ve tried a completely fresh re-install of Julia. It’s worth noting this problem started spontaneously - my Julia install was working fine one day, the next day this error popped up when I tried to run one of my scripts. Thanks for any help!
1 Like
Welcome,
Which version of Windows do you use, maybe 8 (note it’s not supported, and may be implicated):
Do you use VS Code? I googled your error code…
It shouldn’t be your first guess but after googling the error code, maybe it’s related to a hardware fault (or does it actually mean just similar to segfault?):
Or maybe ENV var related:
Hi, thanks for the swift response! I’m using Windows 10 Pro. I was using VScode, which is when I first ran into the problem, but I uninstalled it a while ago while searching for a solution to my problem. I’ve played around a lot with environment variables, nothing I’ve done (setting various JULIA_* variables, removing others, changing the order) has seemed to have any effect.
My first guess was, since Windows, some enterprise restrictions (or virus checker).
I believe I’ve decoded the error message to (for that field):
FACILITY_SECURITY 9
The source of the error code is the Security API layer.
You can look up error messages with a tool, if I recall err.exe in Windows. Maybe you need it’s hex value C0000139
What I also found (but I think mis-decoded, since least significant is to the left…):
ERROR_NOT_ALLOWED_ON_SYSTEM_FILE313 (0x139)
I think actually I found the right error code here (there are many types… I think I’m now looking up the correct type):
{Entry Point Not Found} The procedure entry point %hs could not be located in the dynamic link library %hs.
I though don’t know the exact cause for that…
I suggest Julia changes to reporting Windows exit codes in hexadecimal, in case more easily googlable that way (but only on Windows, Linux reports in decimal? And has no complex decoding?). And maybe Julia should decode, at least some of the code, like that one, in case helping, and fill in for “%h” the error message. I suppose a try clause is needed…
Likely decode for sub-code:
ERROR_NOT_ALLOWED_ON_SYSTEM_FILE
313 (0x139)Operation is not allowed on a file system internal file.
You can do (to confirm, or deny):
Err_6.4.5.exe <error code>
i.e. needs to use the hex code, here C0000139, similar to:
C:\Tools>Err_6.4.5.exe c000021a
# for hex 0xc000021a / decimal -1073741286
STATUS_SYSTEM_PROCESS_TERMINATED ntstatus.h
# {Fatal System Error}
# The %hs system process terminated unexpectedly with a
# status of 0x%08x (0x%08x 0x%08x).
# The system has been shut down.
# as an HRESULT: Severity: FAILURE (1), FACILITY_NULL (0x0), Code 0x21a
# for hex 0x21a / decimal 538
ERROR_ABIOS_ERROR winerror.h
# An error occurred in the ABIOS subsystem.
# 2 matches found for "c000021a"
I’ll admit to not being the most savvy windows user in the world. If I’m understanding all this, it seems like the system either (a) can’t find the DLLs it needs or (b) is loading conflicting DLLs. Is that right, or have a completely misunderstood?
Thanks again for all your help!
Yes, it’s very strange you can’t precompile ANY packages, especially high-profile like Plots.jl. Are you sure you did noting like update or downgrade its version?
DLLs should be transparent, i.e. Plots.jl and other packages should download those needed (likely for its dependency GR._jll at least), and just work.
I’m not on Windows even, I just got curious, because of the large exit code, and went down a rabbit hole for you (I want to know how they work), can you at least run:
Err_6.4.5.exe C0000139
(@v1.10) pkg> st -m Plots
Status `~/.julia/environments/v1.10/Manifest.toml`
[91a5bcdd] Plots v1.40.4
and confirm same version and if like me behind:
(@v1.10) pkg> st -m GR
Status `~/.julia/environments/v1.10/Manifest.toml`
⌃ [28b8d3ca] GR v0.72.8
update to latest:
(@v1.10) pkg> add GR@v73.5
I think that’s your problem and what changed!
You likely had a 64-bit Julia install (as you “should” when possible).
It seems you installed a 32-bit one, i.e. “i686 (32-bit)” which (STILL) is a “Tier 1” platform, so you strictly didn’t do anything wrong.
I noticed in your error message i386pep that I didn’t recognize (and System32 and ldd.exe and was thinking why…)
[I’m on Linux and at one point I installed 32-bit Julia by accident, i.e. Ubuntu’s snap, I think it’s now 64-bit. It DID work, until it didn’t when using with Python (since it was 64-bit, and hard to mix such together at least on Linux), maybe even it was for/with plotting.]
While 32-bit should ideally just work, note it is no longer supported in Windows 11, and Windows 10 soon out of support, and almost all have 64-bit anyway. I think 32-bit is supported in Julia still to be helpful, so I like to know it it’s actually unhelpful… I know it’s hard to support (for libm), and I will be happy when it’s gone.
Julia can only do it’s part, and it can enable all pure Julia packages, but many are not or have dependencies on DLLs, i.e. so called JLL packages that install them. It’s possible some such doesn’t work for you on 32-bit for some reason.
Are you possibly using an ARM based Windows computer, that needs to emulate 32-bit/Intel? That would be very interesting info to know…
I think I have the 64-bit version installed, the folder containing the binaries reads “julia-1.10.3+0.x64.w64.mingw32”, although I’m seeing that the mingw version is 32 bit somehow?
It’s probably worth noting I installed via the recommended “winget install julia -s msstore” methodology.
I think I’m up to date on Plots and the GR backend.
I know what mingw is but unsure what mingw32 means in this context, so yes it may mean 32-bit, or some part of it is. Then why, or it it like that for all?
While you installed correctly, i.e. “juliaup” is now preferred the way you installed (did you not use originally?), can you try out the old type of download:
https://julialang-s3.julialang.org/bin/winnt/x64/1.10/julia-1.10.3-win64.exe
Note that it’s much easier for everybody involved if you copy-paste the text, rather than posting screenshots. The advantage, besides being actually readable, is that plain text is searchable, text inside pictures is not. But please quote the code
```
like this
```
1 Like
I re-installed from the download, same result unfortunately.
I’m kind of giving up, what does this show:
(@v1.10) pkg> st -m
and:
C:\> Err_6.4.5.exe C0000139
It’s ldd.exe failing for some reason but I no longer think because of 1386pep, i.e. I no longer think it or -mingw32 implies 32-bit, since seeing this:
Mingw-w64 can generate 32 bit and 64-bit executables for x86 under the target names i686-w64-mingw32 and x86_64-w64-mingw32.
Open cmd.exe and try to run lld.exe directly by providing the full path indicated in the error. If you can figure out what is preventing that from running, your issues will be partly solved.
Thanks again for all the help! There does appear to be some issue with lld.exe when I attempt to run it independently.
Output from the error checker is below.
PS C:\Users\gplayer\Downloads> .\Err_6.4.5.exe C0000139
# for hex 0xc0000139 / decimal -1073741511
STATUS_ENTRYPOINT_NOT_FOUND ntstatus.h
# {Entry Point Not Found}
# The procedure entry point %hs could not be located in the
# dynamic link library %hs.
# as an HRESULT: Severity: FAILURE (1), FACILITY_NULL (0x0), Code 0x139
# for hex 0x139 / decimal 313
ERROR_NOT_ALLOWED_ON_SYSTEM_FILE winerror.h
# Operation is not allowed on a file system internal file.
# 2 matches found for "C0000139"
And from Pkg (I only have CSV downloaded for testing):
(@v1.10) pkg> st -m
Status `C:\Users\gplayer\.julia\environments\v1.10\Manifest.toml`
[34da2185] Compat v4.15.0
[864edb3b] DataStructures v0.18.20
[bac558e1] OrderedCollections v1.6.3
[1fd47b50] QuadGK v2.9.4
[56f22d72] Artifacts
[2a0f44e3] Base64
[ade2ca70] Dates
[b77e0a4c] InteractiveUtils
[8f399da3] Libdl
[37e2e46d] LinearAlgebra
[d6f4376e] Markdown
[de0858da] Printf
[9a3f8284] Random
[ea8e919c] SHA v0.7.0
[fa267f1f] TOML v1.0.3
[cf7118a7] UUIDs
[4ec0a83e] Unicode
[e66e0078] CompilerSupportLibraries_jll v1.1.1+0
[4536629a] OpenBLAS_jll v0.3.23+4
[8e850b90] libblastrampoline_jll v5.8.0+1
So I ran lld.exe - I received the following errors:
The procedure entry point _ZSt14__once_functor could not be located in the dynamic link library C:\Users\gplayer.julia\juliaup\julia-1.10.3+0.x64.w64.mingw32\libexec\julia\lld.exe
The procedure entry point _ZSt14__once_functor could not be located in the dynamic link library C:\Users\gplayer.julia\juliaup\julia-1.10.3+0.x64.w64.mingw32\bin\libLLVM-15jl.dll
I’m not sure what to make of this, honestly. Am I trapped in DLL hell?
1 Like
I had no idea about _ZSt14__once_functor, only libLLVM-15jl.dll and looking it up it seems to be a known problem (and solution):
What exactly you did, to cause this, I would like to know. And since it’s a known problem, maybe Julia could do something to mitigate it, more than just explaining the error code or showing it just in hex, rather point to the fix.
2 Likes