Segmentation violation when switching TFile

Dear all,
I made a routine where firts 2 TFiles are created, as well as 2 TTrees
A loop follows where the 2 TTrees are filled.
Finally outside the loop the 2 TTrees are written on the respective TFiles and the TFiles are closed.

The created TFiles exceed 1.9 GB, therefore ROOT automatically switches to new TFiles, but when this happens, the routine crashes and I obtain “*** Break *** segmentation violation”.

I gave a look at Fill: Switching to new file /*** Break*** segmentation viola

For debugging faster, I inserted “TTree::SetMaxTreeSize(500000)”, so that each time I modified the routine I did not have to wait for one hour to see if corrections worked.
But actually no one trial was successfull…

Could someone help me, please?

Thanks,
bye,
Fra
AddDiff.C (6.54 KB)
PXMG001_TRACK.txt (1.76 MB)

Hi,

this is hardly a solution but, is it possible for you to separately create the TFiles?

I mean a structure like below:

TTree t1,t2;

Loop to fill t1,t2;

TFile f1;

t1.Write();

f1.Close();

TFile f2;

t2.Write();

f2.Close();

Hi franciuska,

the problem is that once a file switches the original pointers to the file
become invalid (in this case tout_YES, but potentially also tout_NO). You
access such invalid pointers in lines 164 and 175, but these operations do
nothing (you can work on the contained TTrees without cd’ing to the file).
Just removing these lines fixes this particular segfault.

Btw, one can locate the problem pretty quickly when running this program
standalone. After I added

int main() {
  run();
}

to the end of your code I compiled and ran it with

$ make AddDiff CXXFLAGS="$(root-config --cflags) -ggdb3" LDFLAGS="$(root-config --libs)"
$ ./AddDiff
PXMG001_TRACK.txt
 The file PXMG001_TRACK.txt has 11812 lines 
 You have info about 868 events 
Fill: Switching to new file: PROVAResults_YES_1.root

 *** Break *** segmentation violation

===========================================================
There was a crash.
This is the entire stack trace of all threads:
===========================================================
#0  0x00007ff9b009b80e in waitpid () from /lib64/libc.so.6
#1  0x00007ff9b002386e in ?? () from /lib64/libc.so.6
#2  0x00007ff9b4a97594 in TUnixSystem::StackTrace() () from /usr/lib64/root/libCore.so.5.34
#3  0x00007ff9b4a99e83 in TUnixSystem::DispatchSignals(ESignals) () from /usr/lib64/root/libCore.so.5.34
#4  <signal handler called>
#5  0x0000000000000000 in ?? ()
#6  0x0000000000402c91 in run () at AddDiff.C:164
#7  0x0000000000403390 in main () at AddDiff.C:239
===========================================================

[..]

which immediately pointed me to line 164.

Cheers,

Benjamin

Hi Benjamin,
thanks a lot for the solution and also for the hint about debugging!

Fra