Luca SCOTTO LAVINA | 29 May 19:25 2015

PROOF and aliases

Dear ROOT developers,
our Collaboration XENON uses, and plans to use for its new detector,
ROOT as analysis framework. Our data format is quite simple (just a
TTree where each entry is a triggered event; the total number of
branches is < 100) but with billions of entries that we organise in
separate ROOT files. We use TChain to merge them and to make plots. Our
analysis uses complex cuts based on the values of these branches. For
this reason, we massively use TChain to merge files and aliases
(T->SetAlias(...)) to better handle complex TCut's.
We could benefit really a lot in our analyses of parallel processing
provided by PROOF-Lite, but unfortunately I see, from previous roottalk
threads, that the use of aliases is still not supported. In what seems
to me the most recent thread (on 2013) it was written that people were
working on it but since then I did not have any news.
May I know if this feature will be added in ROOT in near future? What is
the timescale?
The presence of this feature could really make a big difference in our


Attachment (Luca_Scotto-Lavina.vcf): text/x-vcard, 504 bytes
Tom Roberts | 29 May 17:25 2015

Windows woes

I am trying to build G4beamline on Windows 7; its only use of Root is to read 
and write TNtuples in TFiles. It builds just fine on Mac and Linux.

I am trying to do a 64-bit build. No Windows 64-bit binary is available for 
download, so I downloaded the source root_v5.34.30.source.tar.gz. I used CMake 
3.2.1 to prepare a VC++ project, using generator "Visual Studio 12 2013 Win64" 
(it had problems, but seemed to finish OK); I kept all the default selections, 
changing only the install prefix and binary destination. I then used Microsoft 
Visual Studio 2013 to open the resulting Root.sln file, and built ALL_BUILD.

This solution has lots of projects; 79 succeeded and 115 failed. Something is 
terribly wrong.

A common error is: error MSB6006: "cmd.exe" exited with code 9009.

Another error is:C:\Program Files (x86)\Windows 
Kits\8.1\Include\um\winnt.h(17792): error C3861: '__stosb': identifier not found 
(lots more variables are missing),

How does one build Root on Windows?
Is a 64-bit build just not possible?

Tom Roberts

SIZUN Patrick | 29 May 10:57 2015

JetEvent and TTree::Draw


Given a TTree of JetEvent objects such as the one created by the jets.C tutorial,
can TTree::Draw be used to create a histogram of, say, the fPx momentum of all tracks from jets with fPt > 20 ?

T->Draw("fPx", "fPt > 20") selects a single track per matching jet

Is the only solution to loop  manually over tree entries and each entry's array of jets?


Suvayu Ali | 28 May 22:32 2015

Undelivered mail bounces


Could someone please take care of the ridiculous undelivered mail
bounces?  It has been a problem for ages now (I think since the list
moved from majordomo to egroups).  So far the count is 6, but from what
I recall there might be a few more.

  jericha <at>
  vipscorpio <at>
  nethuad <at>
  mundim <at>
  mwlee <at>
  dark93 <at>




Open source is the future. It sets us free.

Joosep Pata | 27 May 23:29 2015

TTree Draw can corrupt memory and lead to random segfaults

Dear root devs,

The following C++ snippet [1] illustrates how a reasonable program using a TTree can corrupt memory and
lead to random segfaults in ROOT. This can happen when one first does a manual loop over the TTree using
SetBranchAddress and later does TTree::Draw.

I would like to ask the devs if this is the intended behaviour as I could find no reference in the
documentation that a loop with manual branch variables followed by a TTree::Draw does not lead to valid
memory usage and thus a valid program.
My other question is: if the branch address points to unallocated memory, how can TTree::Draw even produce
reasonable results at all? I would expect that it should give an error rather than produce results and
later segfault...

This may not be a problem in C++, where the user always knows and understands perfectly what they are doing
with the memory, but it is a problem in PyROOT, where memory is handled by the python gc. The python snippet
[2] illustrates the problem. It is a distilled version of a real analysis code that was randomly crashing.

Best regards,

[1] C++ code to reproduce the error
> #include <TFile.h>
> #include <TTree.h>
> #include <TH1F.h>
> #include <iostream>
> void corrupt(TTree* tree) {
>     double* br = new double(0.0);
>     tree->SetBranchAddress("b", br);
(Continue reading)

Knut Kiesel | 27 May 15:12 2015

Looping over empty TTreeReaderArrays bug


I modified CountEventSelector.C[2] from the tutorial[1], adding a 
TTreeReaderArray arr. In the 'Process' function, I loop over this array, 
for( int i=0; i<arr.GetSize(); i++ ) cout << arr[i] ; // works perfectly
for( auto a = arr.begin(); a != arr.end(); ++a ) cout << a; // chashes 
only if the length is 0.

I'm using ROOT 6.02/05 

You can find the modified script at [3] or in the attachments.

Should I report a bug or is this something obvious?


// This class is derived from the ROOT class TSelector. 
// For more information on the TSelector framework see 

// The file for this selector can be found at
(Continue reading)

Brett Viren | 26 May 17:35 2015

PyROOT and TTreeReader and POD


I'm curious about an apparent asymmetry in how POD and STL objects are
handled when using TTreeReader via PyROOT.

I'm working with ROOT 6.02/05 on Ubuntu, Python 2.7.9.

I have some test code and data here:

The Python script there will read the test.root file "live" from that
HTTP location.

Here is a session showing how I ran that test and its output:

<class 'ROOT.TTreeReaderValue<vector<int> >'>
<ROOT.TTreeReaderValue<vector<int> > object at 0x33bf5d0>
<class 'ROOT.TTreeReaderValue<int>'>
<ROOT.TTreeReaderValue<int> object at 0x3349a40>
Traceback (most recent call last):
  File "", line 26, in <module>
  File "", line 22, in test_reader_pod
    assert siz == 9180

(Continue reading)

Christian Bourjau | 20 May 16:56 2015

Inheriting from TObject

Dear experts,

I have been trying to write a class inheriting from TObject, but have
been getting errors about members of TObject being inaccessible when
loading my class with gROOT->LoadMacro("mylib.cxx++g") in root
I created a minimum (non) working example and am really puzzled whats
missing (also attached as files):

#include "mylib.h"
: TObject()

#ifndef mylib_cxx
#define mylib_cxx

#include "TObject.h"

class Mylib : TObject {
  virtual ~Mylib() {}
  Mylib(const Mylib&);
  Mylib& operator=(const Mylib&);
(Continue reading)

John Idarraga | 19 May 10:17 2015


Dear ROOT community,

     Where could I read about the efforts done within ROOT6 to make the 
design thread-safe.  And the long term plans in that direction. I am 
looking at it from the perspective of the developer who uses the ROOT 
framework as a library in third party applications.



Tom Roberts | 18 May 18:19 2015

Bothersome error message

I link my G4beamline program with Root libraries. On Linux, when the program starts up, Root emits this error message:
Error: cannot open file "iostream"  (tmpfile):2:
*** Interpreter error recovered ***

This is recent, and earlier versions did not do this. Moreover, this does not happen on Mac OS X (I haven't yet gotten to Windows....).

  • Linux is SLF 5.5 (64 bit) / gcc version 4.1.2 20080704 (Red Hat 4.1.2-50)
  • Root root_v5.34.30
  • ROOTSYS points to the root (binary) installation
  • The Root libs are linked: -lTree -lCore -lCint -lRIO; when executed, .so-s for MathCore, Net, and Thread are also used.
  • This error message also happens when I copy the binary to a bare installation of SLF 6.3, and run it with ROOTSYS unset (the way my users normally run it)
The error message is emitted very early, before any of my global initializers run, so I believe it is emitted when some Root .so is linked and initialized.

Note the program runs fine, including reading and writing TNtuple-s in TFile-s (the only part of Root it uses).

This bogus message is bothersome -- how can I get rid of it? I dislike having to tell my users to ignore a scary-looking error message.

Tom Roberts
Joosep Pata | 18 May 15:49 2015

Tool to save time writing TTree commands

Dear collaborators,

I’m announcing a small tool called headergen which helps you to generate useful C++ header files for flat ROOT TTrees. The premise is that writing “lepton_pt, eta, phi” etc branches by hand in multiple places in every code file can be error prone.

Now you can write once what kind of branches you want and the tool will generate for you a small standalone .h file which you can include to always have the up-to-date version of the tree format.

It’s kind of like TTree::MakeClass, but on steroids.

I hope it will save some of you some time in debugging lines like
tree->Branch("lep__eta", lep__eta, "lep__eta[n__lep]/F);
tree->SetBranchAddress("lep__eta", lep__eta);

Here is the code.

Hope it saves some time for physics.

Joosep Pata