I've been trying to run bullseye through Crux, and I get a core segmentation fault and core dump. I showed Kaipo the bug, and he wasn't able to figure out what was going on with a short investigation. Attached is the configure file for Hardklor that contains the paths to all of the input files and the parameters used.
Here is the backtrace:
0 std::basic_fstream<char, std::char_traits\<char=""> >::open(char const*, std::_Ios_Openmode) () at /usr/src/gcc-4.8.1/build/x86_64-unknown-linux-gnu/libstdc++-v3/include/fstream:894</char,>
1 0x0000000000ace985 in CruxHardklorApplication::hardklorMain(int, char**) ()
2 0x0000000000ac795d in CruxHardklorApplication::main(std::basic_string<char, std::char_traits\<char="">, std::allocator\<char> > const&) ()</char></char,>
3 0x00000000008e4dc1 in CruxBullseyeApplication::main(int, char**) ()
4 0x00000000009092f7 in CruxApplicationList::main(int, char**) ()
5 0x0000000000875630 in main ()
I think it might have to do with the fact that if I run my data on Hardklor separately, I get an output that is empty of isotope distributions. Perhaps bullseye is looking for something that isn't there and thus returns a segfault.
Alex, you should produce a tar file that reproduces this problem and then hand this issue off to Kaipo.
The command that causes the segfault is below:
crux bullseye --overwrite T --output-dir /net/noble/vol3/user/alexhu/proj/crux-projects/2013MouseHeartProteome/data/2014-02-27/bullseye_runs /net/noble/vol3/user/alexhu/proj/crux-projects/2013MouseHeartProteome/data/ms1/82593_lv_mcx_DIA_5mz_525to650.ms1 /net/gs/vol1/home/alexhu/proj/crux-projects/2013MouseHeartProteome/data/charged/centroided/82593_lv_mcx_DIA_5mz_525to650.ms2
I gave the full directory path to those files. The output directory is here:
/net/noble/vol3/user/alexhu/proj/crux-projects/2013MouseHeartProteome/data/2014-02-27/bullseye_runs
Which contains the empty hardklor.mono.txt file.
I also added a tar file in that directory that contains the ms1 and ms2 files that cause the segfault.
The code changes look good, and it fixes the problem. Thanks! The code review is approved.
Fixed in r16325