roottalk

ArchiveSeg.fault when quitting ROOT v5.34.00 Flat

Quick Launch

All Site Content

Posted By

Post

E-mailed: 06/12/2012 18:24

View Properties

Reply

Christopher Rob Jones

Seg.fault when quitting ROOT v5.34.00

Hi,

I have an application that reads in a TTree from a ROOT file, filters it
based on a set of cuts (in the form of the TCut) using a TEntryList, and
writes out the selected entries to an output file. The code for this is here

<https://svnweb.cern.ch/trac/lhcb/browser/Erasmus/trunk/Phys/B2D0hD2KsPiPiDalitz/src/applications/FilterNTuple/FilterNTuple_main.cpp>

This all seems to work fine. I can open the filtered root file and
navigate the TTree with a TBrowser etc. However, when I quit I get the
seg. fault below.

The problem seems to come from lines 85-89. The original TTree is in a
directory in the file, "Tuple_BDKstar", and these lines are supposed to
replicate this in the filtered file. They work, but seem to cause the
traceback when reading the output, since if I comment out these lines
(and have the TTree written to the output file root dir.) I don't get
the traceback.

I cannot figure out what I'm doing wrong here, or if this is just a bug
in ROOT. Any suggestions ?

cheers Chris

pciy ~/cmtuser/DaVinci_v33r1/Phys/B2D0hD2KsPiPiDalitz/scripts > root
/r02/lhcb/jonesc/B2D0KstarD2KsPiPiDalitz/V2/Presel/Collision11.root
   *******************************************
   *                                         *
   *        W E L C O M E to R O O T       *
   *                                         *
   *   Version   5.34/03   27 October 2012   *
   *                                         *
   * You are welcome to visit our Web site *
   *          http://root.cern.ch            *
   *                                         *
   *******************************************

ROOT 5.34/03 (tags/v5-34-03@46856, Oct 27 2012, 23:19:27 on linuxx8664gcc)

CINT/ROOT C/C++ Interpreter version 5.18.00, July 2, 2010
Type ? for help. Commands must be C++ statements.
Enclose multiple statements between { }.
root [0]
Attaching file
/r02/lhcb/jonesc/B2D0KstarD2KsPiPiDalitz/V2/Presel/Collision11.root as
_file0...
root [1] .q

  *** Break *** segmentation violation

===========================================================
There was a crash.
This is the entire stack trace of all threads:
===========================================================
#0 0x0000003b70e997b5 in waitpid () from /lib64/libc.so.6
#1 0x0000003b70e3c761 in do_system () from /lib64/libc.so.6
#2 0x00002b8de8c7e580 in TUnixSystem::StackTrace() () from
/cvmfs/lhcb.cern.ch/lib/lcg/app/releases/ROOT/5.34.03/x86_64-slc5-gcc46-opt/root/lib/libCore.so
#3 0x00002b8de8c80e23 in TUnixSystem::DispatchSignals(ESignals) ()
    from
/cvmfs/lhcb.cern.ch/lib/lcg/app/releases/ROOT/5.34.03/x86_64-slc5-gcc46-opt/root/lib/libCore.so
#4 <signal handler called>
#5 0x0000000000000061 in ?? ()
#6 0x00002b8de8c3330b in THashTable::FindObject(TObject const*) const ()
    from
/cvmfs/lhcb.cern.ch/lib/lcg/app/releases/ROOT/5.34.03/x86_64-slc5-gcc46-opt/root/lib/libCore.so
#7 0x00002b8de8c36d7f in TMap::GetValue(TObject const*) const () from
/cvmfs/lhcb.cern.ch/lib/lcg/app/releases/ROOT/5.34.03/x86_64-slc5-gcc46-opt/root/lib/libCore.so
#8 0x00002b8dedb5fda0 in TFile::SetCacheRead(TFileCacheRead*, TObject*,
TFile::ECacheAction) ()
    from
/cvmfs/lhcb.cern.ch/lib/lcg/app/releases/ROOT/5.34.03/x86_64-slc5-gcc46-opt/root/lib/libRIO.so
#9 0x00002b8df046e106 in TTreeCache::~TTreeCache() () from
/cvmfs/lhcb.cern.ch/lib/lcg/app/releases/ROOT/5.34.03/x86_64-slc5-gcc46-opt/root/lib/libTree.so
#10 0x00002b8df046e189 in TTreeCache::~TTreeCache() () from
/cvmfs/lhcb.cern.ch/lib/lcg/app/releases/ROOT/5.34.03/x86_64-slc5-gcc46-opt/root/lib/libTree.so
#11 0x00002b8dedb645f6 in TFile::~TFile() () from
/cvmfs/lhcb.cern.ch/lib/lcg/app/releases/ROOT/5.34.03/x86_64-slc5-gcc46-opt/root/lib/libRIO.so
#12 0x00002b8dedb648a9 in TFile::~TFile() () from
/cvmfs/lhcb.cern.ch/lib/lcg/app/releases/ROOT/5.34.03/x86_64-slc5-gcc46-opt/root/lib/libRIO.so
#13 0x00002b8de8c316e9 in TCollection::GarbageCollect(TObject*) ()
    from
/cvmfs/lhcb.cern.ch/lib/lcg/app/releases/ROOT/5.34.03/x86_64-slc5-gcc46-opt/root/lib/libCore.so
#14 0x00002b8de8c35215 in TList::Delete(char const*) () from
/cvmfs/lhcb.cern.ch/lib/lcg/app/releases/ROOT/5.34.03/x86_64-slc5-gcc46-opt/root/lib/libCore.so
#15 0x00002b8de8becaa7 in TROOT::~TROOT() () from
/cvmfs/lhcb.cern.ch/lib/lcg/app/releases/ROOT/5.34.03/x86_64-slc5-gcc46-opt/root/lib/libCore.so
#16 0x0000003b70e337fe in __cxa_finalize () from /lib64/libc.so.6
#17 0x00002b8de8baaaf6 in __do_global_dtors_aux () from
/cvmfs/lhcb.cern.ch/lib/lcg/app/releases/ROOT/5.34.03/x86_64-slc5-gcc46-opt/root/lib/libCore.so
#18 0x0000000000000000 in ?? ()
===========================================================

The lines below might hint at the cause of the crash.
If they do not help you then please submit a bug report at
http://root.cern.ch/bugs. Please post the ENTIRE stack trace
from above as an attachment in addition to anything else
that might help us fixing this issue.
===========================================================
#5 0x0000000000000061 in ?? ()
#6 0x00002b8de8c3330b in THashTable::FindObject(TObject const*) const ()
    from
/cvmfs/lhcb.cern.ch/lib/lcg/app/releases/ROOT/5.34.03/x86_64-slc5-gcc46-opt/root/lib/libCore.so
#7 0x00002b8de8c36d7f in TMap::GetValue(TObject const*) const () from
/cvmfs/lhcb.cern.ch/lib/lcg/app/releases/ROOT/5.34.03/x86_64-slc5-gcc46-opt/root/lib/libCore.so
#8 0x00002b8dedb5fda0 in TFile::SetCacheRead(TFileCacheRead*, TObject*,
TFile::ECacheAction) ()
    from
/cvmfs/lhcb.cern.ch/lib/lcg/app/releases/ROOT/5.34.03/x86_64-slc5-gcc46-opt/root/lib/libRIO.so
#9 0x00002b8df046e106 in TTreeCache::~TTreeCache() () from
/cvmfs/lhcb.cern.ch/lib/lcg/app/releases/ROOT/5.34.03/x86_64-slc5-gcc46-opt/root/lib/libTree.so
#10 0x00002b8df046e189 in TTreeCache::~TTreeCache() () from
/cvmfs/lhcb.cern.ch/lib/lcg/app/releases/ROOT/5.34.03/x86_64-slc5-gcc46-opt/root/lib/libTree.so
#11 0x00002b8dedb645f6 in TFile::~TFile() () from
/cvmfs/lhcb.cern.ch/lib/lcg/app/releases/ROOT/5.34.03/x86_64-slc5-gcc46-opt/root/lib/libRIO.so
#12 0x00002b8dedb648a9 in TFile::~TFile() () from
/cvmfs/lhcb.cern.ch/lib/lcg/app/releases/ROOT/5.34.03/x86_64-slc5-gcc46-opt/root/lib/libRIO.so
#13 0x00002b8de8c316e9 in TCollection::GarbageCollect(TObject*) ()
    from
/cvmfs/lhcb.cern.ch/lib/lcg/app/releases/ROOT/5.34.03/x86_64-slc5-gcc46-opt/root/lib/libCore.so
#14 0x00002b8de8c35215 in TList::Delete(char const*) () from
/cvmfs/lhcb.cern.ch/lib/lcg/app/releases/ROOT/5.34.03/x86_64-slc5-gcc46-opt/root/lib/libCore.so
#15 0x00002b8de8becaa7 in TROOT::~TROOT() () from
/cvmfs/lhcb.cern.ch/lib/lcg/app/releases/ROOT/5.34.03/x86_64-slc5-gcc46-opt/root/lib/libCore.so
#16 0x0000003b70e337fe in __cxa_finalize () from /lib64/libc.so.6
#17 0x00002b8de8baaaf6 in __do_global_dtors_aux () from
/cvmfs/lhcb.cern.ch/lib/lcg/app/releases/ROOT/5.34.03/x86_64-slc5-gcc46-opt/root/lib/libCore.so
#18 0x0000000000000000 in ?? ()
===========================================================

E-mailed: 06/12/2012 18:50

View Properties

Reply

pcanal@fnal.gov

Hi Chris,

Can you provide a complete running example?
Alternatively, can you try to move the creation of the TFile to *before* the creation to the TTree (CloneTree(0))?

Cheers,
Philippe.

Show Quoted Messages

E-mailed: 06/12/2012 19:02

View Properties

Reply

Christopher Rob Jones

Hi,

Show Quoted Messages

E-mailed: 06/12/2012 19:07

View Properties

Reply

Christopher Rob Jones

Hi,

> Alternatively, can you try to move the creation of the TFile to *before*
> the creation to the TTree (CloneTree(0))?

That didn't help unfortunately, I still get the trace back when reading
the ROOT file.

Here is the gdb traceback from a debug build.

cheers Chris

pciy ~/cmtuser/DaVinci_v33r1/Phys/B2D0hD2KsPiPiDalitz/scripts > gdb
--args root.exe Collision12-ANNPID.root
GNU gdb (GDB) Red Hat Enterprise Linux (7.0.1-42.el5_8.1)
Copyright (C) 2009 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later
<http://gnu.org/licenses/gpl.html>
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law. Type "show copying"
and "show warranty" for details.
This GDB was configured as "x86_64-redhat-linux-gnu".
For bug reporting instructions, please see:
<http://www.gnu.org/software/gdb/bugs/>...
Reading symbols from
/afs/cern.ch/sw/lcg/app/releases/ROOT/5.34.03/x86_64-slc5-gcc46-dbg/root/bin/root.exe...done.
(gdb) run
Starting program:
/afs/cern.ch/sw/lcg/app/releases/ROOT/5.34.03/x86_64-slc5-gcc46-dbg/root/bin/root.exe
Collision12-ANNPID.root
warning: no loadable sections found in added symbol-file system-supplied
DSO at 0x2aaaaaaab000
   *******************************************
   *                                         *
   *        W E L C O M E to R O O T       *
   *                                         *
   *   Version   5.34/03   27 October 2012   *
   *                                         *
   * You are welcome to visit our Web site *
   *          http://root.cern.ch            *
   *                                         *
   *******************************************

ROOT 5.34/03 (tags/v5-34-03@46856, Oct 27 2012, 23:19:27 on linuxx8664gcc)

CINT/ROOT C/C++ Interpreter version 5.18.00, July 2, 2010
Type ? for help. Commands must be C++ statements.
Enclose multiple statements between { }.
Detaching after fork from child process 2478.
[Thread debugging using libthread_db enabled]
root [0]
Attaching file Collision12-ANNPID.root as _file0...
root [1] .q

Program received signal SIGSEGV, Segmentation fault.
0x0000000000000000 in ?? ()
(gdb) where
#0 0x0000000000000000 in ?? ()
#1 0x00002aaaaad7c75b in THashTable::GetHashValue (this=0x229a240,
obj=0x26fec30) at include/THashTable.h:92
#2 0x00002aaaaad7b648 in THashTable::FindObject (this=0x229a240,
obj=0x26fec30) at
/build/bellenot/SPI/x86_64-slc5-gcc46-dbg/root/core/cont/src/THashTable.cxx:206
#3 0x00002aaaaad801e2 in TMap::GetValue (this=0x2288120, key=0x26fec30)
at /build/bellenot/SPI/x86_64-slc5-gcc46-dbg/root/core/cont/src/TMap.cxx:257
#4 0x00002aaab2209588 in TFile::SetCacheRead (this=0x2288190,
cache=0x0, tree=0x26fec30, action=kDisconnect)
     at
/build/bellenot/SPI/x86_64-slc5-gcc46-dbg/root/io/io/src/TFile.cxx:2100
#5 0x00002aaab4cae62a in TTreeCache::~TTreeCache (this=0x26c6df0,
__in_chrg=<value optimized out>)
     at
/build/bellenot/SPI/x86_64-slc5-gcc46-dbg/root/tree/tree/src/TTreeCache.cxx:314
#6 0x00002aaab4cae73e in TTreeCache::~TTreeCache (this=0x26c6df0,
__in_chrg=<value optimized out>)
     at
/build/bellenot/SPI/x86_64-slc5-gcc46-dbg/root/tree/tree/src/TTreeCache.cxx:318
#7 0x00002aaab2202f99 in TFile::~TFile (this=0x2288190,
__in_chrg=<value optimized out>) at
/build/bellenot/SPI/x86_64-slc5-gcc46-dbg/root/io/io/src/TFile.cxx:507
#8 0x00002aaab2203486 in TFile::~TFile (this=0x2288190,
__in_chrg=<value optimized out>) at
/build/bellenot/SPI/x86_64-slc5-gcc46-dbg/root/io/io/src/TFile.cxx:528
#9 0x00002aaaaad784a1 in TCollection::GarbageCollect (obj=0x2288190) at
/build/bellenot/SPI/x86_64-slc5-gcc46-dbg/root/core/cont/src/TCollection.cxx:591
#10 0x00002aaaaad7d766 in TList::Delete (this=0x7579b0,
option=0x2aaaab1cd034 "slow") at
/build/bellenot/SPI/x86_64-slc5-gcc46-dbg/root/core/cont/src/TList.cxx:394
#11 0x00002aaaaad29be2 in TROOT::~TROOT (this=0x2aaaab5aa340,
__in_chrg=<value optimized out>)
     at
/build/bellenot/SPI/x86_64-slc5-gcc46-dbg/root/core/base/src/TROOT.cxx:500
#12 0x0000003b70e337fe in __cxa_finalize () from /lib64/libc.so.6
#13 0x00002aaaaacd2a46 in __do_global_dtors_aux () from
/afs/cern.ch/sw/lcg/app/releases/ROOT/5.34.03/x86_64-slc5-gcc46-dbg/root/lib/libCore.so
#14 0x0000000000000000 in ?? ()

>
> Cheers,
> Philippe.
>

Show Quoted Messages

E-mailed: 06/12/2012 19:17

View Properties

Reply

pcanal@fnal.gov

Hi Chris,

I can reproduce the problem and will look into it.

Cheers,
Philippe.

Show Quoted Messages

E-mailed: 06/12/2012 19:23

View Properties

Reply

nickve.nl@gmail.com

Hi Chris,

I think this is related to a similar problem that I have encountered already several

ROOT versions ago.

I could probably trace the problem back to the fact that if one has a TFile (or TFolder) that contains

several objects, the earlier versions of ROOT did not by default delete the objects themselves when one

deleted (or closed) the file or folder. It seems that in newer ROOT versions these objects get deleted as well.

Obviously this gives a seg fault if one closes (or deletes) a file and then also wants to delete the various objects.

In your traceback I see a problem with the deletion of a TList, so to my opinion this is related to the problem I

encountered. I solved it for my cases (since the analysis must go on :) by just not closing a file explicitly, but obviously

this is not an elegant solution. Maybe our ROOT guru's can have a look into the problem to see whether the default

behaviour of deleting objects in a TFile, TFolder of TList has been changed in the past.

I don't know at which ROOT version I encountered this problem for the firts time, but if my memory is correct,

ROOT 5.14 was still working fine.

Cheers,

Nick.

Nick van Eijndhoven
Professor of Physics
Vrije Universiteit Brussel (VUB-ELEM)
Inter-university Institute for High Energies (IIHE)
Pleinlaan 2, B-1050 Brussel, Belgium
===============================================
Office : 0G-122 tel: +32.(0)2.629.3212 gsm: +32.(0)488.074166
Secr. : 1G-006 tel: +32.(0)2.629.3203 fax : +32.(0)2.629.3816
Email : Nick.van.Eijndhoven@vub.ac.be or : nick@icecube.wisc.edu
Web : http://www.iihe.ac.be http://sites.google.com/site/nickveweb
Skype: nickve.nl Gsm-NL: +31.(0)6.40181589

"In the beginning there was nothing, which exploded".

On Thu, Dec 6, 2012 at 6:23 PM, Chris Jones <jonesc@hep.phy.cam.ac.uk> wrote:

Hi,

I have an application that reads in a TTree from a ROOT file, filters it based on a set of cuts (in the form of the TCut) using a TEntryList, and writes out the selected entries to an output file. The code for this is here

<https://svnweb.cern.ch/trac/lhcb/browser/Erasmus/trunk/Phys/B2D0hD2KsPiPiDalitz/src/applications/FilterNTuple/FilterNTuple_main.cpp>

This all seems to work fine. I can open the filtered root file and navigate the TTree with a TBrowser etc. However, when I quit I get the seg. fault below.

The problem seems to come from lines 85-89. The original TTree is in a directory in the file, "Tuple_BDKstar", and these lines are supposed to replicate this in the filtered file. They work, but seem to cause the traceback when reading the output, since if I comment out these lines (and have the TTree written to the output file root dir.) I don't get the traceback.

I cannot figure out what I'm doing wrong here, or if this is just a bug in ROOT. Any suggestions ?

cheers Chris

pciy ~/cmtuser/DaVinci_v33r1/Phys/B2D0hD2KsPiPiDalitz/scripts > root /r02/lhcb/jonesc/B2D0KstarD2KsPiPiDalitz/V2/Presel/Collision11.root
*******************************************
* *
* W E L C O M E to R O O T *
* *
* Version 5.34/03 27 October 2012 *
* *
* You are welcome to visit our Web site *
* http://root.cern.ch *
* *
*******************************************

ROOT 5.34/03 (tags/v5-34-03@46856, Oct 27 2012, 23:19:27 on linuxx8664gcc)

CINT/ROOT C/C++ Interpreter version 5.18.00, July 2, 2010
Type ? for help. Commands must be C++ statements.
Enclose multiple statements between { }.
root [0]
Attaching file /r02/lhcb/jonesc/B2D0KstarD2KsPiPiDalitz/V2/Presel/Collision11.root as _file0...
root [1] .q

*** Break *** segmentation violation

===========================================================
There was a crash.
This is the entire stack trace of all threads:
===========================================================
#0 0x0000003b70e997b5 in waitpid () from /lib64/libc.so.6
#1 0x0000003b70e3c761 in do_system () from /lib64/libc.so.6
#2 0x00002b8de8c7e580 in TUnixSystem::StackTrace() () from /cvmfs/lhcb.cern.ch/lib/lcg/app/releases/ROOT/5.34.03/x86_64-slc5-gcc46-opt/root/lib/libCore.so
#3 0x00002b8de8c80e23 in TUnixSystem::DispatchSignals(ESignals) ()
from /cvmfs/lhcb.cern.ch/lib/lcg/app/releases/ROOT/5.34.03/x86_64-slc5-gcc46-opt/root/lib/libCore.so
#4 <signal handler called>
#5 0x0000000000000061 in ?? ()
#6 0x00002b8de8c3330b in THashTable::FindObject(TObject const*) const ()
from /cvmfs/lhcb.cern.ch/lib/lcg/app/releases/ROOT/5.34.03/x86_64-slc5-gcc46-opt/root/lib/libCore.so
#7 0x00002b8de8c36d7f in TMap::GetValue(TObject const*) const () from /cvmfs/lhcb.cern.ch/lib/lcg/app/releases/ROOT/5.34.03/x86_64-slc5-gcc46-opt/root/lib/libCore.so
#8 0x00002b8dedb5fda0 in TFile::SetCacheRead(TFileCacheRead*, TObject*, TFile::ECacheAction) ()
from /cvmfs/lhcb.cern.ch/lib/lcg/app/releases/ROOT/5.34.03/x86_64-slc5-gcc46-opt/root/lib/libRIO.so
#9 0x00002b8df046e106 in TTreeCache::~TTreeCache() () from /cvmfs/lhcb.cern.ch/lib/lcg/app/releases/ROOT/5.34.03/x86_64-slc5-gcc46-opt/root/lib/libTree.so
#10 0x00002b8df046e189 in TTreeCache::~TTreeCache() () from /cvmfs/lhcb.cern.ch/lib/lcg/app/releases/ROOT/5.34.03/x86_64-slc5-gcc46-opt/root/lib/libTree.so
#11 0x00002b8dedb645f6 in TFile::~TFile() () from /cvmfs/lhcb.cern.ch/lib/lcg/app/releases/ROOT/5.34.03/x86_64-slc5-gcc46-opt/root/lib/libRIO.so
#12 0x00002b8dedb648a9 in TFile::~TFile() () from /cvmfs/lhcb.cern.ch/lib/lcg/app/releases/ROOT/5.34.03/x86_64-slc5-gcc46-opt/root/lib/libRIO.so
#13 0x00002b8de8c316e9 in TCollection::GarbageCollect(TObject*) ()
from /cvmfs/lhcb.cern.ch/lib/lcg/app/releases/ROOT/5.34.03/x86_64-slc5-gcc46-opt/root/lib/libCore.so
#14 0x00002b8de8c35215 in TList::Delete(char const*) () from /cvmfs/lhcb.cern.ch/lib/lcg/app/releases/ROOT/5.34.03/x86_64-slc5-gcc46-opt/root/lib/libCore.so
#15 0x00002b8de8becaa7 in TROOT::~TROOT() () from /cvmfs/lhcb.cern.ch/lib/lcg/app/releases/ROOT/5.34.03/x86_64-slc5-gcc46-opt/root/lib/libCore.so
#16 0x0000003b70e337fe in __cxa_finalize () from /lib64/libc.so.6
#17 0x00002b8de8baaaf6 in __do_global_dtors_aux () from /cvmfs/lhcb.cern.ch/lib/lcg/app/releases/ROOT/5.34.03/x86_64-slc5-gcc46-opt/root/lib/libCore.so
#18 0x0000000000000000 in ?? ()
===========================================================

The lines below might hint at the cause of the crash.
If they do not help you then please submit a bug report at
http://root.cern.ch/bugs. Please post the ENTIRE stack trace
from above as an attachment in addition to anything else
that might help us fixing this issue.
===========================================================
#5 0x0000000000000061 in ?? ()
#6 0x00002b8de8c3330b in THashTable::FindObject(TObject const*) const ()
from /cvmfs/lhcb.cern.ch/lib/lcg/app/releases/ROOT/5.34.03/x86_64-slc5-gcc46-opt/root/lib/libCore.so
#7 0x00002b8de8c36d7f in TMap::GetValue(TObject const*) const () from /cvmfs/lhcb.cern.ch/lib/lcg/app/releases/ROOT/5.34.03/x86_64-slc5-gcc46-opt/root/lib/libCore.so
#8 0x00002b8dedb5fda0 in TFile::SetCacheRead(TFileCacheRead*, TObject*, TFile::ECacheAction) ()
from /cvmfs/lhcb.cern.ch/lib/lcg/app/releases/ROOT/5.34.03/x86_64-slc5-gcc46-opt/root/lib/libRIO.so
#9 0x00002b8df046e106 in TTreeCache::~TTreeCache() () from /cvmfs/lhcb.cern.ch/lib/lcg/app/releases/ROOT/5.34.03/x86_64-slc5-gcc46-opt/root/lib/libTree.so
#10 0x00002b8df046e189 in TTreeCache::~TTreeCache() () from /cvmfs/lhcb.cern.ch/lib/lcg/app/releases/ROOT/5.34.03/x86_64-slc5-gcc46-opt/root/lib/libTree.so
#11 0x00002b8dedb645f6 in TFile::~TFile() () from /cvmfs/lhcb.cern.ch/lib/lcg/app/releases/ROOT/5.34.03/x86_64-slc5-gcc46-opt/root/lib/libRIO.so
#12 0x00002b8dedb648a9 in TFile::~TFile() () from /cvmfs/lhcb.cern.ch/lib/lcg/app/releases/ROOT/5.34.03/x86_64-slc5-gcc46-opt/root/lib/libRIO.so
#13 0x00002b8de8c316e9 in TCollection::GarbageCollect(TObject*) ()
from /cvmfs/lhcb.cern.ch/lib/lcg/app/releases/ROOT/5.34.03/x86_64-slc5-gcc46-opt/root/lib/libCore.so
#14 0x00002b8de8c35215 in TList::Delete(char const*) () from /cvmfs/lhcb.cern.ch/lib/lcg/app/releases/ROOT/5.34.03/x86_64-slc5-gcc46-opt/root/lib/libCore.so
#15 0x00002b8de8becaa7 in TROOT::~TROOT() () from /cvmfs/lhcb.cern.ch/lib/lcg/app/releases/ROOT/5.34.03/x86_64-slc5-gcc46-opt/root/lib/libCore.so
#16 0x0000003b70e337fe in __cxa_finalize () from /lib64/libc.so.6
#17 0x00002b8de8baaaf6 in __do_global_dtors_aux () from /cvmfs/lhcb.cern.ch/lib/lcg/app/releases/ROOT/5.34.03/x86_64-slc5-gcc46-opt/root/lib/libCore.so
#18 0x0000000000000000 in ?? ()
===========================================================

E-mailed: 06/12/2012 19:47

View Properties

Reply

nickve.nl@gmail.com

Hi Philippe,

In case the problem of Chris is related to the one I mentioned in my previous email,

I can tell you that from the history records of my analysis package I saw that I

removed the explicit closing of the file on 05-apr-2011. So very likely the problem

was introduced in the ROOT version that was released around that time.

Cheers,

Nick.

On Thu, Dec 6, 2012 at 7:16 PM, Philippe Canal <pcanal@fnal.gov> wrote:

Hi Chris,

I can reproduce the problem and will look into it.

Cheers,
Philippe.

Show Quoted Messages

E-mailed: 06/12/2012 19:57

View Properties

Reply

Christopher Rob Jones

Hi,

I just tried removing the final Close() on the output ROOT file, and it doesn't help. I still get the seg. fault when reading the file.

cheers Chris

On 6 Dec 2012, at 6:46pm, Nick van Eijndhoven <nickve.nl@gmail.com> wrote:

Hi Philippe,
In case the problem of Chris is related to the one I mentioned in my previous email,
I can tell you that from the history records of my analysis package I saw that I

removed the explicit closing of the file on 05-apr-2011. So very likely the problem
was introduced in the ROOT version that was released around that time.

Cheers,
Nick.

Nick van Eijndhoven
Professor of Physics
Vrije Universiteit Brussel (VUB-ELEM)
Inter-university Institute for High Energies (IIHE)
Pleinlaan 2, B-1050 Brussel, Belgium
===============================================
Office : 0G-122 tel: +32.(0)2.629.3212 gsm: +32.(0)488.074166
Secr. : 1G-006 tel: +32.(0)2.629.3203 fax : +32.(0)2.629.3816
Email : Nick.van.Eijndhoven@vub.ac.be or : nick@icecube.wisc.edu
Web : http://www.iihe.ac.be http://sites.google.com/site/nickveweb
Skype: nickve.nl Gsm-NL: +31.(0)6.40181589

"In the beginning there was nothing, which exploded".

On Thu, Dec 6, 2012 at 7:16 PM, Philippe Canal <pcanal@fnal.gov> wrote:
Hi Chris,

I can reproduce the problem and will look into it.

Cheers,
Philippe.

Show Quoted Messages

E-mailed: 06/12/2012 20:17

View Properties

Reply

pcanal@fnal.gov

Hi,

The problem is fixed in the trunk (by revision 47898) and in the v5.34 patch branch.

To work around the problem you must delete the TTree object before the TFile is closed.

Cheers,
Philippe.

Show Quoted Messages

E-mailed: 06/12/2012 20:24

View Properties

Reply

nickve.nl@gmail.com

Hi Philippe,

Thanks for fixing the problem so quickly.

Question : Was it related to TFile only, or also to TFolder ?

If it was also related to TFolder, then this will probably also fix the

problem I encountered a while ago.

Cheers,

Nick.

On Thu, Dec 6, 2012 at 8:17 PM, Philippe Canal <pcanal@fnal.gov> wrote:

Hi,

The problem is fixed in the trunk (by revision 47898) and in the v5.34 patch branch.

To work around the problem you must delete the TTree object before the TFile is closed.

Cheers,
Philippe.

Show Quoted Messages

E-mailed: 06/12/2012 20:26

View Properties

Reply

pcanal@fnal.gov

Hi Nick,

It is only related to TTree being stored in a subdirectory (and to some new code that has been
recently added to the TTree destructor ; i.e. it is a new-ish bug).

Cheers,
Philippe.

Show Quoted Messages

E-mailed: 06/12/2012 20:43

View Properties

Reply

Christopher Rob Jones

Hi,

Thanks for the fast feedback, but I'm afraid your work round does not work for me.

If I insert

delete newTree;

between lines 86 and 87 in

<https://svnweb.cern.ch/trac/lhcb/browser/Erasmus/trunk/Phys/B2D0hD2KsPiPiDalitz/src/applications/FilterNTuple/FilterNTuple_main.cpp>

then it makes no difference, I still get the seg. fault when reading the output file.

If Instead I use

newTree->Delete();

( which do you mean ?) I get a seg. fault whilst writing the file. See below.

Have I miss understood what you said to do ?

cheers Chris

Writing to output file 'out.root'

*** Break *** segmentation violation

===========================================================

There was a crash.

This is the entire stack trace of all threads:

===========================================================

Thread 1 (process 15498):

#0 0x00007fff8c5026ac in wait4 ()

#1 0x00007fff82df103a in system ()

#2 0x0000000104c0d40f in TUnixSystem::StackTrace ()

#3 0x0000000104c0b267 in TUnixSystem::DispatchSignals ()

#4 <signal handler called>

#5 0x00000001069a8e4d in TTree::CopyAddresses ()

#6 0x00000001069a3d0e in TTree::~TTree ()

#7 0x00000001069a3adf in TTree::~TTree ()

#8 0x0000000104bc16c4 in TCollection::GarbageCollect ()

#9 0x0000000104bc2f30 in THashList::Delete ()

#10 0x0000000104b4f021 in TDirectory::~TDirectory ()

#11 0x0000000105b1ad8f in TDirectoryFile::~TDirectoryFile ()

#12 0x0000000104bc16c4 in TCollection::GarbageCollect ()

#13 0x0000000104bc2f30 in THashList::Delete ()

#14 0x0000000105b1bce4 in TDirectoryFile::Close ()

#15 0x0000000105b27012 in TFile::Close ()

#16 0x0000000105b25893 in TFile::~TFile ()

#17 0x0000000105b2582f in TFile::~TFile ()

#18 0x0000000104bc16c4 in TCollection::GarbageCollect ()

#19 0x0000000104bc4f4d in TList::Delete ()

#20 0x0000000104b7917e in TROOT::~TROOT ()

#21 0x00007fff82dad307 in __cxa_finalize ()

#22 0x00007fff82daef57 in exit ()

#23 0x00007fff89a927e8 in start ()

===========================================================

The lines below might hint at the cause of the crash.

If they do not help you then please submit a bug report at

http://root.cern.ch/bugs. Please post the ENTIRE stack trace

from above as an attachment in addition to anything else

that might help us fixing this issue.

===========================================================

#5 0x00000001069a8e4d in TTree::CopyAddresses ()

#6 0x00000001069a3d0e in TTree::~TTree ()

#7 0x00000001069a3adf in TTree::~TTree ()

#8 0x0000000104bc16c4 in TCollection::GarbageCollect ()

#9 0x0000000104bc2f30 in THashList::Delete ()

#10 0x0000000104b4f021 in TDirectory::~TDirectory ()

#11 0x0000000105b1ad8f in TDirectoryFile::~TDirectoryFile ()

#12 0x0000000104bc16c4 in TCollection::GarbageCollect ()

#13 0x0000000104bc2f30 in THashList::Delete ()

#14 0x0000000105b1bce4 in TDirectoryFile::Close ()

#15 0x0000000105b27012 in TFile::Close ()

#16 0x0000000105b25893 in TFile::~TFile ()

#17 0x0000000105b2582f in TFile::~TFile ()

#18 0x0000000104bc16c4 in TCollection::GarbageCollect ()

#19 0x0000000104bc4f4d in TList::Delete ()

#20 0x0000000104b7917e in TROOT::~TROOT ()

#21 0x00007fff82dad307 in __cxa_finalize ()

#22 0x00007fff82daef57 in exit ()

#23 0x00007fff89a927e8 in start ()

===========================================================

Chris-Jones-Macbook-Pro ~/LHCb/B2D0hD2KsPiPiDalitz/scripts >

On 6 Dec 2012, at 7:25pm, Philippe Canal <pcanal@fnal.gov> wrote:

Hi Nick,

It is only related to TTree being stored in a subdirectory (and to some new code that has been
recently added to the TTree destructor ; i.e. it is a new-ish bug).

Cheers,
Philippe.

Show Quoted Messages

E-mailed: 06/12/2012 20:52

View Properties

Reply

nickve.nl@gmail.com

Hi Chris,

If the bug is related to what I think, just try

delete newTree;

newTree=0;

and see if that works.

If it does, it is related to multiple deletes of objects in a TCollection.

Cheers,

Nick.

On Thu, Dec 6, 2012 at 8:42 PM, Chris Jones <jonesc@hep.phy.cam.ac.uk> wrote:

Hi,

Thanks for the fast feedback, but I'm afraid your work round does not work for me.

If I insert

delete newTree;

between lines 86 and 87 in

<https://svnweb.cern.ch/trac/lhcb/browser/Erasmus/trunk/Phys/B2D0hD2KsPiPiDalitz/src/applications/FilterNTuple/FilterNTuple_main.cpp>

then it makes no difference, I still get the seg. fault when reading the output file.

If Instead I use

newTree->Delete();

( which do you mean ?) I get a seg. fault whilst writing the file. See below.

Have I miss understood what you said to do ?

cheers Chris

Writing to output file 'out.root'

*** Break *** segmentation violation

===========================================================
There was a crash.
This is the entire stack trace of all threads:
===========================================================

Thread 1 (process 15498):
#0 0x00007fff8c5026ac in wait4 ()
#1 0x00007fff82df103a in system ()
#2 0x0000000104c0d40f in TUnixSystem::StackTrace ()
#3 0x0000000104c0b267 in TUnixSystem::DispatchSignals ()

#4 <signal handler called>
#5 0x00000001069a8e4d in TTree::CopyAddresses ()
#6 0x00000001069a3d0e in TTree::~TTree ()
#7 0x00000001069a3adf in TTree::~TTree ()
#8 0x0000000104bc16c4 in TCollection::GarbageCollect ()

#9 0x0000000104bc2f30 in THashList::Delete ()
#10 0x0000000104b4f021 in TDirectory::~TDirectory ()
#11 0x0000000105b1ad8f in TDirectoryFile::~TDirectoryFile ()
#12 0x0000000104bc16c4 in TCollection::GarbageCollect ()

#13 0x0000000104bc2f30 in THashList::Delete ()
#14 0x0000000105b1bce4 in TDirectoryFile::Close ()
#15 0x0000000105b27012 in TFile::Close ()
#16 0x0000000105b25893 in TFile::~TFile ()

#17 0x0000000105b2582f in TFile::~TFile ()
#18 0x0000000104bc16c4 in TCollection::GarbageCollect ()
#19 0x0000000104bc4f4d in TList::Delete ()
#20 0x0000000104b7917e in TROOT::~TROOT ()

#21 0x00007fff82dad307 in __cxa_finalize ()
#22 0x00007fff82daef57 in exit ()
#23 0x00007fff89a927e8 in start ()
===========================================================

The lines below might hint at the cause of the crash.
If they do not help you then please submit a bug report at
http://root.cern.ch/bugs. Please post the ENTIRE stack trace

from above as an attachment in addition to anything else
that might help us fixing this issue.
===========================================================
#5 0x00000001069a8e4d in TTree::CopyAddresses ()

#6 0x00000001069a3d0e in TTree::~TTree ()
#7 0x00000001069a3adf in TTree::~TTree ()
#8 0x0000000104bc16c4 in TCollection::GarbageCollect ()
#9 0x0000000104bc2f30 in THashList::Delete ()

#10 0x0000000104b4f021 in TDirectory::~TDirectory ()
#11 0x0000000105b1ad8f in TDirectoryFile::~TDirectoryFile ()
#12 0x0000000104bc16c4 in TCollection::GarbageCollect ()
#13 0x0000000104bc2f30 in THashList::Delete ()

#14 0x0000000105b1bce4 in TDirectoryFile::Close ()
#15 0x0000000105b27012 in TFile::Close ()
#16 0x0000000105b25893 in TFile::~TFile ()
#17 0x0000000105b2582f in TFile::~TFile ()
#18 0x0000000104bc16c4 in TCollection::GarbageCollect ()
#19 0x0000000104bc4f4d in TList::Delete ()
#20 0x0000000104b7917e in TROOT::~TROOT ()
#21 0x00007fff82dad307 in __cxa_finalize ()

#22 0x00007fff82daef57 in exit ()
#23 0x00007fff89a927e8 in start ()
===========================================================

Chris-Jones-Macbook-Pro ~/LHCb/B2D0hD2KsPiPiDalitz/scripts >

On 6 Dec 2012, at 7:25pm, Philippe Canal <pcanal@fnal.gov> wrote:

Hi Nick,

It is only related to TTree being stored in a subdirectory (and to some new code that has been
recently added to the TTree destructor ; i.e. it is a new-ish bug).

Cheers,
Philippe.

Show Quoted Messages

E-mailed: 06/12/2012 20:59

View Properties

Reply

Christopher Rob Jones

Hi,

That does not help. I still get a seg. fault when reading the file.

cheers Chris

On 6 Dec 2012, at 7:51pm, Nick van Eijndhoven <nickve.nl@gmail.com> wrote:

Hi Chris,
If the bug is related to what I think, just try

delete newTree;

newTree=0;

and see if that works.
If it does, it is related to multiple deletes of objects in a TCollection.

Cheers,
Nick.

Nick van Eijndhoven
Professor of Physics
Vrije Universiteit Brussel (VUB-ELEM)
Inter-university Institute for High Energies (IIHE)
Pleinlaan 2, B-1050 Brussel, Belgium
===============================================
Office : 0G-122 tel: +32.(0)2.629.3212 gsm: +32.(0)488.074166
Secr. : 1G-006 tel: +32.(0)2.629.3203 fax : +32.(0)2.629.3816
Email : Nick.van.Eijndhoven@vub.ac.be or : nick@icecube.wisc.edu
Web : http://www.iihe.ac.be http://sites.google.com/site/nickveweb
Skype: nickve.nl Gsm-NL: +31.(0)6.40181589

"In the beginning there was nothing, which exploded".

On Thu, Dec 6, 2012 at 8:42 PM, Chris Jones <jonesc@hep.phy.cam.ac.uk> wrote:

Hi,

Thanks for the fast feedback, but I'm afraid your work round does not work for me.

If I insert

delete newTree;

between lines 86 and 87 in

<https://svnweb.cern.ch/trac/lhcb/browser/Erasmus/trunk/Phys/B2D0hD2KsPiPiDalitz/src/applications/FilterNTuple/FilterNTuple_main.cpp>

then it makes no difference, I still get the seg. fault when reading the output file.

If Instead I use

newTree->Delete();

( which do you mean ?) I get a seg. fault whilst writing the file. See below.

Have I miss understood what you said to do ?

cheers Chris

Writing to output file 'out.root'

*** Break *** segmentation violation

===========================================================
There was a crash.
This is the entire stack trace of all threads:
===========================================================

Thread 1 (process 15498):
#0 0x00007fff8c5026ac in wait4 ()
#1 0x00007fff82df103a in system ()
#2 0x0000000104c0d40f in TUnixSystem::StackTrace ()
#3 0x0000000104c0b267 in TUnixSystem::DispatchSignals ()

#4 <signal handler called>
#5 0x00000001069a8e4d in TTree::CopyAddresses ()
#6 0x00000001069a3d0e in TTree::~TTree ()
#7 0x00000001069a3adf in TTree::~TTree ()
#8 0x0000000104bc16c4 in TCollection::GarbageCollect ()

#9 0x0000000104bc2f30 in THashList::Delete ()
#10 0x0000000104b4f021 in TDirectory::~TDirectory ()
#11 0x0000000105b1ad8f in TDirectoryFile::~TDirectoryFile ()
#12 0x0000000104bc16c4 in TCollection::GarbageCollect ()

#13 0x0000000104bc2f30 in THashList::Delete ()
#14 0x0000000105b1bce4 in TDirectoryFile::Close ()
#15 0x0000000105b27012 in TFile::Close ()
#16 0x0000000105b25893 in TFile::~TFile ()

#17 0x0000000105b2582f in TFile::~TFile ()
#18 0x0000000104bc16c4 in TCollection::GarbageCollect ()
#19 0x0000000104bc4f4d in TList::Delete ()
#20 0x0000000104b7917e in TROOT::~TROOT ()

#21 0x00007fff82dad307 in __cxa_finalize ()
#22 0x00007fff82daef57 in exit ()
#23 0x00007fff89a927e8 in start ()
===========================================================

The lines below might hint at the cause of the crash.
If they do not help you then please submit a bug report at
http://root.cern.ch/bugs. Please post the ENTIRE stack trace

from above as an attachment in addition to anything else
that might help us fixing this issue.
===========================================================
#5 0x00000001069a8e4d in TTree::CopyAddresses ()

#6 0x00000001069a3d0e in TTree::~TTree ()
#7 0x00000001069a3adf in TTree::~TTree ()
#8 0x0000000104bc16c4 in TCollection::GarbageCollect ()
#9 0x0000000104bc2f30 in THashList::Delete ()

#10 0x0000000104b4f021 in TDirectory::~TDirectory ()
#11 0x0000000105b1ad8f in TDirectoryFile::~TDirectoryFile ()
#12 0x0000000104bc16c4 in TCollection::GarbageCollect ()
#13 0x0000000104bc2f30 in THashList::Delete ()

#14 0x0000000105b1bce4 in TDirectoryFile::Close ()
#15 0x0000000105b27012 in TFile::Close ()
#16 0x0000000105b25893 in TFile::~TFile ()
#17 0x0000000105b2582f in TFile::~TFile ()
#18 0x0000000104bc16c4 in TCollection::GarbageCollect ()
#19 0x0000000104bc4f4d in TList::Delete ()
#20 0x0000000104b7917e in TROOT::~TROOT ()
#21 0x00007fff82dad307 in __cxa_finalize ()

#22 0x00007fff82daef57 in exit ()
#23 0x00007fff89a927e8 in start ()
===========================================================

Chris-Jones-Macbook-Pro ~/LHCb/B2D0hD2KsPiPiDalitz/scripts >

On 6 Dec 2012, at 7:25pm, Philippe Canal <pcanal@fnal.gov> wrote:

Hi Nick,

It is only related to TTree being stored in a subdirectory (and to some new code that has been
recently added to the TTree destructor ; i.e. it is a new-ish bug).

Cheers,
Philippe.

Show Quoted Messages

E-mailed: 06/12/2012 21:06

View Properties

Reply

nickve.nl@gmail.com

Okido, then I give up and leave it to our ROOT experts.

Cheers,

Nick.

On Thu, Dec 6, 2012 at 8:57 PM, Chris Jones <jonesc@hep.phy.cam.ac.uk> wrote:

Hi,

That does not help. I still get a seg. fault when reading the file.

cheers Chris

On 6 Dec 2012, at 7:51pm, Nick van Eijndhoven <nickve.nl@gmail.com> wrote:

Hi Chris,
If the bug is related to what I think, just try

delete newTree;

newTree=0;

and see if that works.
If it does, it is related to multiple deletes of objects in a TCollection.

Cheers,
Nick.

Nick van Eijndhoven
Professor of Physics
Vrije Universiteit Brussel (VUB-ELEM)
Inter-university Institute for High Energies (IIHE)
Pleinlaan 2, B-1050 Brussel, Belgium
===============================================
Office : 0G-122 tel: +32.(0)2.629.3212 gsm: +32.(0)488.074166
Secr. : 1G-006 tel: +32.(0)2.629.3203 fax : +32.(0)2.629.3816
Email : Nick.van.Eijndhoven@vub.ac.be or : nick@icecube.wisc.edu
Web : http://www.iihe.ac.be http://sites.google.com/site/nickveweb
Skype: nickve.nl Gsm-NL: +31.(0)6.40181589

"In the beginning there was nothing, which exploded".

On Thu, Dec 6, 2012 at 8:42 PM, Chris Jones <jonesc@hep.phy.cam.ac.uk> wrote:

Hi,

Thanks for the fast feedback, but I'm afraid your work round does not work for me.

If I insert

delete newTree;

between lines 86 and 87 in

<https://svnweb.cern.ch/trac/lhcb/browser/Erasmus/trunk/Phys/B2D0hD2KsPiPiDalitz/src/applications/FilterNTuple/FilterNTuple_main.cpp>

then it makes no difference, I still get the seg. fault when reading the output file.

If Instead I use

newTree->Delete();

( which do you mean ?) I get a seg. fault whilst writing the file. See below.

Have I miss understood what you said to do ?

cheers Chris

Writing to output file 'out.root'

*** Break *** segmentation violation

===========================================================
There was a crash.
This is the entire stack trace of all threads:
===========================================================

Thread 1 (process 15498):
#0 0x00007fff8c5026ac in wait4 ()
#1 0x00007fff82df103a in system ()
#2 0x0000000104c0d40f in TUnixSystem::StackTrace ()
#3 0x0000000104c0b267 in TUnixSystem::DispatchSignals ()

#4 <signal handler called>
#5 0x00000001069a8e4d in TTree::CopyAddresses ()
#6 0x00000001069a3d0e in TTree::~TTree ()
#7 0x00000001069a3adf in TTree::~TTree ()
#8 0x0000000104bc16c4 in TCollection::GarbageCollect ()

#9 0x0000000104bc2f30 in THashList::Delete ()
#10 0x0000000104b4f021 in TDirectory::~TDirectory ()
#11 0x0000000105b1ad8f in TDirectoryFile::~TDirectoryFile ()
#12 0x0000000104bc16c4 in TCollection::GarbageCollect ()

#13 0x0000000104bc2f30 in THashList::Delete ()
#14 0x0000000105b1bce4 in TDirectoryFile::Close ()
#15 0x0000000105b27012 in TFile::Close ()
#16 0x0000000105b25893 in TFile::~TFile ()

#17 0x0000000105b2582f in TFile::~TFile ()
#18 0x0000000104bc16c4 in TCollection::GarbageCollect ()
#19 0x0000000104bc4f4d in TList::Delete ()
#20 0x0000000104b7917e in TROOT::~TROOT ()

#21 0x00007fff82dad307 in __cxa_finalize ()
#22 0x00007fff82daef57 in exit ()
#23 0x00007fff89a927e8 in start ()
===========================================================

The lines below might hint at the cause of the crash.
If they do not help you then please submit a bug report at
http://root.cern.ch/bugs. Please post the ENTIRE stack trace

from above as an attachment in addition to anything else
that might help us fixing this issue.
===========================================================
#5 0x00000001069a8e4d in TTree::CopyAddresses ()

#6 0x00000001069a3d0e in TTree::~TTree ()
#7 0x00000001069a3adf in TTree::~TTree ()
#8 0x0000000104bc16c4 in TCollection::GarbageCollect ()
#9 0x0000000104bc2f30 in THashList::Delete ()

#10 0x0000000104b4f021 in TDirectory::~TDirectory ()
#11 0x0000000105b1ad8f in TDirectoryFile::~TDirectoryFile ()
#12 0x0000000104bc16c4 in TCollection::GarbageCollect ()
#13 0x0000000104bc2f30 in THashList::Delete ()

#14 0x0000000105b1bce4 in TDirectoryFile::Close ()
#15 0x0000000105b27012 in TFile::Close ()
#16 0x0000000105b25893 in TFile::~TFile ()
#17 0x0000000105b2582f in TFile::~TFile ()
#18 0x0000000104bc16c4 in TCollection::GarbageCollect ()
#19 0x0000000104bc4f4d in TList::Delete ()
#20 0x0000000104b7917e in TROOT::~TROOT ()
#21 0x00007fff82dad307 in __cxa_finalize ()

#22 0x00007fff82daef57 in exit ()
#23 0x00007fff89a927e8 in start ()
===========================================================

Chris-Jones-Macbook-Pro ~/LHCb/B2D0hD2KsPiPiDalitz/scripts >

On 6 Dec 2012, at 7:25pm, Philippe Canal <pcanal@fnal.gov> wrote:

Hi Nick,

It is only related to TTree being stored in a subdirectory (and to some new code that has been
recently added to the TTree destructor ; i.e. it is a new-ish bug).

Cheers,
Philippe.

Show Quoted Messages

roottalk

ArchiveSeg.fault when quitting ROOT v5.34.00 Flat

Top Link Bar

Quick Launch