julia: wrong compiler?

[nico202]

Issue description

The issue is described here: https://discourse.julialang.org/t/julia-script-segfault-on-errors/8484
Short: an error in a running a script causes a segfault instead of reporting the error. The hypothesis is a compiler mismatch

Steps to reproduce

just run a script containing any kind of error in julia 0.6

@raskin

[dtzWill]

Hmm, having troubles reproducing, in the future please provide a bit more information (see the issue template for easy way to generate this with nix-info).

How did you get julia 0.6.0?

• On latest 17.09 channel:
  • default for julia is 0.4.7 (julia)
  • Julia 0.5 is available as julia_05
  • julia-git is marked as broken-- no 0.6 here.
• On latest unstable:
  • default for julia is 0.6.2 (not 0.6.0)
  • it appears julia-git is 0.6.0?

Building julia-git presently, we'll see if I see the same problem (I expect so).

In the meantime, how about switching to a stable julia release, presumably with improvements and fixes? Using julia 0.6.2 (available from the binary cache, hooray!) I don't see the error you're experiencing.

Depending on how you installed julia, and your system setup, something like one of the following should do the trick:

$ nix-env -u -A nixpkgs.julia

or

$ nix-env -u -A nixos.julia

or, I guess:

$ nix-env -u julia

Hope this helps, good luck!

[dtzWill]

Nope, julia-git fails to build -- looks like last successful build was 2017-04-08 (!), probably should go back to being marked broken.

(you probably have it julia 0.6.0 from the period where that was the supported nixpkgs version, not from julia-git, I'd guess)

[7c6f434c]

Well, 0.6.2 has the same problem…

[dtzWill]

Err, it does! (?!)

I really thought I confirmed it didn't, not sure what that's about. Sorry O:).

[7c6f434c]

Maybe I use a version from a slightly obsolete master and it got fixed?

In other news, compiler version conflict seems unlikely…

[7c6f434c]

Hm, current master. Basically, once you have REPL, everything is fine, if you get an error before/without REPL, there are problems. -L and -e have the same problem.

Edit: loading a file inside REPL works fine, yes.

[nico202]

Hi, sorry for the bad report. I was on julia 0.6.0 indeed, on nixos-unstable. Upgraded the system today:
nix-info

system: "x86_64-linux", multi-user?: yes, version: nix-env (Nix) 1.11.16, channels(IITaudio): "nixos-17.09.2138.48bf1f43cd, unstable-18.03pre120540.b8f7027360, telegram-cli-2016-03-23, machine-0.9.0, gitlab-runner-1.10.4, california-0.4.0, entr-3.6, tmuxp-1.2.2, keybase-20170209.17b641d, kbfs-20170209.d1db463, non-2016-12-07, go-sct-20160529-1d6b5e0, freecad-0.16, antimony-0.9.2, librecad-2.1.3, lemonbar-xft-unstable-2016-02-17, pencil-2.0.21, python3.5-qnotero-1.0.0, ruby-2.3.3, gimp-2.8.20, chromium-56.0.2924.87, nix-repl-1.11.7-2016-02-28, gparted-0.26.1, screen-4.5.1, vmpk-0.5.1, a2jmidid-8, platformio, teensyduino-1.6.12, teensy-loader-cli-2.1, blender-2.78c, unetbootin-613, mediainfo-0.7.91, xournal-0.4.8, zip-3.0, graphviz-2.40.1, ffmpeg-3.2.4, vlc-2.2.4, okular-16.12.2, pdfmod-0.9.1, green-pdfviewer-nightly-2014-04-22, android-sdk-25.2.3, android-studio-2.2.3.0, zathura-with-plugins-0.3.7, openjdk-8u121b13, android-ndk-r10e, virtualbox-5.1.14, R-3.3.2-wrapper, aspell-dict-en-2016.06.26-0", channels(gitlab-runner): "nixpkgs-18.03pre117013.aebdc892d6", channels(root): "nixos-18.03pre126063.95880aaf062, nixpkgs-18.03pre117013.aebdc892d6", nixpkgs: /nix/var/nix/profiles/per-user/root/channels/nixos/nixpkgs

julia -v

julia version 0.6.2

And the segfault on scripts still exists.

OT: why do we still have julia 0.4.7 in the repo? Also 0.5.0. They are outdated, and nothing depends on them in the store. As you said, julia-git is older than julia... it seems that we need a cleanup, also given that the new Pkg3 is coming and we might want to add julia pkgs too in the future

[currymj]

I have also noticed this problem. Additional info: it persists even in FHS-compatible environments, if that matters.

Also, this is interesting:

julia> error("test")
ERROR: test
Stacktrace:
 [1] error(::String) at ./error.jl:21

errors work fine if typed in at the REPL. If I then define a file named test.jl containing the single line error("test"), I get a segfault running julia test.jl (output at bottom, let me know if I should move it to a gist).

However, including the file from the REPL does not cause problems.

julia> include("test.jl")
ERROR: LoadError: test
Stacktrace:
 [1] error(::String) at ./error.jl:21
 [2] include_from_node1(::String) at ./loading.jl:576
 [3] include(::String) at ./sysimg.jl:14
while loading /home/curry/test.jl, in expression starting on line 1

Finally, I tried defining a function that just immediately calls error. If the function was called from the REPL, things were fine; if it was called in code invoked from the shell, it segfaulted.

Segfault output:

[nix-shell:~]$ julia test.jl

signal (11): Segmentation fault
while loading no file, in expression starting on line 0
get at /nix/store/8h8zfp48ha0yw7ala3pz29d7ml7bdwjc-gfortran-6.4.0/include/c++/6.4.0/bits/unique_ptr.h:308 [inlined]
getBinary at /nix/store/lkikwvfb5ikhg95bnmkqvflkw5ayzcwr-llvm-3.9.1/include/llvm/Object/Binary.h:181 [inlined]
jl_dylib_DI_for_fptr at /build/source/src/debuginfo.cpp:1242
jl_getDylibFunctionInfo at /build/source/src/debuginfo.cpp:1397 [inlined]
jl_getFunctionInfo at /build/source/src/debuginfo.cpp:1633
jl_lookup_code_address at /build/source/src/stackwalk.c:348
lookup at ./stacktraces.jl:125
collect_to! at ./array.jl:508
_collect at ./array.jl:489
stacktrace at ./stacktraces.jl:151
display_error at ./client.jl:126
unknown function (ip: 0x7f934b35a6dd)
jl_call_fptr_internal at /build/source/src/julia_internal.h:339 [inlined]
jl_call_method_internal at /build/source/src/julia_internal.h:358 [inlined]
jl_apply_generic at /build/source/src/gf.c:1926
display_error at ./client.jl:140
unknown function (ip: 0x7f934b35a146)
jl_call_fptr_internal at /build/source/src/julia_internal.h:339 [inlined]
jl_call_method_internal at /build/source/src/julia_internal.h:358 [inlined]
jl_apply_generic at /build/source/src/gf.c:1926
do_call at /build/source/src/interpreter.c:75
eval at /build/source/src/interpreter.c:242
eval_body at /build/source/src/interpreter.c:539
jl_toplevel_eval_body at /build/source/src/interpreter.c:511
jl_toplevel_eval_flex at /build/source/src/toplevel.c:571
jl_toplevel_eval_in at /build/source/src/builtins.c:496
eval at ./boot.jl:235
unknown function (ip: 0x7f93689db67f)
jl_call_fptr_internal at /build/source/src/julia_internal.h:339 [inlined]
jl_call_method_internal at /build/source/src/julia_internal.h:358 [inlined]
jl_apply_generic at /build/source/src/gf.c:1926
_start at ./client.jl:417
unknown function (ip: 0x7f9368a2d4d8)
jl_call_fptr_internal at /build/source/src/julia_internal.h:339 [inlined]
jl_call_method_internal at /build/source/src/julia_internal.h:358 [inlined]
jl_apply_generic at /build/source/src/gf.c:1926
Segmentation fault

nix-info:

system: "x86_64-linux", multi-user?: yes, version: nix-env (Nix) 1.11.16, channels(root): "nixos-18.03pre126729.2e4aded3669", nixpkgs: /nix/var/nix/profiles/per-user/root/channels/nixos/nixpkgs

[nico202]

Yes the difference between the REPL and scripts is the behaviour I noticed. In the fhs you are running upstream julia?

[currymj]

Previously, no, I was just using julia from nixpkgs.

However, if I build an FHS-compatible env with only zlib, and download the generic Julia binary from their site, the problem actually does disappear.

julia-minimal-chrootenv:curry@nixos:~$ Downloads/julia-d386e40c17/bin/julia test.jl
ERROR: LoadError: test
Stacktrace:
 [1] error(::String) at ./error.jl:21
 [2] include_from_node1(::String) at ./loading.jl:576
 [3] include(::String) at ./sysimg.jl:14
 [4] process_options(::Base.JLOptions) at ./client.jl:305
 [5] _start() at ./client.jl:371
while loading /home/curry/test.jl, in expression starting on line 1

to make the nix shell:

{ pkgs ? import <nixpkgs> {} }:

(pkgs.buildFHSUserEnv {
name = "julia-minimal";
targetPkgs = pkgs: (
with pkgs; [ zlib ]
);
}).env

[currymj]

Also, I would add that I have observed these segfaults from the REPL, but only while trying to install packages where the builds failed.

[nico202]

Yeah if I remember well package install spawns a new julia process

[7c6f434c]

So upstream binary carries its own copy of LLVM and other things? I wonder if replacing them with symlinks to Nixpkgs-built ones in a FHS is a viable problem-localisation idea.

[currymj]

There's lots of .so files for LLVM (v 3.9), gcc/gfortran etc, under lib/julia. I'm a new enough nix user that I'm not sure how to find the actual compiled libraries, but that sounds viable. It should be enough to just download from the website.

[nico202]

Fixed by f8fe297