Error in <TInterpreter::AutoParse>: Error parsing payload code for class LeptonSelector with content:

Hi,

I am experiencing a weird issue when dealing with custom libraries/packages. The funny thing is that the same code works with ROOT 6.08.04 under SLC6 and gcc 5.3.0 (now using 6.16.00 in CVMFS under CC7 and gcc 4.8). I have some libraries that I can load and then create some objects using>

TClass result("Lepton");
LeptonParentClass* bla = (LeptonParentClass*) result.New();

However I have some other classes where I had to add a LinkDef.h file with stuff like:

#pragma link C++ class PAFGenericItemVariableContainer<Lepton>+;

For these classes the dictionary and library are generated (custom Makefile) and they can be loaded with no problem. When I try to instantiate them through the couple of lines above:

  1. If I do it in a local ROOT session it works
  2. If I try to do it through a compiled code it spits the following errors:
Error in <TInterpreter::AutoParse>: Error parsing payload code for class LeptonSelector with content:

#line 1 "LeptonSelectorDict dictionary payload"

#ifndef G__VECTOR_HAS_CLASS_ITERATOR
  #define G__VECTOR_HAS_CLASS_ITERATOR 1
#endif

#define _BACKWARD_BACKWARD_WARNING_H
#include "LeptonSelector.h"

#undef  _BACKWARD_BACKWARD_WARNING_H

Warning in <TClass::TClass>: no dictionary for class LeptonSelector is available

Any hint of what to check is very much welcome! Thanks!

Isidro


_ROOT Version: 6.16.00 (CVMFS)
_Platform: CC7
_Compiler: gcc48


Hi,

there could be a difference in your environment.

  1. Can you have a look?
  2. Did the directory structure of your application change?
  3. Do or did you define a ROOT_INCLUDE_PATH environment variable?
  4. In your compiled code, can you try to create a TApplication?

Cheers,
Danilo

Ciao Danilo,
Thanks for the quick answer. Answers to your questions:

  1. Environment: The main difference is that I am using SLC6 in one (working) case and CC7 in the other (not working). I forgot to mention in SLC6 I compiled ROOT myself, while in CC7 I use the one distributed through CVMFS.

  2. Application structure: Nothing changed.

  3. No, I don’t define ROOT_INCLUDE_PATH

  4. At which level should I create TApplication?

An extra piece of information: I tried with ROOT 6.12.07 and gcc 7.3.1 (from a CMSSW installation on CVMFS) with identical results.

Cheers,

Isidro

Hi Isidro,

thanks for the answers.
To be clear: does the compiled code work on slc6?
How did you configure the cvmfs ROOT release?

Cheers,
D

Hi Danilo,
Sorry if I did not make it clear. In SLC6 I compiled and installed ROOT 6.08.04 first and then my code. The steps I follow and the code I use is identical in SLC6 and CC7. Except for the ROOT version which in SLC6 is 6.08.04 compiled by myself and in CC7 it is 6.16.00 in CVMFS.

Cheers,
Isidro

Hi Isidro,

I tend to exclude an issue in ROOT since we did not see anything similar in months of testing on many platforms, included the ones you mention.
The TApplication can be created soon-ish in the main function of your compiled program for example.
What happens if you try to include the file LeptonSelector.h at the prompt with the statement #include "LeptonSelector.h"?
Where is it located? Can ROOT access it?

Cheers,
D

Hi Danilo,
Thanks for your answer. I really appreciate a lot your help!

I will try instantiating of TApplication as soon as possible.
Meanwhile I have tried to use different combinations of ROOT and gcc locally compiled with no success. Now trying exactly the same ROOT version I had working on SLC6 and same compiler (xrootd is giving me a few headaches with this).

I cannot do the test you suggest since LeptonSelector.h includes lot’s of other stuff both from my own analysis code and from the framework (PAF) I am using.

Maybe I can explain better how this works. We are using since long a PROOF based framework (PAF, http://www.hep.uniovi.es/PAF/). It can also run sequentially and it is based on TSelector. The user codes a set of TSelector-like classes and tells the framework to use them on the date. The framework then goes through this “selectors”, and:

  1. Compiles them (custom Makefiles are generated)
  2. Loads them (gSystem->Load("libXXXX.so"))
  3. Uploads it to the remote nodes (this is not been used now)
  4. Instantiates them:
TClass result("SomeSelector"); //This line fails for some selectors
PAFSelectorBaseClass* bla = (PAFSelectorBaseClass*) result.New();

All this steps are carried out by the framework (compiled code). Once the compilation is over and ROOT fails, I can successfully execute points 2 and 3 in a new pure ROOT session (weird!).

The problem appears only for those classes were we have a custom LinkDef.h file with the following content.

#ifdef __CLING__
#pragma link C++ class PAFGenericItemVariableContainer<Lepton>+;
#pragma link C++ class PAFGenericItemVariableContainer<std::vector<Lepton>>+;
#pragma link C++ class LeptonSelector+;
#endif

So, for me the suspects are:

  • Some missing library/package in my CC7 installation… very strange, since I would expect that something fails before
  • Some change in the way ROOT (cling) generates dictionaries and loads them. And the error message is not showing the real reason of the problem

Of course, my guess might be completely wrong!

Cheers (and sorry for the long message),

Isidro

Hi Isidro,

ROOT tries to parse at runtime headers for interactive usage. The information about what classes should trigger this autoparsing procedure are contained in the dictionaries, the generation of which is steered via the linkdef files.
Now, what (I believe it) happens in your case is that: the library containing your symbols and the dictionaries is properly loaded. ROOT now knows for what classes autoparsing should take place. The interpreter stumbles on an undefined symbol, it tries to complete it by autoparsing the necessary headers. The headers are not found.

How this ansatz matches your distributed setup? What are the relevant changes between the working and non-working backends?

Cheers,
D

Hi Danilo,

Well… that can explain the problem. There are no changes in my code (PAF or analysis) between working and non-working. The only (not negligible) difference is the ROOT release, gcc and OS.

Extra piece of information. PAF with ROOT 6.08.04 with gcc 5.3.0 under CC7 works. That means we can discard a dependency on the OS.(this was the working setup in SLC6).

Now, since I would like to use PAF with newer ROOT releases, how would you suggest a way to debug/get information on what is missing in the autoparse mechanism? Is there any detailed documentation somewhere?

Thanks!

Isidro

Hi Isidro,

we need to remove layers of complexity and arrive to a trivial reproducer.
Can you debug in the same conditions where the workers run? If yes, you can open a simple root prompt and instantiate a LeptonSelector?
What happens if you try to include, at the same prompt on the worker, the LeptonSelector.h header?

Cheers,
D

This topic was automatically closed 14 days after the last reply. New replies are no longer allowed.