TMVA::MethodBDT throws St9bad_alloc while reading trees

TMVA
1

Hi Everyone,

I get a St9bad_alloc when I am reading the 4th tree (out of 200) from a txt weights file. The error comes from:

TMVA::MethodBDT::ReadWeightsFromStream( istream& istr )
defined in
tmva/src/MethodBDT.cxx

The trees were trained using root 5.16 and I am using root 5.28, but that shouldn’t be a problem, since other people on other systems have had no problems with this.

digging even deeper, the St9bad_alloc crash comes from the line:

 currentNode = CreateNode(); // create a new node to be read next

in tmva/src/BinaryTree.cxx

The function is defined in:
tmva/src/G__TMVA2.cxx
G__memfunc_setup(“CreateNode”,986,G__G__TMVA2_243_0_4, 85,
G__get_linked_tagnum(&G__G__TMVA2LN_TMVAcLcLNode), -1, 0, 0, 1, 1, 8,
"", (char*)NULL, (void
*) NULL, 3);

auto-generated by:
core/utils/src/rootcint_tmp

I don’t understand what this memfunc_setup is or what the problem could be.

I’m using Red Hat 4.1.2. I don’t think I’m running out of memory, the weights file is only 18MB and it crashes already on the 4th out of 200 trees. Any thoughts?

Thanks,

Matt

2

I found the problem myself.
In TMVA::DecisionTreeNode.cxx it reads in the records one at a time, including one variable called “ULong_t lseq”. The training files were created on a machine which has 8 bytes for ULongs, but my machine uses has sizeof(ULong_t) = 4. It’s a local variable (to the function) and is not stored anywhere so I changed it to a long long and recompiled, now it works fine.

I don’t know if I should submit a bug report over this, since it’s apparently a machine/compiler dependent thing.

Cheers,

Matt

3

Hi Matt,

[quote]“ULong_t lseq”. The training files were created on a machine which has 8 bytes for ULongs, but my machine uses has sizeof(ULong_t) = 4. [/quote]This likely resulted in a (fatal) loss of data. Your solution is the right one (i.e. make sure no data is lost).

Cheers,
Philippe.