DiscoSNP++ Kissnp2 module terminate called after throwing an instance of 'std::bad_alloc'
1
0
Entering edit mode
5.6 years ago
tkitapci ▴ 60

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!

discosnp kissnp2 std::bad_alloc • 1.8k views
ADD COMMENT
0
Entering edit mode
5.6 years ago

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

ADD COMMENT
1
Entering edit mode

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

ADD REPLY
0
Entering edit mode

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

ADD REPLY

Login before adding your answer.

Traffic: 1605 users visited in the last hour
Help About
FAQ
Access RSS
API
Stats

Use of this site constitutes acceptance of our User Agreement and Privacy Policy.

Powered by the version 2.3.6