Segmentation fault during nhmmer search with binary (fm) database

[traviswheeler]

During testing on PR #253, @npcarter identified a scenario that causes nhmmer to seg fault while searching the binary target database format. The problem was observed in a branch used for the PR, but it reproduces in the develop branch. It's not universally reproducible - crashing only occurs with some combinations of (machine + --cpu value + --enable-debugging + flags to tighten or loosen the fm-index filter). It seems clear that this is a matter of an out-of-bounds memory access pattern that sometimes gets (un)lucky and stomps on an illegal address.

One way I've reproduced:

• Use a collection of scaffolds from https://mycocosm.jgi.doe.gov/saccharomycotina/saccharomycotina.info.html, totaling ~1.3Gb in target sequence. Below, I'll call this file 89x_JGI_Saccharomycotina-jan21.fa. Nick has the file in his possession, and I can share it if necessary.
• Use a query that I'll attach here (note: called "query.txt" because github won't accept a file with the extension .fasta): query.txt
• I've reproduced on a couple centos machines. One is : Linux version 3.10.0-1160.31.1.el7.x86_64, Red Hat 4.8.5-44. The error happens elsewhere, so this seems not to be important.
• Clone the develop branch of hmmer and easel
• % ./configure --enable-debugging (this isn't strictly necessary; the seg fault also raises w/o --enable-debugging in some scenarios)
• % make
• % makehmmerdb 89x_JGI_Saccharomycotina-jan21.fa 89x_JGI_Saccharomycotina-jan21.db
• % nhmmer --cpu=2 --tblout test.tblout test.fasta 89x_JGI_Saccharomycotina-jan21.db > test.out ---> seg fault

Next up: I'll start hunting for the source of the error

[npcarter]

Closing this because the work has been incorporated into issue #172.