Severe problem with tree->DropBaskets() in root_v5.26/00

Dear ROOTers,

Some time ago I made quite an effort to optimize tree memory managment when handling 25000 trees, and with the kind help
from Philippe I was finally able to achieve this goal, see:
root.cern.ch/phpBB2/viewtopic.ph … a01c03ed42
The main suggestion was to use “tree->DropBaskets()”, which resulted in a dramatical improvement.

This works perfectly fine with root_v5.24/00 but causes severe problems with root_v5.26/00 as the following example shows:

Int_t XGCProcesSet::DoMultichipExpress(Int_t numdata, TTree **datatree)
{
   idx = 0;
   for (Int_t i=0; i<size; i++) {
      datatree[0]->GetEntry(i);

      ij = XY2Index(gccell[0]->GetX(), gccell[0]->GetY(), numcols);

      if (arrMask[ij] == 1) {
         arrIndx[ij] = idx++;
      }//if
   }//for_i
   datatree[0]->DropBaskets();   //<==== PROBLEM

// some code

   for (Int_t k=0; k<numdata; k++) {
      idx = 0;
      for (Int_t i=0; i<size; i++) {
         datatree[k]->GetEntry(i);

         if (arrMask[i] == 1) {
            table[k][idx++] = gccell[k]->GetIntensity();
if(i>2000 && i<2020)cout << "k= " << k << " i= " << i  << " x= " << gccell[k]->GetX() << " y= " << gccell[k]->GetY() <<  "  inten= " << gccell[k]->GetIntensity() << endl;
         }//if
      }//for_i
   }//for_k

// some code
}

With this code I get the following strange output:

k= 0 i= 2001 x= 125 y= 125  inten= 1142.3
k= 0 i= 2002 x= 125 y= 125  inten= 1142.3
k= 0 i= 2003 x= 125 y= 125  inten= 1142.3
k= 0 i= 2004 x= 125 y= 125  inten= 1142.3
k= 0 i= 2005 x= 125 y= 125  inten= 1142.3
k= 0 i= 2006 x= 125 y= 125  inten= 1142.3
k= 0 i= 2007 x= 125 y= 125  inten= 1142.3
k= 0 i= 2008 x= 125 y= 125  inten= 1142.3
k= 0 i= 2009 x= 125 y= 125  inten= 1142.3
k= 0 i= 2010 x= 125 y= 125  inten= 1142.3
k= 0 i= 2011 x= 125 y= 125  inten= 1142.3
k= 0 i= 2012 x= 125 y= 125  inten= 1142.3
k= 0 i= 2013 x= 125 y= 125  inten= 1142.3
k= 0 i= 2014 x= 125 y= 125  inten= 1142.3
k= 1 i= 2001 x= 111 y= 15  inten= 697.8
k= 1 i= 2002 x= 112 y= 15  inten= 840.3
k= 1 i= 2003 x= 113 y= 15  inten= 867.8
etc

However, when I delete the line “datatree[0]->DropBaskets()” I get the correct output:

k= 0 i= 2001 x= 111 y= 15  inten= 704.3
k= 0 i= 2002 x= 112 y= 15  inten= 852.3
k= 0 i= 2003 x= 113 y= 15  inten= 908.8
k= 0 i= 2004 x= 114 y= 15  inten= 721.5
k= 0 i= 2005 x= 115 y= 15  inten= 3913.3
k= 0 i= 2006 x= 116 y= 15  inten= 1804.8
k= 0 i= 2007 x= 117 y= 15  inten= 798.9
k= 0 i= 2008 x= 118 y= 15  inten= 776.1
k= 0 i= 2009 x= 119 y= 15  inten= 1370.1
k= 0 i= 2010 x= 120 y= 15  inten= 765.4
k= 0 i= 2011 x= 121 y= 15  inten= 1027.1
k= 0 i= 2012 x= 122 y= 15  inten= 983.9
k= 0 i= 2013 x= 123 y= 15  inten= 837.1
k= 0 i= 2014 x= 124 y= 15  inten= 737.1
k= 1 i= 2001 x= 111 y= 15  inten= 697.8
k= 1 i= 2002 x= 112 y= 15  inten= 840.3
k= 1 i= 2003 x= 113 y= 15  inten= 867.8
etc

This is only an example. In every function where I use tree->DropBaskets(), I get similar problems.

Can you tell me why tree->DropBaskets() does no longer work in root_v5.26/00?

BTW, the link “http://root.cern.ch/files/brun_lcgapp09.pdf” seems to be broken.

Best regards
Christian

Christian,

several remarks;
-1: do not expect an answer from Philippe soon. He (rather his wife : is expecting a baby today.

-2: I do not see why calling Dropbaskets can help if you call this function
only for the first Tree.

-3: Calling DropBaskets the way you show in your code snippet is time consuming noop
since after having dropped the baskets, you are going to load them again in the following loop.

-4: Your ouput is symptomatic of an array overflow on your side, but it is difficult
to tell you more without being able to run the actual code.

-5: I did not follow your original postings. However reading your code snippet:
it is clear that having 25000 trees in parallel is the clear sign of a wrong object model.
What you do is not only innefficient memory-wise but also time-wise. You should opt
for a solution with only ONE Tree where each top branch will hold the current top branch
of each of your 25000 Trees.

Rene

I am just learning now that Philippe had a baby yesterday and his name is “Christian” :

Rene

Dear Rene,

Thank you for your remarks:

ad 1,
First, let me congratulate Philippe and his wife to the birth of their son, especially since I am now the namesake of
his son. Dear Philippe: Congratulations, I wish your son a long and happy life in a peaceful world.

ad 2,
I call DropBasket() after looping over the first tree only. It is probably not a good example but it shows how calling
DropBasket() for the first tree causes the next for-loop not to work any longer for the first tree only, whereas it works
for the remaining trees. Only after deleting DropBasket() does the second for-loop work correctly again with root_v5.26/00!

ad 3,
Maybe, in this case it is really not necessary to call DropBasket(), but (as I mentioned above) it definitely shows the
problem with root_v5.26/00. Here are two more typical functions where I use DropBasket():

Int_t XGCProcesSet::FillDataArrays(TTree *datatree, Int_t nrow, Int_t ncol, Double_t *inten, Double_t *stdev, Int_t *npix)
{
// Init datatree
   XGCCell *gccell = 0;
   datatree->SetBranchAddress("DataBranch", &gccell);

// Get data from datatree and store in arrays
   Int_t size = datatree->GetEntries();
   Int_t x, y, ij;
   for (Int_t i=0; i<size; i++) {
      datatree->GetEntry(i);

      x  = gccell->GetX();
      y  = gccell->GetY();
      ij = XY2Index(x, y, ncol);

      if (inten) inten[ij] = gccell->GetIntensity();
      if (stdev) stdev[ij] = gccell->GetStdev();
      if (npix)  npix[ij]  = gccell->GetNumPixels();
   }//for_i

   SafeDelete(gccell);
   datatree->DropBaskets(); 
   datatree->ResetBranchAddress(datatree->GetBranch("DataBranch"));

   return errNoErr;
}//FillDataArrays


TTree *XGCProcesSet::FillDataTree(TTree *oldtree, const char *exten, XAlgorithm *algorithm, Int_t nrow, Int_t ncol,
                     Double_t *inten, Double_t *stdev)
{
   if (oldtree == 0) return 0;

   Int_t size = nrow*ncol;

// Init branch address for oldtree
   XGCCell *oldcell = 0;
   oldtree->SetBranchAddress("DataBranch", &oldcell);

// Create tree newtree
   TString name = Path2Name(oldtree->GetName(),"",".");
   name = name + "." + exten;
   TTree *newtree = new TTree(name, fSchemeName.Data());
   if (newtree == 0) return 0;

   XGCCell *newcell = new XGCCell();
   Int_t    bufsize = XManager::GetBufSize();
   Int_t    split   = 99;
   newtree->Branch("DataBranch", "XGCCell", &newcell, bufsize, split);

   Int_t x, y, ij;
   for (Int_t i=0; i<size; i++) {
      oldtree->GetEntry(i);

      x  = oldcell->GetX();
      y  = oldcell->GetY();
      ij = XY2Index(x, y, ncol);

      newcell->SetX(x);
      newcell->SetY(y);
      newcell->SetIntensity(inten[ij]);
      newcell->SetStdev((stdev == 0) ? oldcell->GetStdev() : stdev[ij]);
      newcell->SetNumPixels((Short_t)numpix);

      newtree->Fill();
   }//for_i

// Write expression tree to file 
   if (WriteTree(newtree, TObject::kOverwrite) == errNoErr) {
   // Delete tree header in case of overwrite
      XTreeHeader *header = GetTreeHeader(name);
      if (header) {fHeaders->Remove(header); delete header;} 
   }//if

   SafeDelete(newcell);
   newtree->DropBaskets(); 
   newtree->ResetBranchAddress(newtree->GetBranch("DataBranch"));

   SafeDelete(oldcell);
   oldtree->ResetBranchAddress(oldtree->GetBranch("DataBranch"));
   SafeDelete(oldtree);

   return newtree;
}//FillDataTree

These two methods are called by other methods and here DropBasket() helped to reduce memory consumption dramatically,
i.e. memory consumption did not increase over time when calling the parent methods for 25000 trees! The increase in
memory consumption (from <1GB to about 12GB) was reported by a user of my program who sent me a graph showing this
increase during the course of one week. After adding DropBasket() to these methods the user reported that memory
consumption remained stable at about 1-2GB!
However, with root_v5.26/00 I have to delete DropBasket() from these methods otherwise my program no longer works.

ad 4,
I can assure you that there is definitely no array buffer overflow. Not only did I test my code extensively with valgrind,
but it is meanwhile used by so many users that this would have definitely been reported to me. Furthermore, the one user
would not have been able to run my program with 25000 trees.

ad 5,
Using 25000 trees is only an exception, typical uses are 50-100 trees. Nevertheless, I am interested to know what you
mean with “only ONE Tree where each top branch will hold the current top branch of each of your 25000 Trees”. I am
afraid that I do not quite understand what you mean. Maybe an example would help.

Best regards
Christian

Instead of making many trees with one or few branches in each Tree, it is far more economical (and much simpler to manage) to create only one tree.
The total number of branches is identical, but the processing will be much faster in case of one single Tree and you will also gain a substantial fraction of memory.
For examples of trees, see $ROOTSYS/test/MainEvent.cxx or $ROOTSYS/tutorials/tree

Rene

Dear Rene,

I seems that I have misunderstood your last sentence. Replacing all trees with only one tree is another story and currently not possible.
Furthermore, I would need to rewrite substantial parts of my code.

Best regards
Christian

Dear Philippe,

As I have already mentioned, there seems to be a problem with tree->DropBaskets() in root_v5.26/00 and the patch release 5.26/00a.

After a very long testing time where I could often not even reproduce the problem, and after a lot of trial and error, I can finally
reproduce the conditions under which I get the error.

As I have already mentioned, when I keep the line “datatree->DropBaskets();” in method “XGCProcesSet::FillDataArrays()” shown earlier,
I get the following debugging output:

      normalizing data using method <quantile>...
------XGCProcesSet::FillDataArrays------..        
2:i= 2001 x= 111 y= 15  inten= 704.3
2:i= 2002 x= 112 y= 15  inten= 852.3
2:i= 2003 x= 113 y= 15  inten= 908.8
2:i= 2004 x= 114 y= 15  inten= 721.5
2:i= 2005 x= 115 y= 15  inten= 3913.3
2:i= 2006 x= 116 y= 15  inten= 1804.8
2:i= 2007 x= 117 y= 15  inten= 798.9
2:i= 2008 x= 118 y= 15  inten= 776.1
2:i= 2009 x= 119 y= 15  inten= 1370.1
2:i= 2010 x= 120 y= 15  inten= 765.4
2:i= 2011 x= 121 y= 15  inten= 1027.1
2:i= 2012 x= 122 y= 15  inten= 983.9
2:i= 2013 x= 123 y= 15  inten= 837.1
2:i= 2014 x= 124 y= 15  inten= 737.1
2:i= 2015 x= 125 y= 15  inten= 1052
2:i= 2016 x= 0 y= 16  inten= 20181.1
2:i= 2017 x= 1 y= 16  inten= 7760.5
2:i= 2018 x= 2 y= 16  inten= 948.7
2:i= 2019 x= 3 y= 16  inten= 912.6
1:k= 0  *datatree[k]= 0x6316dc0   datatree[k]= TestA1.cel
...
         finished filling <4> arrays.                   
         computing common mean...
2:k= 0  *datatree[k]= 0x6316dc0   datatree[k]= TestA1.cel  
------XGCProcesSet::FillDataTree(newtree)------
*oldtree= 0x6316dc0   oldtree= TestA1.cel
*newtree= 0x635ca70   newtree= TestA1.cqu
i= 2001 x= 8 y= -1  inten= -1  inten[ij]= 0
i= 2002 x= 8 y= -1  inten= -1  inten[ij]= 0
i= 2003 x= 8 y= -1  inten= -1  inten[ij]= 0
i= 2004 x= 8 y= -1  inten= -1  inten[ij]= 0
i= 2005 x= 8 y= -1  inten= -1  inten[ij]= 0
i= 2006 x= 8 y= -1  inten= -1  inten[ij]= 0
i= 2007 x= 8 y= -1  inten= -1  inten[ij]= 0
i= 2008 x= 8 y= -1  inten= -1  inten[ij]= 0
i= 2009 x= 8 y= -1  inten= -1  inten[ij]= 0
i= 2010 x= 8 y= -1  inten= -1  inten[ij]= 0
i= 2011 x= 8 y= -1  inten= -1  inten[ij]= 0
i= 2012 x= 8 y= -1  inten= -1  inten[ij]= 0
i= 2013 x= 8 y= -1  inten= -1  inten[ij]= 0
i= 2014 x= 8 y= -1  inten= -1  inten[ij]= 0
i= 2015 x= 8 y= -1  inten= -1  inten[ij]= 0
i= 2016 x= 8 y= -1  inten= -1  inten[ij]= 0
i= 2017 x= 8 y= -1  inten= -1  inten[ij]= 0
i= 2018 x= 8 y= -1  inten= -1  inten[ij]= 0
i= 2019 x= 8 y= -1  inten= -1  inten[ij]= 0
------XPreProcesSet::AddDataTreeInfo------

As you see I cannot fill “newtree” with “inten[ij]” since there is a problem with “oldtree” which is identical to “datatree[0]”.
However, when I delete the line “datatree->DropBaskets();” in method “XGCProcesSet::FillDataArrays()” I get the following correct
debugging output:

      normalizing data using method <quantile>...
------XGCProcesSet::FillDataArrays------..        
2:i= 2001 x= 111 y= 15  inten= 704.3
2:i= 2002 x= 112 y= 15  inten= 852.3
2:i= 2003 x= 113 y= 15  inten= 908.8
2:i= 2004 x= 114 y= 15  inten= 721.5
2:i= 2005 x= 115 y= 15  inten= 3913.3
2:i= 2006 x= 116 y= 15  inten= 1804.8
2:i= 2007 x= 117 y= 15  inten= 798.9
2:i= 2008 x= 118 y= 15  inten= 776.1
2:i= 2009 x= 119 y= 15  inten= 1370.1
2:i= 2010 x= 120 y= 15  inten= 765.4
2:i= 2011 x= 121 y= 15  inten= 1027.1
2:i= 2012 x= 122 y= 15  inten= 983.9
2:i= 2013 x= 123 y= 15  inten= 837.1
2:i= 2014 x= 124 y= 15  inten= 737.1
2:i= 2015 x= 125 y= 15  inten= 1052
2:i= 2016 x= 0 y= 16  inten= 20181.1
2:i= 2017 x= 1 y= 16  inten= 7760.5
2:i= 2018 x= 2 y= 16  inten= 948.7
2:i= 2019 x= 3 y= 16  inten= 912.6
1:k= 0  *datatree[k]= 0x6319850   datatree[k]= TestA1.cel
...
         finished filling <4> arrays.                   
         computing common mean...
2:k= 0  *datatree[k]= 0x6319850   datatree[k]= TestA1.cel  
------XGCProcesSet::FillDataTree(newtree)------
*oldtree= 0x6319850   oldtree= TestA1.cel
*newtree= 0x6358640   newtree= TestA1.cqu
i= 2001 x= 111 y= 15  inten= 704.3  inten[ij]= 430.7
i= 2002 x= 112 y= 15  inten= 852.3  inten[ij]= 663.8
i= 2003 x= 113 y= 15  inten= 908.8  inten[ij]= 730.55
i= 2004 x= 114 y= 15  inten= 721.5  inten[ij]= 462.175
i= 2005 x= 115 y= 15  inten= 3913.3  inten[ij]= 3228.88
i= 2006 x= 116 y= 15  inten= 1804.8  inten[ij]= 1468.62
i= 2007 x= 117 y= 15  inten= 798.9  inten[ij]= 593.725
i= 2008 x= 118 y= 15  inten= 776.1  inten[ij]= 556.1
i= 2009 x= 119 y= 15  inten= 1370.1  inten[ij]= 1118.15
i= 2010 x= 120 y= 15  inten= 765.4  inten[ij]= 538.15
i= 2011 x= 121 y= 15  inten= 1027.1  inten[ij]= 836
i= 2012 x= 122 y= 15  inten= 983.9  inten[ij]= 802.425
i= 2013 x= 123 y= 15  inten= 837.1  inten[ij]= 645.35
i= 2014 x= 124 y= 15  inten= 737.1  inten[ij]= 489.925
i= 2015 x= 125 y= 15  inten= 1052  inten[ij]= 0
i= 2016 x= 0 y= 16  inten= 20181.1  inten[ij]= 0
i= 2017 x= 1 y= 16  inten= 7760.5  inten[ij]= 0
i= 2018 x= 2 y= 16  inten= 948.7  inten[ij]= 0
i= 2019 x= 3 y= 16  inten= 912.6  inten[ij]= 0

For a very long time I did not understand why I get these different results, so I looked at the differences in the source code for
TTree.cxx and TBranch.cxx between root_v5.26/00a and root_v5.24/00. I realized that some member variables of TBranch have been removed,
so I had the idea that the problem could be related to the fact that “datatree” was reading the trees from a ROOT file which I have
created with root_v5.20/00. This file is named “DataTest3_cel.root”. For this reason I have re-created this file with root_v5.26/00a
with the name “DataTest3_52600a_cel.root”. And indeed, using this new data file I can now use “datatree->DropBaskets();” and get the
correct results.

If this interpretation turns out to be correct, then there is a severe problem when using code containing “tree->DropBaskets()” to
read trees from ROOT files which were created with earlier versions of ROOT.

Since I am not sure if it is possible to demonstrate this problem with a simple macro, I have decided to attach the relevant files
and the source code in a zipped directory “dropbaskets.tar.gz”. After unzipping the directory you need first to change to subdirectory
“src” and compile the source code by typing “make”. Afterwards, go back to directory “dropbaskets” and start root_v5.26/00a.
Within root you need to type the following (which is also shown in macro “macro4XPSTest3.C”):

  .L macro4XPSTest3.C 
  Init() 
  RMATest3("tmp_Test3A_rma", "DataTest3_cel.root")
  RMATest3("tmp_Test3B_rma", "DataTest3_52600a_cel.root")

Since the source code “XPSPreProcessing.cxx” contains debugging code you should get the same output shown above.

Please let me know if you can reproduce my findings.
Furthermore, if this turns out to be a root problem and not a problem with my code, I would really appreciate if you could find
a solution so that trees from old ROOT files could be read with code using “tree->DropBaskets()”.

Best regards
Christian
dropbaskets.tar.gz (1.32 MB)

Hi Christian,

My apologies for the late answer. As it turns out I had just started to look at this problem but was unsuccessful in reproducing it. Thanks to your example, I can now reproduce it and it will be fixed shortly.

Thanks,
Philippe.

Dear Philippe,

I am glad to hear that you can reproduce my findings, and am looking forward to your fix.

Maybe one note: In April the next Bioconductor version will be released which will contain my program, too. Since I want to
ask the admins to install the new root version on their Bioconductor servers (Linux, Mac, Windows) it would be great if
sometimes in March binaries for the next patch release of root_v5.26/00 would be available, otherwise I would need to stay
with root_v5.24/00.

Best regards
Christian

Hi Christian,

The problem has been fixed in the trunk by revision 32339, it is also fixed in the patch branch.

Cheers,
Philippe

Dear Philippe,

Thank you for fixing the problem.
After downloading the new trunk svn version I can confirm that now everything works fine.
However, on my Mac Tiger I got the following error when compiling the new trunk 32341:

Compiling grst_x509.c
gcc  -c -I/usr/include/libxml2 -Iinclude -DR__SSL -DOPENSSL_NO_KRB5 -U_FORTIFY_SOURCE -D_LARGEFILE_SOURCE -D_LARGEFILE64_SOURCE -D_FILE_OFFSET_BITS=64 -m32 -D_REENTRANT -D_GNU_SOURCE -Wall -D__macos__  -Wno-deprecated-declarations -undefined dynamic_lookup -multiply_defined suppress  -O2 -DXrdDEBUG=0 -DHAVE_STRLCPY   -DHAVE_LIBZ   -I. -I.. -o ../../obj/grst_x509.o libsslGridSite/grst_x509.c
Compiling grst_xacml.c
gcc  -c -I/usr/include/libxml2 -Iinclude -DR__SSL -DOPENSSL_NO_KRB5 -U_FORTIFY_SOURCE -D_LARGEFILE_SOURCE -D_LARGEFILE64_SOURCE -D_FILE_OFFSET_BITS=64 -m32 -D_REENTRANT -D_GNU_SOURCE -Wall -D__macos__  -Wno-deprecated-declarations -undefined dynamic_lookup -multiply_defined suppress  -O2 -DXrdDEBUG=0 -DHAVE_STRLCPY   -DHAVE_LIBZ   -I. -I.. -o ../../obj/grst_xacml.o libsslGridSite/grst_xacml.c
Creating archive ../../lib/libsslGridSite.a
rm -f ../../lib/libsslGridSite.a
if [ "Darwin" = "SunOS" -a "g++" = "CC" ]; then \
          if [ "x/SunWS_cache" != "x" ]; then \
             g++ -xar -o ../../lib/libsslGridSite.a ../../obj/SunWS_cache/*/*.o; \
          else \
             g++ -xar -o ../../lib/libsslGridSite.a ../../obj/grst_asn1.o ../../obj/grst_err.o ../../obj/grst_gacl.o ../../obj/grst_http.o ../../obj/grst_verifycallback.o ../../obj/grst_x509.o ../../obj/grst_xacml.o ; \
          fi; \
       else \
          ar -rc ../../lib/libsslGridSite.a ../../obj/grst_asn1.o ../../obj/grst_err.o ../../obj/grst_gacl.o ../../obj/grst_http.o ../../obj/grst_verifycallback.o ../../obj/grst_x509.o ../../obj/grst_xacml.o ; \
          ranlib ../../lib/libsslGridSite.a; \
       fi
Compiling XrdSecProtocolssl.cc
g++ -c -Iinclude -DR__SSL -DOPENSSL_NO_KRB5 -D_LARGEFILE_SOURCE -D_LARGEFILE64_SOURCE -D_FILE_OFFSET_BITS=64 -m32 -D_REENTRANT -D_GNU_SOURCE -Wall -D__macos__  -Wno-deprecated-declarations -undefined dynamic_lookup -multiply_defined suppress  -O2 -DXrdDEBUG=0 -DHAVE_STRLCPY   -DHAVE_LIBZ   -I. -I.. -o ../../obj/XrdSecProtocolssl.o XrdSecProtocolssl.cc
XrdSecProtocolssl.cc: In member function 'virtual void XrdSecProtocolssl::secClient(int, XrdOucErrInfo*)':
XrdSecProtocolssl.cc:263: error: invalid conversion from 'char* (*)()' to 'char* (*)(...)'
XrdSecProtocolssl.cc:263: error:   initializing argument 1 of 'char* PEM_ASN1_read(char* (*)(...), const char*, FILE*, char**, int (*)(char*, int, int, void*), void*)'
XrdSecProtocolssl.cc:490: error: invalid conversion from 'int (*)()' to 'int (*)(...)'
XrdSecProtocolssl.cc:490: error:   initializing argument 1 of 'int PEM_ASN1_write(int (*)(...), const char*, FILE*, char*, const EVP_CIPHER*, unsigned char*, int, int (*)(char*, int, int, void*), void*)'
make[5]: *** [../../obj/XrdSecProtocolssl.o] Error 1
make[4]: *** [Darwinall] Error 2
make[3]: *** [all] Error 2
make[2]: *** [XrdSecssl] Error 2
make[1]: *** [all] Error 2
*** Error condition reported by make (rc = 2):
make: *** [net/xrootd/src/xrootd/LastBuild.d] Error 1
rm core/utils/src/RStl_tmp.cxx core/utils/src/rootcint_tmp.cxx

Only after doing “./configure macosx --disable-xrootd” could I complete the compilation of root.

Best regards
Christian

Dear Christian,

Unfortunately we do not have Tiger machines where to test and problems like the one you are experiencing may always happen with new developments.
We will try to fix it asap.
In the meantime, disabling ‘xrootd’ is one workaround. A conceptually similar one, but with finer granularity, is to disable only the new module.
To do that you can try:

--with-xrootd-opts="--disable-secssl"

instead of ‘–disable-xrootd’.

Gerri Ganis

Dear Gerri,

Doesn’t have Fons Tiger machines?

Luckily I do not need xrootd, however this is not the first time that I had to disable xrootd in order to be able
to compile root. Earlier on I had to disable it when compiling root on OpenSUSE11.0 and Windows Vista, and recently
I had to disable xrootd when compiling root on Mac Leopard for 64 bit, see:
root.cern.ch/phpBB2/viewtopic.ph … 271759c2ea
This makes me wonder what might be the reason for this?

Best regards
Christian

Dear Christian,

I will check with Fons for Tiger. I meant that we do not have public Tiger machines as we do for other platforms.

The problem you refer to with 5-24-00 and leopard was due to the additional ‘-arch’ argument you gave as option to --with-cxx . In the end you dropped arguments in --with-cxx and --with-ld and that should have worked for xrootd too.
The support for alternative compilers is limited to the compiler executable path. This can be probably improved, if it becomes an issue.
We build daily xrootd for 64 bits.

I am not aware of the problems with OpenSuse and Vista.
Vista is used by Bertrand Bellenot, who also introduced the basic windows support for the xrootd client, and he makes sure daily that any change in xrootd does not break its configurations. Please report to him any problem you have with that.
OpenSuse is not a platform we test on and yours is the first report for problems in there. If you give more details about the problem I can try to setup a virtual machine and debug it.

Gerri

Dear Gerri,

Thank you for explaining that the problem with xrootd on Leopard was the ‘-arch’ argument. I did not know this,
since I have never got an answer to this question.

Regarding the problem on Vista, your answer was: “If you do not need xrootd, the best is to follow Axel’s suggestion.
Otherwise we will investigate further and try to find at least a workaround.”, see:
root.cern.ch/phpBB2/viewtopic.ph … 4a4711d1c9
I do not know if this problem has been solved since then.

Regarding OpenSUSE11.0 it seems to have been a problem of the gcc compiler used by Novell, see:
root.cern.ch/phpBB2/viewtopic.ph … 4a4711d1c9
I did not experience the problem with OpenSUSE 11.1.

I understand that “problems like the one you are experiencing may always happen with new developments” when using
the development version of root, however for me it is important that I can compile the production version of root
w/o problems on Linux and on MacOS X Tiger/Leopard.

Best regards
Christian

Dear Philippe,

Since you have mentioned that the problem has been fixed in the trunk by revision 32339, and is also fixed in the patch branch,
I have just compiled root_v5.26/00b and found that the problem is still not fixed in this patch; currently it is only fixed in the trunk.
Do you know when the next patch root_v5.26/00c will be released, where the problem will be solved?

Best regards
Christian

Hi Christian,

Indeed (as seen in root.cern.ch/drupal/content/root … ease-notes) the fix was put in the v5.26 patch branch after the releases of v5.26/00b. We have no yet fixed a data for the release of v5.26/00c.

Cheers,
Philippe.

Dear Philippe,

I have seen that for each patched version you can download the binaries for Windows, Mac and Linux, which is exactly what I need.
However, as mentioned before, these binaries must be available at the beginning of April, otherwise I need to ask the server admins
and also the users to continue using root_v5.24/00 in the upcoming release version of Bioconductor.

Best regards
Christian

Hi Christian,

We just discovered (and solved) a slowdown in the way ROOT loaded library in v5.26 and just uploaded the patch. We should be releasing a patch release shortly after the Easter holiday.

Cheers,
Philippe.

Dear Philippe,

Thank you for this information, however just this evening I have asked the Bioconductor developers to keep the old
root version, since they are already setting up the servers.
Once the binaries of the patched root version are available I would need to test them extensively first, but I will see.

Best regards
Christian