Release 2.8 pre-compiled binary fails to run: "Illegal instruction (core dumped)"

[pentamorfico]

Description

The precompiled Linux binary for reseek v2.8 crashes immediately on execution with:

Illegal instruction (core dumped)

This happens before any usage or version information is printed.

---

Steps to reproduce

wget https://github.com/rcedgar/reseek/releases/download/v2.8/reseek-v2.8-linux-x86
chmod +x reseek-v2.8-linux-x86
./reseek-v2.8-linux-x86

---

Observed behavior

Illegal instruction (core dumped)

Immediate crash, no output.

---

Expected behavior

The binary should start normally (e.g. show usage/help or accept command-line arguments). Building from source works without any issues

---

Environment

OS

• Linux (x86_64)

CPU
Architecture: x86_64
Vendor ID: AuthenticAMD
Model name: AMD Ryzen Threadripper PRO 5995WX 64-Cores
CPU(s): 128
Thread(s) per core: 2
Core(s) per socket: 64
Socket(s): 1

CPU flags (excerpt)
sse sse2 ssse3 sse4_1 sse4_2 sse4a avx avx2 fma bmi1 bmi2 aes sha vaes vpclmulqdq

(Full lscpu output below.)

---

Full lscpu output

Architecture: x86_64
CPU op-mode(s): 32-bit, 64-bit
Address sizes: 48 bits physical, 48 bits virtual
Byte Order: Little Endian
CPU(s): 128
On-line CPU(s) list: 0-127
Vendor ID: AuthenticAMD
Model name: AMD Ryzen Threadripper PRO 5995WX 64-Cores
CPU family: 25
Model: 8
Thread(s) per core: 2
Core(s) per socket: 64
Socket(s): 1
Stepping: 2
Frequency boost: enabled
CPU max MHz: 7024.2178
CPU min MHz: 1800.0000
BogoMIPS: 5390.17
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 constant_tsc rep_good nopl nonstop_tsc cpuid extd_apicid aperfmperf rapl pni pclmulqdq monitor ssse3 fma cx16 pcid sse4_1 sse4_2 x2apic movbe popcnt aes xsave avx f16c rdrand lahf_lm cmp_legacy svm extapic cr8_legacy abm sse4a misalignsse 3dnowprefetch osvw ibs skinit wdt tce topoext perfctr_core perfctr_nb bpext perfctr_llc mwaitx cpb cat_l3 cdp_l3 hw_pstate ssbd mba ibrs ibpb stibp vmmcall fsgsbase bmi1 avx2 smep bmi2 erms invpcid cqm rdt_a rdseed adx smap clflushopt clwb sha_ni xsaveopt xsavec xgetbv1 xsaves cqm_llc cqm_occup_llc cqm_mbm_total cqm_mbm_local user_shstk clzero irperf xsaveerptr rdpru wbnoinvd amd_ppin brs arat npt lbrv svm_lock nrip_save tsc_scale vmcb_clean flushbyasid decodeassists pausefilter pfthreshold avic v_vmsave_vmload vgif v_spec_ctrl umip pku ospke vaes vpclmulqdq rdpid overflow_recov succor smca fsrm debug_swap
Virtualization: AMD-V

[rcedgar]

Strange. It was built using an Action on a github Linux runner, which has worked consistently before AFAIK. I tested on AMD Ryzen Threadripper 7980X 64-Cores which is similar architecture, and this works fine. What happens if you recompile on the same computer?

[rcedgar]

md5sum reseek-v2.8-linux-x86
b243f380504ae06cd426f0fb0b4f1f5f  reseek-v2.8-linux-x86

Suggest check the md5 just in case the file is damaged somehow.

[pentamorfico]

If I recompile on the same computer it works perfectly fine, so it looks it may indeed be related with GitHub CI/CD?

I checked the md5sum and it matches. Also, another user in the same computer had the same issue and it was fixed after building from source

Let me know if you would like me to try something else to see if we can find the issue! It could also be a problem on our side

md5sum reseek-v2.8-linux-x86
b243f380504ae06cd426f0fb0b4f1f5f  reseek-v2.8-linux-x86

[rcedgar]

If recompiling fixes the problem this suggests the binary is crashing because compiler optimizations are generating instructions which are not supported on the machine where it crashes, if so the "real" problem is the compiler options in the GitHub actions. To verify this would require changing the options in the Action and checking if this fixes the problem, to do this (I think...) you would need to fork this repo so that you can run Actions yourself, but I'm not a GitHub expert. A hacky alternative would be to figure out exactly what Linux platform GitHub runners use and find another way to run that same platform e.g. on AWS or Azure.

[apcamargo]

I'm having the same issue here, in multiple computers.

I'll try to update the Bioconda recipe to check if the binary compiled through their CI will be free of this issue. This should provide an alternative way of people getting a pre-compiled binary.

[apcamargo]

In case someone faces the same issue and finds this thread, you can find a working binary here: #29 (comment)