Julia 1.8.* & VSCode & Ryzen CPU & Windows 10 64bit --> crash

[rryi]

I used julia and VSCode with many julia versions without problems, but since julia 1.8.0, I get severe crashes when installing and starting the VSCode julia extension on windows PCs with an AMD Ryzen CPU… I verified it with two PCs with Ryzen CPU and with julia 1.8.0, 1.8.1 and a 1.9 nightly build. It does only happen o machines with Ryzen CPUs. With Intel CPUs, julia 1.8.*+VSCode behave as expected, the same for my Ryzen machines and julia up to julia 1.7.3.

Did anyone encounter similar problems, or has sucessfully installed julia 1.8.* plus VSCode extension on windows with a Ryzen CPU?

I put an issue to the VSCode extension github project, however no comment so far. See for details crash with julia 1.8.0 on Ryzen CPUs · Issue #3048 · julia-vscode/julia-vscode (github.com). And indeed, I think the problem is not originated in the VSCode extension but was introduced with julia 1.8, probably in the LLVM code generation - the crashes let me think there happens a random jump into executable code.

Any help welcome, I really would appreciate developing with julia 1.8 & VSCode on my new Ryzen 7 5800H powernotebook.

[mkoculak]

Hey,
not sure if it is the same issue, but I have similar setup (Ryzen + Windows) and about 1-2 weeks ago started seeing Julia struggling and crashing taking the whole VSCode down (and sometimes crashing my Firefox also). However in my case the same behavior is also present on i7-8700k machine.

Precompile error on Windows

Since last week I am encountering problems with precompilation - with language server on VSCode and with packages in projects. Seems to be the same issue as here, although it seems it should have been fixed. For me, the precompilation becomes stable only when I set the number of processes to 1. Here is the error I get most frequently: ┌ Error: Pkg.precompile error │ exception = │ IOError: could not spawn `'C:\Users\Marcin\AppData\Local\Programs\Julia-1.8.0\bin\julia.exe' -Cnative '-JC:\…

So my best guess was that it is an iteration of an older issue (link to github issue is in the thread above).

You can try to add to your environment this variable:
JULIA_NUM_PRECOMPILE_TASKS = NUMBER
where number should be less then the number of cores in your CPU.
At least that is how they mitigated the issue earlier. For me it reduced the frequency of crashes, only setting it to 1 completely fixed it.

Let us know if this helps your case or not.

[rryi]

Thanks for your suggestion.

I put “JULIA_NUM_PRECOMPILE_TASKS = 1” into the global environment variables, restarted the machine and tried “julia:start REPL”. Results are mixed:

• on my Ryzen 7 5800H notebook, language server did compile, and now I have a REPL in VSCode on that machine. I tried some julia standard library method calls in VSCode julia REPL, julia seems to work. However some more serious testing of stability has to be done.

• on my Ryzen 1700 desktop, behavior did not change. Tried 3 times, always with reboot, in the 3rd try I also deleted VSCode extensions and reinstalled the extension before starting REPL. In all cases, VSCode instance or whole windows crashed. Two times without any message after “[ Info: Precompiling VSCodeServer [9f5989ce-84fe-42d4-91ec-6a7a8d53ed0f]”. Only in the last attempt, I got some log lines in the terminal window:

[ Info: Precompiling VSCodeServer [9f5989ce-84fe-42d4-91ec-6a7a8d53ed0f]
Internal error: encountered unexpected error in runtime:
ReadOnlyMemoryError()

Please submit a bug report with steps to reproduce this fault, and any error messages that follow (in their entirety). Thanks.
Exception: UNKNOWN at 0x7ffe7a144fd9 --

This is one of the messages I got in my numerous attempts without setting JULIA_NUM_PRECOMPILE_TASKS, documented in my julia-vscode issue #3048.

I will continue with some experiments, in particular using (a) a linux VM and (b) a native Linux installation on my notebook to see if the problem is related to OS.

[mkoculak]

Yeah, sounds like a combination of more then one problem that gives similar results.

One place where you can look for more information - there is an output tab in VSCode that has a Julia Language Server option, maybe check there if you haven’t yet.

Maybe you could also check if you see the same error when compiling other packages directly in the REPL? For me, creating a temporary environment and trying to install e.g. GLMakie, which needs to precompile a lot of code, also generated the memory error.

[rryi]

Thanks again for your suggestions.

I found the VScode output tab for julia language server. On my crashing attempts, the tab stays empty - not very surprising, if the crash occurs within precompile. But I will keep it in mind for the case of future language server problems.

julia 1.8.2 did arrive. I tried again on both Ryzen machines with fresh installation of VScode and julia 1.8.2, and still JULIA_NUM_PRECOMPILE_TASKS = 1. Now it was successful, on both Ryzen machines. I suppose some of the changes had a side effect, causing the ryzen problem to disappear. I had a look at the julia 1.8.2 commit-s - there was no commit clearly related to a CPU vendor specific problem.

@mkoculak

same error when compiling other packages directly in the REPL?

Do you mean REPL of a directly started julia.exe, not the REPL inside VScode? I will try that, if I encounter new crashes within VScode.

[mkoculak]

Great to hear that things started to work.

Yeah, there were actually no changes addressing the precompilation threads in Julia, but some developers think what actually caused trouble is the number of spawned openblas threads (you can find their comments and links to commits in the thread below).

Julia 1.8.1 pkg.update() crashes OS / software during precompilation phase

Julia defaults to more BLAS threads if you have more cores, so given AMD has more cores than most it seems sensible AMD users had most problems, but otherwise memory use is strictly unrelated to CPUs at least their frequency etc.

Julia 1.8.2 also seemed to fix the issue for me. I experimented with higher number of precompile tasks and things look stable. You might want to give it also a go, since it speeds up the installation substantially.