Bad_alloc exception while reading ROOT files friends

ROOT
1

I am using root 5.34.26 under windows (VC++12 release). I am trying to read a peculiar root file which has a large number of tress (10708). Each tree in the file has 53 branches of type double and has a friend tree in a secondary file which contains an extra 3 ‘friend’ branches. While doing a recursive read I get a bad_alloc exception after reading 600 to 700 trees (main and friend) or so. As I understand it this exception essentially means that I am running out of memory.

I’ve tried dropping all buffers and baskets and still the issue persists and the only solution that seems to work is deleting the tree pointers once I’ve read the data. Is this the correct way of doing things or am I missing something? Please note that this issue does not occur while reading from a standalone file.

In order to reproduce the issue you may use the following scripts:
[ul]
use the script and set delete_ptr_after_use to false to see the issue : ForumEntryTestRead.cpp (4.74 KB)
standalone file generation script : ForumEntryTestFullWriteNoFriends.cpp (1.83 KB)
main and ‘friend’ file generation script : ForumEntryTestFullWriteHasFriends.cpp (3.31 KB)
[/ul]

2

Try [url=https://root-forum.cern.ch/t/hadd-problem/15725/5 old thread[/url].

3

I’ve edited my original post to include information on my configuration (root 5.34.26 VC++12 release). Since I am running windows the limits and ulimits commands are not available.

I am using ReadObj to get each individual TTree pointer I assume that this does a new allocation every-time it is called. Could I be running out of memory because of this?

4

Hi,

I do not see any obvious memory leak in that code … except for the fact that there are many (largish) object being created on the stack … and the code is interpreted. CINT has not notorious (and hard to fix) problem with temporary variable and their lifetime.

Could you try you example in compiled code (For example making you script a named script and compiling it with ACLIC)?

Thanks,
Philippe.