Problems in 1.6.4 with IJulia. Downgrade to 1.6.3?

I am having a problem with IJulia throwing StackOverflowError: in 1.6.4. I am pretty sure that I was having no problem in 1.6.3 and have tested the notebook in 1.6.1 with no problems.

Is there any way I can get 1.6.3 to see if there is or is not a problem with 1.6.3 and stick with that version if it works ok. The downloads page only offers 1.6.4 and I did not save 1.6.3. My copy of 1.6.1 was on a machine that I rarely use, and I’m lucky to have it.

This code that throws the exception is complicated and I do not have an MWE yet. All I know is that it uses FFTW and allocates only a modest (< 100MB) amount of storage.

Just try to modify the 1.6.4 download link, e.g.
works for me.

1 Like

Thanks. The code works fine in the REPL under 1.6.4, but not in IJulia.

I had the same experience. My code worked with julia 1.6.4 in REPL but not in Juno / vscode. I had stackoverflow as well. I went back to 1.6.2

On a side note, this was on osx if it is of any help.

Yup. It was osx for me too. I’m not sure if it’s a 1.6.4 problem or a Monterey problem, but it is a problem. Given that it’s the two of us, perhaps 1.6.4 hates nonlinear solver work.

@rveltz ,were you able to come up with a MWE? Someone should file an issue if that someone could clearly identify the problem. That someone is not me, at least not yet.

I think it would be really helpful, if one of you could make minimum crashing example. Maybe it could become a test in some package to make sure we will get rid of this bug.

I am working on it, but it if happens in all of Juno/VScode/IJulia, it’ll be hard to find. If I make any progress I will post on this thread and file an issue, at least if I can figure out which package has the issue.

If the problem vanishes in 1.7, then it really does not matter.

I don’t think this is true, after all 1.6 will still be the version with the Long Term Support label, so it may be worth it to attack and report bugs.

In general all released are available on GitHub here:

Fair enough.

If you have any code which works, but not in Juno: I’m in.

Here you go. This

n=512; L=rand(n,n); z=rand(n); b=L\z;

runs in the REPL and in IJUlia with 1.6.3. I get the StackOverflowError: in IJulia under 1.6.4. Running Monterey.

@rveltz, can you try this in Juno/vscode and see what happens?

1 Like

Wow, this is Juno/Atom on Windows 10:

Sorry, should have been more specific: Juno/Atom. But I see your point (if IJulia is based on Juno?)!

On what foundations is IJulia built, VS Code or Atom/Juno?

On Windows 11 (sorta), running VSCode:

julia> n=512; L=rand(n,n); z=rand(n); b=L\z;
ERROR: StackOverflowError:

That’s it. No additional output after “StackOverflowError:”
Probing further, L is defined. “z” is defined. “b” is not defined.

my version info:

julia> versioninfo()
Julia Version 1.6.4
Commit 35f0c911f4 (2021-11-19 03:54 UTC)
Platform Info:
  OS: Windows (x86_64-w64-mingw32)
  CPU: Intel(R) Core(TM) i7-4960X CPU @ 3.60GHz
  LIBM: libopenlibm
  LLVM: libLLVM-11.0.1 (ORCJIT, ivybridge)
  JULIA.EXECUTABLEPATH = C:\Users\amgough\Julia\bin\julia.exe
  JULIA_GLPK_LIBRARY_PATH = C:\Program Files\glpk
  JULIA_HOME = C:\Users\amgough\Julia\bin\julia.exe

I will file an issue and reference this thread. Strange that

n=32; L=rand(n,n); z=rand(n); b=L\z;

works fine, at least for me and IJullia in 1.6.4.

Just filed

1.7 has the same problem. Switching to the MKL BLAS solved it on my intel Macs and also with the x86 version of 1.7.0 on my M1 Mac. The success on M1 surprised me.

MKL has to be using rosetta2 and the performance was good. I did a few tests an it looks 10-20% faster than openblas in the REPL for moderately sized problems (1000x1000 Gaussian elimination …)

I’m now using x86 1.7.0 on all my machines while I wait for the openblas fix for the native M1 version.

So using MKL is now in my startup.jl and startup_ijulia.jl files. Problem solved!