Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Julia 1.5.0 Illegal instruction using official binary on AMD Athlon II X2 255 Processor with Debian Buster #36934

Closed
ejolson2005 opened this issue Aug 6, 2020 · 7 comments
Labels
duplicate Indicates similar issues or pull requests

Comments

@ejolson2005
Copy link

System

$ uname -a
Linux liberty 4.19.0-10-amd64 #1 SMP Debian 4.19.132-1 (2020-07-24) x86_64 GNU/Linux
$ cat /proc/cpuinfo | grep "model name"
model name  : AMD Athlon(tm) II X2 255 Processor
model name  : AMD Athlon(tm) II X2 255 Processor
$ julia --version
julia version 1.5.0

Expected behavior

Julia should not crash.

Actual behavior

Program crashed with Illegal instruction.

Steps to reproduce the behavior

$ julia
               _
   _       _ _(_)_     |  Documentation: https://docs.julialang.org
  (_)     | (_) (_)    |
   _ _   _| |_  __ _   |  Type "?" for help, "]?" for Pkg help.
  | | | | | | |/ _` |  |
  | | |_| | | | (_| |  |  Version 1.5.0 (2020-08-01)
 _/ |\__'_|_|_|\__'_|  |  Official https://julialang.org/ release
|__/                   |

julia> a=[1,2,3]
3-element Array{Int64,1}:
 1
 2
 3

julia> b=[4,5,6]
3-element Array{Int64,1}:
 4
 5
 6

julia> a*b'
Invalid instruction at 0x7fa733c9baa7: 0x66, 0x0f, 0x3a, 0x0f, 0xc0, 0x08, 0x0f, 0x29, 0x84, 0x24, 0xb0, 0x03, 0x00, 0x00, 0xe8

signal (4): Illegal instruction
in expression starting at none:0
_ZN4llvm17SLPVectorizerPass18tryToVectorizeListENS_8ArrayRefIPNS_5ValueEEERNS_13slpvectorizer7BoUpSLPEib at /usr/local/julia-1.5.0/bin/../lib/julia/libLLVM-9jl.so (unknown line)
_ZN4llvm17SLPVectorizerPass22vectorizeChainsInBlockEPNS_10BasicBlockERNS_13slpvectorizer7BoUpSLPE at /usr/local/julia-1.5.0/bin/../lib/julia/libLLVM-9jl.so (unknown line)
_ZN4llvm17SLPVectorizerPass7runImplERNS_8FunctionEPNS_15ScalarEvolutionEPNS_19TargetTransformInfoEPNS_17TargetLibraryInfoEPNS_9AAResultsEPNS_8LoopInfoEPNS_13DominatorTreeEPNS_15AssumptionCacheEPNS_12DemandedBitsEPNS_25OptimizationRemarkEmitterE.part.1401 at /usr/local/julia-1.5.0/bin/../lib/julia/libLLVM-9jl.so (unknown line)
_ZN12_GLOBAL__N_113SLPVectorizer13runOnFunctionERN4llvm8FunctionE at /usr/local/julia-1.5.0/bin/../lib/julia/libLLVM-9jl.so (unknown line)
_ZN4llvm13FPPassManager13runOnFunctionERNS_8FunctionE at /usr/local/julia-1.5.0/bin/../lib/julia/libLLVM-9jl.so (unknown line)
_ZN4llvm13FPPassManager11runOnModuleERNS_6ModuleE at /usr/local/julia-1.5.0/bin/../lib/julia/libLLVM-9jl.so (unknown line)
_ZN4llvm6legacy15PassManagerImpl3runERNS_6ModuleE at /usr/local/julia-1.5.0/bin/../lib/julia/libLLVM-9jl.so (unknown line)
operator() at /buildworker/worker/package_linux64/build/src/jitlayers.cpp:520
addModule at /buildworker/worker/package_linux64/build/usr/include/llvm/ExecutionEngine/Orc/IRCompileLayer.h:93 [inlined]
addModule at /buildworker/worker/package_linux64/build/src/jitlayers.cpp:648
jl_add_to_ee at /buildworker/worker/package_linux64/build/src/jitlayers.cpp:893 [inlined]
jl_add_to_ee at /buildworker/worker/package_linux64/build/src/jitlayers.cpp:955
jl_add_to_ee at /buildworker/worker/package_linux64/build/src/jitlayers.cpp:940
jl_add_to_ee at /buildworker/worker/package_linux64/build/src/jitlayers.cpp:940
jl_add_to_ee at /buildworker/worker/package_linux64/build/src/jitlayers.cpp:977 [inlined]
_jl_compile_codeinst at /buildworker/worker/package_linux64/build/src/jitlayers.cpp:126
jl_generate_fptr at /buildworker/worker/package_linux64/build/src/jitlayers.cpp:302
jl_compile_method_internal at /buildworker/worker/package_linux64/build/src/gf.c:1964
jl_compile_method_internal at /buildworker/worker/package_linux64/build/src/gf.c:1919 [inlined]
_jl_invoke at /buildworker/worker/package_linux64/build/src/gf.c:2224 [inlined]
jl_apply_generic at /buildworker/worker/package_linux64/build/src/gf.c:2398
display at /buildworker/worker/package_linux64/build/usr/share/julia/stdlib/v1.5/REPL/src/REPL.jl:214
display at /buildworker/worker/package_linux64/build/usr/share/julia/stdlib/v1.5/REPL/src/REPL.jl:218
_jl_invoke at /buildworker/worker/package_linux64/build/src/gf.c:2214 [inlined]
jl_apply_generic at /buildworker/worker/package_linux64/build/src/gf.c:2398
display at ./multimedia.jl:328
_jl_invoke at /buildworker/worker/package_linux64/build/src/gf.c:2214 [inlined]
jl_apply_generic at /buildworker/worker/package_linux64/build/src/gf.c:2398
jl_apply at /buildworker/worker/package_linux64/build/src/julia.h:1690 [inlined]
do_apply at /buildworker/worker/package_linux64/build/src/builtins.c:655
jl_f__apply_latest at /buildworker/worker/package_linux64/build/src/builtins.c:705
#invokelatest#1 at ./essentials.jl:710 [inlined]
invokelatest at ./essentials.jl:709 [inlined]
print_response at /buildworker/worker/package_linux64/build/usr/share/julia/stdlib/v1.5/REPL/src/REPL.jl:238
print_response at /buildworker/worker/package_linux64/build/usr/share/julia/stdlib/v1.5/REPL/src/REPL.jl:223
do_respond at /buildworker/worker/package_linux64/build/usr/share/julia/stdlib/v1.5/REPL/src/REPL.jl:822
jfptr_do_respond_60634 at /usr/local/julia-1.5.0/lib/julia/sys.so (unknown line)
_jl_invoke at /buildworker/worker/package_linux64/build/src/gf.c:2214 [inlined]
jl_apply_generic at /buildworker/worker/package_linux64/build/src/gf.c:2398
jl_apply at /buildworker/worker/package_linux64/build/src/julia.h:1690 [inlined]
do_apply at /buildworker/worker/package_linux64/build/src/builtins.c:655
jl_f__apply_latest at /buildworker/worker/package_linux64/build/src/builtins.c:705
#invokelatest#1 at ./essentials.jl:710 [inlined]
invokelatest at ./essentials.jl:709 [inlined]
run_interface at /buildworker/worker/package_linux64/build/usr/share/julia/stdlib/v1.5/REPL/src/LineEdit.jl:2355
jfptr_run_interface_59827 at /usr/local/julia-1.5.0/lib/julia/sys.so (unknown line)
_jl_invoke at /buildworker/worker/package_linux64/build/src/gf.c:2214 [inlined]
jl_apply_generic at /buildworker/worker/package_linux64/build/src/gf.c:2398
run_frontend at /buildworker/worker/package_linux64/build/usr/share/julia/stdlib/v1.5/REPL/src/REPL.jl:1143
#38 at ./task.jl:356
jfptr_YY.38_60720 at /usr/local/julia-1.5.0/lib/julia/sys.so (unknown line)
_jl_invoke at /buildworker/worker/package_linux64/build/src/gf.c:2214 [inlined]
jl_apply_generic at /buildworker/worker/package_linux64/build/src/gf.c:2398
jl_apply at /buildworker/worker/package_linux64/build/src/julia.h:1690 [inlined]
start_task at /buildworker/worker/package_linux64/build/src/task.c:707
unknown function (ip: (nil))
Allocations: 2546 (Pool: 2534; Big: 12); GC: 0
Illegal instruction

Commentary

This may be a problem specific to older AMD processors. Here are the flags in cpuinfo

flags       : fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pat pse36 clflush mmx fxsr sse sse2 ht syscall nx mmxext fxsr_opt pdpe1gb rdtscp lm 3dnowext 3dnow constant_tsc rep_good nopl nonstop_tsc cpuid extd_apicid pni monitor cx16 popcnt lahf_lm cmp_legacy svm extapic cr8_legacy abm sse4a misalignsse 3dnowprefetch osvw ibs skinit wdt hw_pstate vmmcall npt lbrv svm_lock nrip_save
bugs        : tlb_mmatch apic_c1e fxsave_leak sysret_ss_attrs null_seg amd_e400 spectre_v1 spectre_v2

I tried to compile from source. Simply typing make led to an Illegal instruction. Typing make cleanall and then make again also led to an Illegal instruction. I have not tracked the source of the problem down.

@ejolson2005
Copy link
Author

ejolson2005 commented Aug 6, 2020

I just checked a different AMD system running Artix Linux and a recent kernel

$ uname -a
Linux blue 5.7.10-artix1-1 #1 SMP PREEMPT Thu, 23 Jul 2020 15:41:52 +0000 x86_64 GNU/Linux
$ cat /proc/cpuinfo | grep "model name"
model name  : AMD A4-3400 APU with Radeon(tm) HD Graphics
model name  : AMD A4-3400 APU with Radeon(tm) HD Graphics

and obtained

Invalid instruction at 0x7f598cb1baa7: 0x66, 0x0f, 0x3a, 0x0f, 0xc0, 0x08, 0x0f, 0x29, 0x84, 0x24, 0xb0, 0x03, 0x00, 0x00, 0xe8

which appears to be exactly the same error.

However, for the system

$ uname -a
Linux okapi 4.15.0-20-generic #21-Ubuntu SMP Tue Apr 24 06:16:15 UTC 2018 x86_64 x86_64 x86_64 GNU/Linux
$ grep "model name" /proc/cpuinfo | head -n1
model name  : Intel(R) Xeon(R) Gold 6126 CPU @ 2.60GHz

I obtain the answer

julia> a*b'
3×3 Array{Int64,2}:
  4   5   6
  8  10  12
 12  15  18

with no errors.

All these runs were made using the official x86 gcc binary

$ md5sum julia-1.5.0-linux-x86_64.tar.gz 
8691258ffbb295c4852ba1a3b2237c04  julia-1.5.0-linux-x86_64.tar.gz

downloaded directly from the main Julia website.

Is there some hand-coded assembler that needs to be disabled to obtain a generic x86 binary?

@jmkuhn
Copy link
Contributor

jmkuhn commented Aug 6, 2020

See #35215 and #36716. Try compiling from source setting USE_BINARY_BUILDER=0.

@yuyichao yuyichao closed this as completed Aug 6, 2020
@ejolson2005
Copy link
Author

Why did this get closed with no text in the post describing why? Is the official binary supposed to work on x86 or not? Would it be better to wait to see if the proposed solution works? Will the official binaries be updated?

@jmkuhn
Copy link
Contributor

jmkuhn commented Aug 6, 2020

This issue was closed because it is a duplicate of open issue #35215. As discussed in that issue, the official binary is not expected to work on all x86 processors. There are minimum requirements that should be documented better #35215 (comment).

@yuyichao
Copy link
Contributor

yuyichao commented Aug 6, 2020

This is closed due to dup but no, there’s no reason for the official binary to not work for you. This is not a document issue. I’ve already listed all the solution I can think of and some of them is a simple revert or option change when building the official binary and it is only blocked on people in charge to change a single line of code.

@ejolson2005
Copy link
Author

ejolson2005 commented Aug 6, 2020

Thanks for your reply. That makes sense. My observation is closing an issue without explanation creates bad feelings and distrust.

While I'm not generally in favour of developer codes of conduct for highly visible open source projects, to avoid problems in the future I would suggest enforcing a simple policy of not closing issues without offering any explanation as to why. Now that Julia is past the 1.0 release and ready for adoption in university applied mathematics courses worldwide, I would also suggest for everyone to pay more attention to unit and regression testing.

Woohoo! As an update, the binary compiled with

USE_BINARY_BUILDER:=0

seems to work. I suspect there is also a way to compile an official binary that works using your build release farm. Maybe details how to do this could be found in the Debian package build scripts for Julia and for LLVM.

Unfortunately, this is not the end of the story for me. I am planning to use Julia this coming semester in a numerical methods course that will be taught online as a result of the ongoing epidemic. Instead of MATLAB in the university computing labs, students will install Julia on their home computers. Julia is definitely up to the task, however, the official binary needs to run on the computer each student has available at home. Some of these were obtained from the university surplus auction, others are hand-me-downs from parents and others are, of course, new Macbooks.

I'll continue this discussion at #35215 which hasn't been closed. Thanks for listening and thanks for the explanation.

@yuyichao
Copy link
Contributor

yuyichao commented Aug 6, 2020

The dup and explanation was already mentioned in #36934 (comment), which is why I close without additional comments.

@nsajko nsajko added the duplicate Indicates similar issues or pull requests label Jan 18, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
duplicate Indicates similar issues or pull requests
Projects
None yet
Development

No branches or pull requests

4 participants