blahah
commented
9 years ago We are also seeing this. It's a non-deterministic error, so that when I run the same command twice it will sometimes produce a truncated bam output. The command exits with a zero status code, indicating that SNAP hasn't errored. The issue doesn't happen when run with a single thread, and it seems to happen more often the more threads there are.
I noticed today that SNAP produces corrupt SAM output (samtools aborts with a truncated input error message) under the new Yosemite Mac OS. I cannot say exactly what's wrong with the files, they just seem to have blocks of junk data inserted in seemingly random places.
This problem exists in the latest Mac binary downloaded from the home page, but also already in SNAP 0.15.4. At least for 0.15.4 it is not solved by source compilation on Yosemite. I think the problem lies with SNAPs thread management since files are fine when produced with -t 1 in SNAP 0.15.4. (I couldn't confirm this with the latest version because of an independent bug that I'm going to report along with this one.)
You can, however, take a binary compiled on Yosemite and run it on 10.8 Mountain Lion and it works just fine (even though all dynamically linked libraries have the exact same version).
If you find a solution for this bug, I would be very interested in getting a fix for version 0.15.4 as well (could patch it myself if you tell me how) since our own code still depends on this version.
Thanks a lot for developing SNAP, Wolfgang
P.S.: forgot to mention the command I used: snap paired with -t 6 -C++