Troubles with inheritance when compiling root macro

ROOT
1

Dear all,

first of all, apologies for the length of this message! I am facing an error when compiling a macro on lxplus, root 5.30.05.
My (rather complicate) setup is as follows:

  • within a root session, I compile about 40 libraries, using gSystem->Load(“macro.C+”)

  • I copy the compiled libraries in a single directory, which is part of my DynamicPath

  • I then start a new root session, my macro looks like the following:

    void run() {
    gSystem->Load(“macro.C+”);
    // … here I similarly load also the other 40 libraries…
    MyClass myClass;
    myClass.run();
    }

    MyClass inherits from essentially all of the ~40 compiled macros that are loaded before I try to compile it.

Now, I ran on a personal machine, with root 5.30.02, and everything worked fine. When I try using lxplus root 5.30.05, athena 17.2.0, I get the following errors (HSG2 is the name of my class):

/afs/cern.ch/work/a/abelloni/be/HSG2_C_ACLiC_dict.cxx: In function ‘void G__cpp_setup_inheritanceHSG2_C_ACLiC_dict()’:
/afs/cern.ch/work/a/abelloni/be/HSG2_C_ACLiC_dict.cxx:1522: error: ‘G__2vbo_TriggerReader_ReaderBase_0’ was not declared in this scope
/afs/cern.ch/work/a/abelloni/be/HSG2_C_ACLiC_dict.cxx:1527: error: ‘G__2vbo_BookKeeperReader_ReaderBase_0’ was not declared in this scope
/afs/cern.ch/work/a/abelloni/be/HSG2_C_ACLiC_dict.cxx:1532: error: ‘G__2vbo_VertexReader_ReaderBase_0’ was not declared in this scope
.
.
.

I get one error message for each of the classes from which my class inherits.
In both cases, the CINT version is 5.18.00. I also noted that the lxplus compilation performs stricter checks (there are warnings that I do not have in the 5.30.02 case). Does anyone have a suggestion as to what the origin of this error is, and how to possibly fix it? Thank you very much for any suggestion,

Alberto

2

Just a stupid idea. Did you recreate all libraries when switching the machine / compiler / root version?
In order to make sure that everything is recreated, use “macro.C++” instead of “macro.C+” (for all of your 40 libraries).

3

Dear Pepe,

sorry for not clarifying this point. I started from a clean set of source files in both cases (no .d nor .so files), therefore the first round of compilation did produce new libraries on each machine. Best,

Alberto

4

Hi Alberto,

This is a bit strange. Could you have run of quota and/or disk space (so that the dictionary source file is only partial)?

Philippe.

5

Dear Philippe,

I have quite a big quota available (~20GB!), so I think I should be safe. Please let me know if there is any additional piece of information that I could provide to help. Best,

Alberto

6

Hi,

One thing that you can do track down the issue, is to have ACLiC keep the files around and compare them on your working and non working machine. By set gDebug to 7, after the compilation the file HSG2_C_ACLiC_dict.cxx will be kept.

Cheers,
Philippe.

7

Dear Philippe,

I ran two jobs with gDebug=7, as you suggested. I attached the two HSG2_C_ACLiC_dict.cxx files I obtained for completeness. I compared them and the main difference seems to be that the file I obtain in the job that does not work, contains the following lines:

if(0==G__getnumbaseclass(G__get_linked_tagnum(&G__HSG2_C_ACLiC_dictLN_TriggerReader))) {
  {    G__inheritance_setup(G__get_linked_tagnum(&G__HSG2_C_ACLiC_dictLN_TriggerReader),G__get_linked_tagnum(&G__HSG2_C_ACLi_dictLN_ReaderBase),(long)G__2vbo_TriggerReader_ReaderBase_0,1,3);
  }
}
if(0==G__getnumbaseclass(G__get_linked_tagnum(&G__HSG2_C_ACLiC_dictLN_BookKeeperReader))) {
  {        G__inheritance_setup(G__get_linked_tagnum(&G__HSG2_C_ACLiC_dictLN_BookKeeperReader),G__get_linked_tagnum(&G__HSG2_C_ACLiC_dictLN_ReaderBase),(long)G__2vbo_BookKeeperReader_ReaderBase_0,1,3);
  }
}
if(0==G__getnumbaseclass(G__get_linked_tagnum(&G__HSG2_C_ACLiC_dictLN_VertexReader))) {
  {        G__inheritance_setup(G__get_linked_tagnum(&G__HSG2_C_ACLiC_dictLN_VertexReader),G__get_linked_tagnum(&G__HSG2_C_ACLiC_dictLN_ReaderBase),(long)G__2vbo_VertexReader_ReaderBase_0,1,3);
  }
}

.
.
.
Does this make sense? Why would these lines be missing in the job that does work? Why are they generated in the jobs that fails? Thank you very much for any clarification. Best,

Alberto
HSG2_C_ACLiC_dict.cxx.WORKS.txt (377 KB)
HSG2_C_ACLiC_dict.cxx.BAD.txt (393 KB)

8

Hi,

It does not make sense :frowning:. In the output when running gDebug = 7, was a series of command, one was a rootcint command. Could you extract this command and run it with valgrind (on the failing platform) just in case it detect some uninitialized memory use?

Thanks,
Philippe.

9

Dear Philippe,

I am sorry for the bother, but I have a problem with valgrind:

valgrind --tool=memcheck
valgrind: failed to start tool ‘memcheck’ for platform ‘x86-linux’: No such file or directory

I setup athena version 17.2.0, CMTCONFIG=i686-slc5-gcc43-opt. I found that others had the same problem (reported on savannah), but the solution was to move to another cluster! Would you have any suggestion? Thanks a lot for your help. Best,

Alberto

10

Hi Alberto,

Yes, you could download and build valgrind yourself (make sure to use --prefix=/one_of_your_directory) …

Philippe.

PS. Are the classes with the problem intended to be stored on file? If not, then you could work around the problem by adding the base class declaration from CINT.

11

Dear Philippe,

I found a version of valgrind that does run on lxplus. Here is my (extremely long) command line:

/afs/cern.ch/sw/lcg/external/valgrind/3.5.0/i686-slc5-gcc43-opt/bin/valgrind --tool=memcheck /cvmfs/atlas.cern.ch/repo/sw/software/i686-slc5-gcc43-opt/17.2.0/sw/lcg/app/releases/ROOT/5.30.05/i686-slc5-gcc43-opt/root/bin/rootcint --lib-list-prefix=/afs/cern.ch/work/a/abelloni/HZZGrid/be/HSG2_C_ACLiC_map -f /afs/cern.ch/work/a/abelloni/HZZGrid/be/HSG2_C_ACLiC_dict.cxx -c -p -I/cvmfs/atlas.cern.ch/repo/sw/software/i686-slc5-gcc43-opt/17.2.0/sw/lcg/app/releases/ROOT/5.30.05/i686-slc5-gcc43-opt/root/include -I/cvmfs/atlas.cern.ch/repo/sw/software/i686-slc5-gcc43-opt/17.2.0/sw/lcg/app/releases/ROOT/5.30.05/i686-slc5-gcc43-opt/root/include -D__ACLIC__ -I/afs/cern.ch/user/a/abelloni/work/HZZGrid/be/include -I/cvmfs/atlas.cern.ch/repo/sw/software/i686-slc5-gcc43-opt/17.2.0/sw/lcg/external/clhep/1.9.4.7/i686-slc5-gcc43-opt/include -I/afs/cern.ch/user/a/abelloni/work/HZZGrid/be/Tools/MuonMomentumCorrections/MuonMomentumCorrections -I/afs/cern.ch/user/a/abelloni/work/HZZGrid/be/Tools/PileupReweighting -I/afs/cern.ch/user/a/abelloni/work/HZZGrid/be/Tools/ExtendedPileupReweighting -I/afs/cern.ch/user/a/abelloni/work/HZZGrid/be/Tools/MuonEfficiencyCorrections -I/afs/cern.ch/user/a/abelloni/work/HZZGrid/be/Tools/egammaAnalysisUtils -I/afs/cern.ch/user/a/abelloni/work/HZZGrid/be/Tools/BTagCalibrationHistos -I/afs/cern.ch/user/a/abelloni/work/HZZGrid/be/Tools/JetResolution/share -I/afs/cern.ch/user/a/abelloni/work/HZZGrid/be/Tools/LHAPDF/include -I/afs/cern.ch/user/a/abelloni/work/HZZGrid/be/Tools/TrigMuonEfficiency -I/afs/cern.ch/user/a/abelloni/work/HZZGrid/be/Tools/IsoIPSF -I/afs/cern.ch/user/a/abelloni/work/HZZGrid/be/Tools/CalibrationDataInterface/CalibrationDataInterface -I/afs/cern.ch/user/a/abelloni/work/HZZGrid/be/Tools/CalibrationDataInterface /afs/cern.ch/work/a/abelloni/HZZGrid/be/./HSG2.C /afs/cern.ch/work/a/abelloni/HZZGrid/be/HSG2_C_ACLiC_linkdef.h

This is the only line that contains “rootcint” in the long log I produced when running with gDebug=7.
I attached the valgrind log file, here are its final lines:

==27102== LEAK SUMMARY:
==27102== definitely lost: 310,028 bytes in 39,352 blocks
==27102== indirectly lost: 2,152 bytes in 104 blocks
==27102== possibly lost: 1,028 bytes in 8 blocks
==27102== still reachable: 9,943 bytes in 17 blocks
==27102== suppressed: 0 bytes in 0 blocks
==27102==
==27102== For counts of detected and suppressed errors, rerun with: -v
==27102== ERROR SUMMARY: 59 errors from 59 contexts (suppressed: 53 from 10)

Is there any indication to why the dict files are so different in the two machines? Best,

Alberto
valgrind_output.txt (103 KB)

12

[quote]Is there any indication to why the dict files are so different in the two machines?[/quote]Unfortunately not (there is no error report, just (intentional) memory leaks).

Are the classes with the problem intended to be stored on file? If not, then you could work around the problem by adding the base class declaration from CINT.

Philippe.

13

Dear Philippe,

the macro I run interactively creates an object of type HSG2 (the last class I compile), which inherits from multiple other objects, loaded right before I try to compile HSG2 (this is the step that fails). How can I try the workaround that you suggest, in practice? Could you provide more details? Thanks a lot, best,

Alberto

14

Hi Alberto,

class HSG2 #ifndef __CINT__ : public BaseClass #endif ....

(This works if and only if object of type HSG2 are not saved in a ROOT File).

Philippe.

15

Dear Philippe,

ach, this will take a bit of time! I have about one hundred classes which inherit from a few base classes. I assume I need to modify all of them. I tried modifying only my final class, HSG2, which inherits from AnalysisBase, and obtained this type of error messages:

/afs/cern.ch/work/a/abelloni/HZZGrid/be/HSG2_C_ACLiC_dict.o:(.data.rel.ro._ZTC4HSG20_12AnalysisBase[vtable for HSG2]+0x190): undefined reference to non-virtual thunk to AnalysisBase::~AnalysisBase()' /afs/cern.ch/work/a/abelloni/HZZGrid/be/HSG2_C_ACLiC_dict.o:(.data.rel.ro._ZTC4HSG20_12AnalysisBase[vtable for HSG2]+0x194): undefined reference tonon-virtual thunk to AnalysisBase::~AnalysisBase()’

Best,

Alberto

16

Hi Alberto,

Humm … oddness continue … Then I would use a newer version of ROOT (and forget about changing the header file); if this is really not possible, and maybe you can give me the complete instruction to reproduce the problem on lxplus.

Cheers,
philippe