DiscoSNP++ Kissnp2 module terminate called after throwing an instance of 'std::bad_alloc'

Question

[tkitapci]

I got the below error. This seems to be a memory problem but I am running this on a machine with 30GB of memory. Is this a memory related problem or something else ?

############################################################
        #######terminate called after throwing an instance of 'std::bad_alloc'############# KISSNP2 MODULE  #######################
        ############################################################
/home/cmb-02/sn1/tkitapci/software/DiscoSNP++-2.1.7-Source/build//tools/kissnp2/kissnp2 -in /home/cmb-07/sn1/tkitapci/BackUp/Dugesia_unzipped/dug_30.6.II/variant_call/Dugesia_k_31_c_4.h5 -out /home/cmb-07/sn1/tkitapci/BackUp/Dugesia_unzipped/dug_30.6.II/variant_call/Dugesia_k_31_c_4_D_0_P_1_b_0_withlow  -b 0 -l -P 1  -D 0  
terminate called after throwing an instance of 'std::bad_alloc'
  what():  std::bad_alloc
/home/cmb-02/sn1/tkitapci/software/DiscoSNP++-2.1.7-Source/run_discoSnp++.sh: line 330:  8020 Aborted                 $DISCO_BUILD_PATH/tools/kissnp2/kissnp2 -in $h5prefix.h5 -out $kissprefix -b $b $l -P $P -D $D $extend $option_cores_gatb
there was a problem with kissnp2, command line: /home/cmb-02/sn1/tkitapci/software/DiscoSNP++-2.1.7-Source/build//tools/kissnp2/kissnp2 -in /home/cmb-07/sn1/tkitapci/BackUp/Dugesia_unzipped/dug_30.6.II/variant_call/Dugesia_k_31_c_4.h5 -out /home/cmb-07/sn1/tkitapci/BackUp/Dugesia_unzipped/dug_30.6.II/variant_call/Dugesia_k_31_c_4_D_0_P_1_b_0_withlow  -b 0 -l -P 1  -D 0

Thanks!

Answer 1

[pierre.peterlongo]

Hi again,

Maybe this comes from your compilation troubles, mixing executables from 2.2.0 and from 2.1.7.

A good thing to do would be to

1. totally remove the 'build' directory generated using the 'compile_discoSnp++.sh' call
2. re-call 'compile_discoSnp++.sh' from scratch using the 2.2.0 version

In case of trouble, send me by email the full compilation log.

Best,
Pierre

[tkitapci]

Hi Pierre,

Thanks for your reply. I re-run it on our high memory node (120GB mem) and it run without any problem. I run on 1 core so multi-threading is not an issue here (although in the future I need to run on multi-core to make it faster). I think there was a memory spike at some point in the execution. I am running the 2.1.7 version and I am pretty sure there is no mixing of executables because I downloaded different version on separate directories.

Thanks
Hamdi

[pierre.peterlongo]

Indeed the 2.1.7 version had a memory issue, that was fixed later.