Working on upgrading to ROOT 5.14.00 from 5.10.00 on both Windows XP (VC7.1 compiler) and Red Hat Linux (gcc 3.2.3)
We have some ROOT files that contain vector<Double32_t> data members, specifically I have one class that contains four such vectors. When I attempt to read “old” files created using 5.10.00 or reading “new” files created with 5.14.00 either in an executable or in CINT - I often receive the following warning:
root [0] gSystem->Load(“commonRootData.dll”);
root [1] gSystem->Load(“reconRootData.dll”);
root [2] TFile f(“recon.root”, “READ”)
root [3] TTree t = (TTree)f.Get(“Recon”)
root [4] ReconEvent *rec = 0
root [5] t->SetBranchAddress(“ReconEvent”, &rec)
root [6] t->GetEvent(0)
Error in : object of class vector<Double32_t> read too few bytes: 26 instead of 46
Error in : object of class vector<Double32_t> read too few bytes: 26 instead of 46
Error in : object of class vector<Double32_t> read too few bytes: 26 instead of 46
(Int_t)8432
I have attempted to make a small simple example - and so far can’t seem to get that to generate the warning message - I’ll keep trying. I do see that in my case, when I receive these warings - I do see that at least one of the vectors is indeed empty.
Still working on providing code that is a simple case…but in the meantime, attached are what should be two identical files (they are slightly different in size) - one produces the CheckByteCount warning and the other does not when reading.
I am generating the library to read these files using the StreamerInfo in CINT so that it will be easy for someone else to reproduce the error. I do indeed see the same behavior when I try to read these files using our full compiled shared library, either within CINT or when reading using one of our ROOT stand-alone applications.
I am hoping there is something obviously wrong with the file that produces the warning…or perhaps a clue.
Actually very little is different… the actual writing of the recon ROOT files is identical code and the contents written should be identical…I should point out the error seems to “require” our full environment where Gaudi is involved. What changes is the fact that I write some additional ROOT files for Monte Carlo data - that are separate from the recon files. This seems to trigger the problem - but that seems to strictly be a trigger and not the real cause. The Monte Carlo files use another set of ROOT classes that include vector<Double_t> (not Double32_t>).
That’s why I have not been able to produce a coherent simple example…it seems I require to use the Gaudi event loop…and to also write out MC data… none of which makes a whole lot of sense and would typically lead me to believe there was some memory issue - but in this case it is as if in the one case knowledge of vector<Double32_t> is adequtely written to the recon file and in the other, that information is not. But I truly do not understand what in our environment would cause such behavior. I cannot reproduce this behavior as yet, in a run where I strictly use ROOT, and write identical data into a recon ROOT file. I should try a simple run that writes both mc and recon data… I haven’t been devoting myself to this effort.
Do you see anything fundamentally different in the two recon ROOT files that suggests why that warning concerning vector<Double32_t> occurs?
[quote]The Monte Carlo files use another set of ROOT classes that include vector<Double_t> (not Double32_t>). [/quote]So the problem is likely to be a problem of which dictionary is loaded when for vector and vector. Most likely the version of Gaudi/Root that you are using is presenting a problem with some of its dictionary (in the case of Gaudi, if memory serve, you are going to be using both Reflex and Cint based dictionary … the Reflex based dictionary have had problems (fixed now) with template of Double32_t).
What parts of Gaudi (and which version) are you using when producing the NotOK file? In particular I am interested to know if both CINT and Reflex dictionaries are available at the same time in your application. I understand that the dictionary for your classes are produced with ROOTCINT, is this correct? What about GaudiPython? are you using it? This package loads a Reflex dictionary that in some versions included a vector.
I am also working on this problem, in parallel with Heather.
It seems I have a way to reproduce the problem, which would not involve GAUDI, nor MC generation. The same as Heather, I am suffering while I try to extract some “simple” demonstration code. Hopefully, I will have one in coming hours/days.
Here is a first set of code so to demonstrate the problem. Just edit the beginning of RUN_ME so to say where the ROOT releases are staying. Let me know if it is reproducing the error with your platform.
I have already removed most of the code from the original program. I will pursue the effort tomorrow, and try to deliver something even smaller. VectorDoubleBug.tar.gz (177 KB)
I failed to compile your code …
I saw:[quote]idents/TowerId.cxx:41:1: pasting “.” and “id” does not give a valid preprocessing token[/quote] … once I fixed this … I can reproduce the problem … I’ll check into it.
ROOT 5.10 was not really able to write the vector<Double32_t> as Double32_t and in some cases (like yours) it was still registering them as vector<Double32_t> which ROOT 5.14 does follow.
However this is ‘fixable’ to some extend. I attached a modified version of David’s first instance of readReconData.cxx that contains (surrounded by #if ROOT_VERSION(5,14,0) < ROOT_VERSION_CODE) code that solve your problem … however to use it you need to know the version number of your ‘old’ classes and the list of data member that are vector<Double32_t>.
Thanks for the diagnostic and the fix
I have just validated that things are OK when I both apply the patch and use a HEAD revision of root (I just needed to add the include of TStreamInfo.h).
Since the fix depends on the class schema number, and the list of vector<Double32_t> fields, I guess that I will need to keep it in my code even when using the next ROOT releases. True ?
the patch in the user code : this is the one you gave in a message above, and we have well understood we must keep it as long as we have old ROOT files we want to analyze.
the patch for the ROOT code : you gave the advice to use the head of ROOT, but having validating ROOT 5.14, we were wondering if we could get some patch for ROOT 5.14, rather than move to a new release that we would need to re-validate from scratch ?
Thanks. I was not aware of this branch.
I have checked out the head revision of branch v5-14-00-patches, and tried to compile. It failed with the error :
g++ -O -pipe -Wall -W -Woverloaded-virtual -fPIC -Iinclude -pthread -o meta/src/TStreamerInfo.o -c meta/src/TStreamerInfo.cxx
meta/src/TStreamerInfo.cxx: Dans function « Bool_t
::CollectionMatch(const TClass*, const TClass*) »:
meta/src/TStreamerInfo.cxx:751: erreur d’analyse syntaxique avant le jeton « { »
…
Before I try with another architecture, do you confirm “compilability” has been demonstrated on your side ?
