Unable to install on Ubuntu 20 (Illegal instruction in VM)

[jcolicchio-soundag]

When attempting to instal modkit on Ubuntu 20 either from the tar or from source we are getting the following error:

Installing mod_kit v0.1.8 (/home/modkit)
Updating crates.io index
Illegal instruction (core dumped)

We tried going back and reinstalling possible prerequisites that could be causing the issue, but to no avail. It is working properly using the exact same commands for us on MacOS.

Thanks for your help,
Jack

[ArtRand]

Hello @jcolicchio-soundag,

Could you tell me a little more about the compute environment you have, which processor architecture are you on? Which version of cargo and cmake? Could you show me the error that the pre-built binary gives you?

[jcolicchio-soundag]

Definitely! Cargo and Cmake were both updated just today so they are at latest versions (Cmake 3.26.4). After updating cmake and cargo and restarting the terminal, we thought we were able to successfully install from source. After doing this, running modkit --h worked properly, and everything seemed good to go, but when we went to actually run modkit pileup on a bam file we just created from dorado (and sorted), we were back receiving the same initial error message (Illegal instruction (core dumped)).

This is the exact same message we got when trying to run modkit downloaded from the prebuilt binary.

As far as computer architecture, this is being run on a server node with an Intel Xeon Gold 6148 running Ubuntu 20.04. This was released end of 2017, so definitely is a bit dated. This same node is successfully running dorado.

[jcolicchio-soundag]

Here is the full CPU info:

[ArtRand]

@jcolicchio-soundag That's certainly perplexing. Would it be at all possible for you to share the file with me so I can try and reproduce the problem? Looks like you're running in a VM, correct? I don't see AVX, it's possible that's the problem, but just a guess right now. You may try compiling with RUSTFLAGS="-C target-feature=-avx".

[jcolicchio-soundag]

Ok, I tried setting the RUSTFLAGS (just entered the command you posted above) and then re-compiling with cargo install, but to no avail (unless i did this wrong ). I also confirmed that when i run the same command on my local mac with this same bam file and all it works just fine, so it really seems like it is somehow specific to the configuration on our cluster (maybe the CPU not compatible with .

Edit: Yes to VM, and just added the bam and bam.bai
test_modified_bases.sorted.bam.bai.zip
test_modified_bases.sorted.bam.zip

[ArtRand]

Yup, there's nothing wrong with the file (other than missing alignments).

Just to be clear, you're excuting

RUSTFLAGS="-C target-feature=-avx" cargo install --path .

(so that RUSTFLAGS is in the environment when building, correct?).

I confirmed on my linux 20.04 server that your file works with modkit summary

> sampling 10042 reads from BAM
> calculating threshold at 10% percentile
> calculated thresholds: C: 0.5683594
# bases             C
# total_reads_used  4000
# count_reads_C     4000
# pass_threshold_C  0.5683594
 base  code  pass_count  pass_frac   all_count  all_frac
 C     h     46672       0.19724953  57893      0.22104074
 C     m     155478      0.65709555  167287     0.638717
 C     -     34464       0.14565495  36731      0.1402423

You may also try RUSTFLAGS="-C target-feature=-avx,-avx2 -C target-cpu=native" cargo build --release. I don't have a VM exactly like yours to test on, however, so I'm just guessing. Also try setting RUST_BACKTRACE=full when running and it might give some clues as to where the problem is coming from. If we can narrow it down, maybe I can put the call behind a feature flag.

[jcolicchio-soundag]

Yeah, tried those and still no luck! I can see that setting those flags are causing it to recompile and overwrite, but still getting the same error. Additionally, even after setting RUST_BACKTRACE=full, we are still getting the same error and the log file does not contain any useful information.

[ArtRand]

Does the debug build also fail? Could you also try an older version of modkit (download an <=0.1.6 binary) and see if they also have this problem? Does modkit summary also fail?

[jcolicchio-soundag]

modkit summary does indeed also fail. Im not sure what exactly you are referring to with the debug build, I tried this: RUSTFLAGS="-C target-feature=-avx,-avx2 -C target-cpu=native" cargo build --release , but im not sure if that is what you are referring to. Tomorrow I will try to give a try to one of the earlier versions of modkit. Just to make sure it wasnt a more general issue, I did just install modbamtobed on this same VM and it is working properly.

[ArtRand]

You can make a debug build by omitting he --release flag: RUSTFLAGS="-C target-feature=-avx,-avx2" cargo build. Then try with full backtrace: RUST_BACKTRACE=full target/debug/modkit pileup <in.bam> <out.bed>.

[jcolicchio-soundag]

Still nothing, I was able to confirm it was running in debug mode, but didnt give any more info sadly!

The log:

[src/logging.rs::54] [DEBUG] commandline: target/debug/modkit pileup test.bam modkit.bed --log-filepath modkitlog.log

[ArtRand]

That's certainly frustrating, but not completely unexpected. From googling, I suspect that cargo is expecting that you have some instructions available that in fact aren't available. Do you have another linux environment you could check on? Maybe the difference would be informative? I'm afraid it's very difficult for me to help debug.