Jason Hobbs (Dec 01 2021 at 23:03): Jason Hobbs (Dec 01 2021 at 23:03):Looks like Num.toStr 5 crashes with Illegal instruction (core dumped) for me. This happens on the roc repl. It might be related to the custom build @Anton hooked me up with to support my CPU: (https://roc.zulipchat.com/#narrow/stream/231634-beginners/topic/Getting.20started.20with.20nightlies)
Lucas Rosa (Dec 02 2021 at 07:08):(deleted)
Anton (Dec 02 2021 at 10:03):Num.toStr is a very recent addition, using this roc binary as a drop in replacement in the decompressed nightly of roc_nightly-linux_x86_64-20211202-4e91ce.tar.gz should work.
I'll set things up so you won't have to rely on me providing custom binaries for the following nightly releases.
Anton (Dec 02 2021 at 10:19):I've set up PR #2125 to make all future nightly releases compatible with your CPU @Jason Hobbs .
Jason Hobbs (Dec 02 2021 at 14:20):Thanks @Anton! Once that gets merged in, I'll download the latest and resume the Advent. As an aside, the roc attachment you provided has the same error. Does it matter where the roc binary lives?
Anton (Dec 02 2021 at 14:43):Yes, the roc binary needs to be in the exact folder layout that is created when the tar.gz is decompressed.
Anton (Dec 02 2021 at 15:06):I just checked my laptop and I have the exact same CPU :) although it's fine if you want to wait until tomorrow, the following steps really should work:
roc_nightly-linux_x86_64-20211202-4e91ce.tar.gztar -xf roc_nightly-linux_x86_64-20211202-4e91ce.tar.gz
rm roc
wget https://www.dropbox.com/s/nwmqpbxnaq1eovk/roc?dl=1
mv roc\?dl\=1 roc
chmod +x roc
./roc repl
Num.toStr 5
` ``
Odd that I'm having that problem and you're not...
~/projects/exploration/advent-of-code-2021/roc 1 (31.2ms)
$ md5sum roc
12899684ced940478eda53abc4e2ffb0 roc
~/projects/exploration/advent-of-code-2021/roc 0 (106ms)
$ ls
compiler LICENSE roc_nightly-linux_x86_64-20211202-4e91ce.tar.gz
examples roc roc_std
LEGAL_DETAILS roc.20211202
~/projects/exploration/advent-of-code-2021/roc 0 (2.9ms)
$ ./roc repl
The rockin’ roc repl
────────────────────────
Enter an expression, or :help, or :exit/:q.
» Num.toStr 5
Illegal instruction (core dumped)
oh wait...
Jason Hobbs (Dec 02 2021 at 17:47):Thought the PATH might have still had another roc in it, but nope... I actually called it directly above: ./roc. Same issue... strange.
Brendan Hansknecht (Dec 02 2021 at 17:51):Oh, this is a zig builtin issue...not a roc binary issue
Brendan Hansknecht (Dec 02 2021 at 17:52):So doesn't matter how we compile roc if the zig builtin is still calling illegal instructions. At least, that is my guess.
Jason Hobbs (Dec 02 2021 at 17:53):The zig hello world works (actually all 3 rust, zig, c).
Jason Hobbs (Dec 02 2021 at 17:53):Oh, does the repl rely on zig? And it's got the Num.toStr issue?
Jason Hobbs (Dec 02 2021 at 17:54):I'll test Num.toStr with the rust platform
Brendan Hansknecht (Dec 02 2021 at 17:54):A lot of the roc builtins, like Num.toStr depend on zig.
Brendan Hansknecht (Dec 02 2021 at 17:54):So my guess is that Num.toStr is compiled in a way such that it is calling an invalid instruction.
Jason Hobbs (Dec 02 2021 at 17:55):oh, okay! That might explain why the rust platform still has the issue too
Brendan Hansknecht (Dec 02 2021 at 18:00):I am not sure how the builtins are compiled for the nightly build, but I would have guess that it is done locally, so this shouldn't happen....so I may still be a different issue
Jason Hobbs (Dec 02 2021 at 18:02):I probably skipped a step then, because I didn't compile anything
Brendan Hansknecht (Dec 02 2021 at 18:04):It would happen automatically when running roc commands.
Brendan Hansknecht (Dec 02 2021 at 19:14):Quick question to verify my theory. If have an example that calls Num.toStr and then run roc build <example> does it fail, or does it only fail when running?
Jason Hobbs (Dec 02 2021 at 21:34):This crashes if that's what you meant:
app "hello-rust"
packages { base: "platform" }
imports []
provides [ main ] to base
greeting =
hi = "Hello"
name = Num.toStr 5
"\(hi), \(name)!\n"
main = greeting
~/projects/exploration/advent-of-code-2021/roc 0 (568ms)
$ ./roc examples/hello-rust/Hello.roc
🔨 Rebuilding host... Done!
Illegal instruction (core dumped)
That is the command to build and run. What do you get when you explicitly just build ./roc build examples/hello-rust/Hello.roc?
Jason Hobbs (Dec 02 2021 at 23:47):Works like a charm... guess the error is in the runtime.
~/projects/exploration/advent-of-code-2021/roc 132 (1.7ms)
$ ./roc build examples/hello-rust/Hello.roc
🔨 Rebuilding host... Done!
🎉 Built examples/hello-rust/hello-rust in 559 ms
~/projects/exploration/advent-of-code-2021/roc 0 (569ms)
$ ./examples/hello-rust/hello-rust
Illegal instruction (core dumped)
Yeah, so either a zig built-in issue or i guess it could be an llvm issue, but that would be quite surprising. I believe we target the host cpu when compiling.
Brendan Hansknecht (Dec 03 2021 at 04:17):Just skimmed the code. The zig builtins are compiled to target the host cpu. So that is where the issue is coming from. We probably need to build a generic x86-64 version.
Anton (Dec 03 2021 at 12:34):I'll look into this, I think it is pretty similar to what I did to make valgrind work on my laptop.
Anton (Dec 03 2021 at 19:08):I've setup PR #2132 for this. I still don't understand why it did not fail on my laptop though.
Brendan Hansknecht (Dec 03 2021 at 19:13):Did you try to run Num.toStr on your laptop. I think that built-in specifically has the issue
Anton (Dec 04 2021 at 09:03):Yes I did, it works without problems.
Anton (Dec 04 2021 at 09:28):Can you try Num.toStr 5 in the roc repl with today's nightly (20211204-e872d0) @Jason Hobbs?
Jason Hobbs (Dec 04 2021 at 16:16):Same problem:
~/projects/exploration/roc/1203-04 0 (1.4ms)
$ mv ~/Downloads/roc_nightly-linux_x86_64-20211204-e872d0.tar.gz .
~/projects/exploration/roc/1203-04 0 (3.7ms)
$ tar xf roc_nightly-linux_x86_64-20211204-e872d0.tar.gz
~/projects/exploration/roc/1203-04 0 (2.539s)
$ ls
compiler LICENSE roc_std
examples roc
LEGAL_DETAILS roc_nightly-linux_x86_64-20211204-e872d0.tar.gz
~/projects/exploration/roc/1203-04 0 (2.3ms)
$ ./roc examples/hello-rust/Hello.roc
🔨 Rebuilding host... Done!
Hello, World!
~/projects/exploration/roc/1203-04 132 (743ms)
$ ./roc repl
The rockin’ roc repl
────────────────────────
Enter an expression, or :help, or :exit/:q.
» Num.toStr 5
Illegal instruction (core dumped)
For what it's worth, it does understand the fn signature:
» Num.toStr
<function> : Num * -> Str
» Num.toStr 5
Illegal instruction (core dumped)
can you upload the output of cat /proc/cpuinfo | grep flags (Note, it will repeat the same info multiple times, you can just upload the first instance)
Also, can you upload your generated examples/hello-rust/hello-rust executable?
Brendan Hansknecht (Dec 04 2021 at 17:17):@Jason Hobbs One other thing that would also be quite useful. Probably more useful than the above:
1) run lldb examples/hello-rust/hello-rust
2) type r and press enter
3) paste the output here
4) type q and press enter to quit lldb
If you don't have lldb, I can look into the equivalent instructions for gdb which you would likely have.
Jason Hobbs (Dec 04 2021 at 18:37):I modified the hello-rust to include the Num.toStr 5 and got this:
~/projects/exploration/roc/1203-04 132 (4.424s)
$ lldb examples/hello-rust/hello-rust
(lldb) target create "examples/hello-rust/hello-rust"
Current executable set to '/home/jason/projects/exploration/roc/1203-04/examples/hello-rust/hello-rust' (x86_64).
(lldb) r
Process 22940 launched: '/home/jason/projects/exploration/roc/1203-04/examples/hello-rust/hello-rust' (x86_64)
Process 22940 stopped
* thread #1, name = 'hello-rust', stop reason = signal SIGILL: illegal instruction operand
frame #0: 0x000055555558d807 hello-rust`roc_builtins.str.from_int.i64 + 71
hello-rust`roc_builtins.str.from_int.i64:
-> 0x55555558d807 <+71>: vmovdqa 0x8891(%rip), %xmm0
0x55555558d80f <+79>: vmovdqu %xmm0, 0xe0(%rsp)
0x55555558d818 <+88>: movq %rax, 0xd0(%rsp)
0x55555558d820 <+96>: leaq 0xf0(%rsp), %rdi
(lldb) q
$ cat /proc/cpuinfo | grep flags
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 rdtscp lm constant_tsc rep_good nopl xtopology nonstop_tsc cpuid tsc_known_freq pni ssse3 pcid sse4_1 sse4_2 hypervisor lahf_lm invpcid_single ibrs_enhanced fsgsbase invpcid md_clear flush_l1d arch_capabilities
hello-rust This is the version with name = Num.toStr 5
Anton (Dec 04 2021 at 18:40):Thanks @Jason Hobbs! I'll see what the disassembly of the executable looks like on my laptop.
Jason Hobbs (Dec 04 2021 at 18:40):built with the 1204 nightly roc
Anton (Dec 04 2021 at 18:41):Can you post the source of your modified hello-rust as well?
Jason Hobbs (Dec 04 2021 at 18:41):app "hello-rust"
packages { base: "platform" }
imports []
provides [ main ] to base
greeting =
hi = "Hello"
name = Num.toStr 5
"\(hi), \(name)!\n"
main = greeting
Interesting observation: I have way more flags on my (exact same) CPU, I wonder if this is some restriction coming from the virtual machine.
Brendan Hansknecht (Dec 04 2021 at 18:48):So that matches the assembly I get. It looks like he doesn't even have avx
Anton (Dec 04 2021 at 18:48):uhu, I do have avx. I'll post my flags in a minute
Brendan Hansknecht (Dec 04 2021 at 18:49):No avx probably means you can't even use x86-64-v2
Brendan Hansknecht (Dec 04 2021 at 18:50):Maybe related to: https://communities.vmware.com/t5/VMware-Workstation-Pro/AVX-instructions-do-not-work-in-a-virtual-machine-on-a-Windows/td-p/2745412
Brendan Hansknecht (Dec 04 2021 at 18:50):Not sure if @Jason Hobbs is using vmware or some other form of virtualization?
Anton (Dec 04 2021 at 18:52):My flags:
flags : fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pat pse36 clflush dts acpi mmx fxsr sse sse2 ss ht tm pbe syscall nx pdpe1gb rdtscp lm constant_tsc art arch_perfmon pebs bts rep_good nopl xtopology nonstop_tsc cpuid aperfmperf tsc_known_freq pni pclmulqdq dtes64 monitor ds_cpl vmx est tm2 ssse3 sdbg fma cx16 xtpr pdcm pcid sse4_1 sse4_2 x2apic movbe popcnt tsc_deadline_timer aes xsave avx f16c rdrand lahf_lm abm 3dnowprefetch cpuid_fault epb cat_l2 invpcid_single cdp_l2 ssbd ibrs ibpb stibp ibrs_enhanced tpr_shadow vnmi flexpriority ept vpid ept_ad fsgsbase tsc_adjust bmi1 avx2 smep bmi2 erms invpcid rdt_a avx512f avx512dq rdseed adx smap avx512ifma clflushopt clwb intel_pt avx512cd sha_ni avx512bw avx512vl xsaveopt xsavec xgetbv1 xsaves split_lock_detect dtherm ida arat pln pts hwp hwp_notify hwp_act_window hwp_epp hwp_pkg_req avx512vbmi umip pku ospke avx512_vbmi2 gfni vaes vpclmulqdq avx512_vnni avx512_bitalg avx512_vpopcntdq rdpid movdiri movdir64b fsrm avx512_vp2intersect md_clear flush_l1d arch_capabilities
I found it in a past message, Jason is using VirtualBox
Anton (Dec 04 2021 at 18:58):@Jason Hobbs Disabling Hyper-V inside windows (if it is enabled) could solve the issue. You'll probably need to restart virtualbox after.
Jason Hobbs (Dec 04 2021 at 19:14):Yes, I have it running in Virtualbox. On the Hyper-V link there, I do see a hypervisor has been detected (using msinfo32.exe). However, I'm running on Windows Home, so Hyper-V isn't an option for me.
Anton (Dec 05 2021 at 10:34):I've looked into this some more and workarounds for windows hyper-v require disabling a bunch of security features, which I would not recommend :sweat_smile: So I will adjust the nightly target for maximal compatibility.
Jason Hobbs (Dec 05 2021 at 13:29):Thank you!
Anton (Dec 06 2021 at 10:34):Can you give the 20211206 nightly a try @Jason Hobbs?
Jason Hobbs (Dec 06 2021 at 14:38)::sad: Still a no go
~/projects/exploration/roc/1206 0 (3.2ms)
$ tar xf roc_nightly-linux_x86_64-20211206-034b8f.tar.gz
~/projects/exploration/roc/1206 0 (2.571s)
$ ls
compiler LICENSE roc_std
examples roc
LEGAL_DETAILS roc_nightly-linux_x86_64-20211206-034b8f.tar.gz
~/projects/exploration/roc/1206 0 (2.6ms)
$ ./roc repl
The rockin’ roc repl
────────────────────────
Enter an expression, or :help, or :exit/:q.
» Num.toStr 5
Illegal instruction (core dumped)
I can put together a minimal VirtualBox image for you that might replicate the problem if you'd like. Would that help?
Anton (Dec 06 2021 at 14:42):Strange... yes the virtualbox image sounds like a good idea :+1:
Jason Hobbs (Dec 06 2021 at 15:14):I found it's pretty interesting that Num.floor 2.5 works but Num.round 2.5 crashes with Illegal instruction (core dumped)
Anton (Dec 06 2021 at 15:21):It seems reasonable that round could use an instruction that is not needed for floor.
Jason Hobbs (Dec 06 2021 at 15:58):Very true... I have the image ready btw.. just figuring out where I can put it (3GB).
Jason Hobbs (Dec 06 2021 at 20:39):http://45.79.131.94/static/xubuntu-roc-repl.ova is the image to import into Virtualbox. The roc is in Downloads. sudo for root access. user and pass are both jason. I made sure the 3 hello-world examples all run and the roc repl still crashes as above.
Anton (Dec 07 2021 at 08:35):Thanks for setting this up! I should be able to take a look either today or tomorrow.
Anton (Dec 08 2021 at 10:00):Using the virtualbox image I was unable to reproduce the error on my Ubuntu laptop, I also had more cpu flags so it makes sense.
I'll try to reproduce the error on my windows desktop.
Anton (Dec 08 2021 at 11:32):I'm also unable to reproduce this on windows (inside VirtualBox).
@Jason Hobbs can you share the values in the "system information" window on windows?
Can you also confirm virtualization is enabled in your BIOS?
Jason Hobbs (Dec 08 2021 at 14:43):
Jason Hobbs (Dec 08 2021 at 14:44):Gotta reboot to check the BIOS. And btw, you're amazing for putting in so much time on this!
Jason Hobbs (Dec 08 2021 at 14:52):Both Intel (VMX) Virtualization Technology and VT-d are enabled in the BIOS
Jason Hobbs (Dec 08 2021 at 15:24):Not sure if this is helpful, but I tracked down creating the crash file caused by core dumped...
~/projects/exploration/roc/1206/crash/unpack 0 (14.5ms)
$ gdb `cat ExecutablePath` CoreDump
GNU gdb (Ubuntu 9.2-0ubuntu1~20.04) 9.2
Copyright (C) 2020 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/gpl.html>
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law.
Type "show copying" and "show warranty" for details.
This GDB was configured as "x86_64-linux-gnu".
Type "show configuration" for configuration details.
For bug reporting instructions, please see:
<http://www.gnu.org/software/gdb/bugs/>.
Find the GDB manual and other documentation resources online at:
<http://www.gnu.org/software/gdb/documentation/>.
For help, type "help".
Type "apropos word" to search for commands related to "word"...
Reading symbols from /home/jason/projects/exploration/roc/1206/roc...
[New LWP 41324]
warning: Could not load shared library symbols for /tmp/.tmpSsVt9n/app.so.1.0.
Do you need "set solib-search-path" or "set sysroot"?
[Thread debugging using libthread_db enabled]
Using host libthread_db library "/lib/x86_64-linux-gnu/libthread_db.so.1".
Core was generated by `./roc repl'.
Program terminated with signal SIGILL, Illegal instruction.
#0 0x00007f5f6d48a0e7 in ?? ()
(gdb) bt
#0 0x00007f5f6d48a0e7 in ?? ()
#1 0x00000316924198d0 in ?? ()
#2 0x00007ffe30476b90 in ?? ()
#3 0x0000562541a0c2e8 in ?? ()
#4 0x0000000000000000 in ?? ()
I used the commands on this answer for the snippet above: https://askubuntu.com/a/947532
_home_jason_projects_exploration_roc_1206_roc.1000.crash
Anton (Dec 08 2021 at 15:55):And btw, you're amazing for putting in so much time on this!
Happy to help :)
For system information I am looking for something like this
Jason Hobbs (Dec 08 2021 at 17:07):
Anton (Dec 08 2021 at 17:08):Yes, that's the one. I'll compare with my settings.
Anton (Dec 08 2021 at 18:55):I have "Secure Boot State" set to off (for linux drivers), I think this also disables Kernel DMA protection and virtualization-based security.
virtualization-based security might cause the limited flags inside VirtualBox.
Jason Hobbs (Dec 08 2021 at 19:21):That's interesting... I'll play with that setting on the host machine later tonight.
Jason Hobbs (Dec 09 2021 at 14:26):I didn't see anything like Secure Boot in the BIOS to disable, so I'll just look into setting up a Linux install that has direct hardware access. It'll be a few days though, as I'm travelling for a conference. I'll shoot an update as soon as I have one
Last updated: Jul 06 2025 at 12:14 UTC
