Undefined reference to `vtable for TLorentzVector'

ROOT
1

Dear experts,

I am trying to simply define a TLorentzVector with one of the following methods. However, none is successful when compilation:
The only lines I have in the code and that are related to TLorentzVector are:

Including the header
#include "TLorentzVector.h"
Defining the vector
TLorentzVector mu1(0,0,0,0);
or
TLorentzVector mu1;
and tried
TLorentzVector* mu1 = new TLorentzVector(0.,0.,0.,0.);

The above definitions produce the following compilation error. The mentioned function is where the definition of mu1 exists in the source code.
CMakeFiles/BplusYieldLib.dir/Root/Process.cxx.o: In function BplusYield::Process::CalculateWeight(TString, float, float): /cvmfs/atlas.cern.ch/repo/sw/software/21.2/AnalysisBaseExternals/21.2.157/InstallArea/x86_64-centos7-gcc8-opt/include/TLorentzVector.h:597: undefined reference to vtable for TLorentzVector CMakeFiles/BplusYieldLib.dir/Root/Process.cxx.o: In function BplusYield::Process::CalculateWeight(TString, float, float): /cvmfs/atlas.cern.ch/repo/sw/software/21.2/AnalysisBaseExternals/21.2.157/InstallArea/x86_64-centos7-gcc8-opt/include/TVector3.h:254: undefined reference to vtable for TVector3

Any idea why none of the above is working or what to look for in the code? Note that the error isn’t reproducible in a root terminal :neutral_face:
e.g
> root -l
root [0] TLorentzVector* mu1=new TLorentzVector(0,0,0,0)
(TLorentzVector *) 0x368e740
root [1] mu1->SetPtEtaPhiM(1.,1.,1.,1.)

I am using Root version 6.20.06

thanks,
Mazuza

2

Hi Mazuza,

the fact that

makes me think that some other part of your code leads to this error. Maybe you could share the entire code?

3

Maybe you are not linking your shared libraries / executable against ROOT libraries (the same problem as here, which also needed the “-lPhysics”).

5

Hi, can’t be. Its not the only class from root I have. I use for example TTree.h and TH1F.h with no problems

6

Hi, hmmm thinking how to share, its a complicated package that is only available for ATLAS users. I was hoping that the error message could point to where I can look or to which things should be checked.

7

TTree and TH1F need libTree and libHist respectively. TLorentzVector needs libPhysics, which you are probably not linking to your executable (compiling from the commandline, you would need to pass -lPhysics. If you have a makefile/CMakeLists.txt, you need to add the required library there).

8

Hi, I can’t see the explicit linking in the makefile/CMakeLists.txt. Since I am running within the AnalysisBase that is an environment provided by ATLAS, I assume it will be linked to all Root libraries. I am attaching both files which are generated automatically. It would be great if you know where I can link to libPhysics there? In the print out when building and compiling, I could only see the following two lines:
-- Configuring the build of package: BplusYield
-- Found ROOT: /cvmfs/atlas.cern.ch/repo/sw/software/21.2/AnalysisBaseExternals/21.2.157/InstallArea/x86_64-centos7-gcc8-opt/include (found version "6.20/06")

Moreover, I’ve tried to define the object as TLorentzVector* mu=0; This compiles but breaks with errors as attached in the log file. The fact that it compiles should imply that there is no missing linking, no? Anyway the error in the attached log file is misleading for me. I could understand it better when running in a root terminal since it also breaks there, I guess because its a null pointer:
root [5] TLorentzVector *mu2=0
(TLorentzVector *) nullptr
root [6] mu2->SetPtEtaPhiM(1.,1.,1.,1.)
gdb.printing.register_pretty_printer(gdb.current_objfile(), gdb.printing.register_pretty_printer(gdb.current_objfile(), #0 0x00007f82397f046c in waitpid () from /lib64/libc.so.6 #1 0x00007f823976df62 in do_system () from /lib64/libc.so.6 #2 0x00007f823a2d158c in TUnixSystem::StackTrace() () from /usr/lib64/root/libCore.so.6.22 #3 0x00007f823441ae48 in cling::MultiplexInterpreterCallbacks::PrintStackTrace() () from /usr/lib64/root/libCling.so #4 0x00007f823441a22e in cling_runtime_internal_throwIfInvalidPointer () from /usr/lib64/root/libCling.so #5 0x00007f823a9a6086 in ?? () #6 0x0000000002406d30 in ?? () #7 0x56142bb8ba0fc900 in ?? () #8 0x00007f823441a1e0 in ?? () from /usr/lib64/root/libCling.so #9 0x00000000024006f0 in ?? () #10 0x0000000002d76b80 in ?? () #11 0x00007ffd492156f0 in ?? () #12 0x0000000000000000 in ?? () Error in <HandleInterpreterException>: Trying to dereference null pointer or trying to call routine taking non-null arguments. Execution of your code was aborted.

CMakeLists.txt (1.6 KB) Makefile.txt (42.5 KB) log_err_exc.txt (19.5 KB)

thanks!

9

Uncle Google → null pointer dereference

10

Hi, thanks I have already seen that. However its a different problem from what I first asked for. I wish to understand the linking thing.

11

Attach your “CMakeFiles/Makefile2”.

12

Please see above. I have attached them in my reply to equiraud.

13

From the attached “log_err_exc.txt” file, it is clear that “SetPtEtaPhiM” is dereferencing a null pointer ("this=0x0"), called from “BplusYield::Process::CalculateWeight” in line 98 of “/.../AnalysisCode/BplusYield/Root/Process.cxx”, called from “BplusYield::Signal::execute” in line 326 of “/.../AnalysisCode/BplusYield/Root/Signal.cxx”, … .
You need to find why this happens.

14

Hi, yes. To make sure that I am not making a confusion:
The log file is related to the error (can be reproduced in a root terminal) when executing the following two lines: (compiles successfully).
TLorentzVector *mu1=0;
mu1->SetPtEtaPhiM( pt_lead, et_lead, phi_lead, 0.1056583745 );
Line98 in the log file is the above mu1->SetPtEtaPhiM( ...). Line 326 is just calling that line or more specifically the function CalculateWeight where Line98 exists.

The compilation error undefined reference to vtable for TLorentzVector ocurrs with one of the following definitions:
TLorentzVector mu1(0,0,0,0);
or
TLorentzVector mu1;
or
TLorentzVector* mu1 = new TLorentzVector(0.,0.,0.,0.);

Indeed, understanding one of the errors should be enough! but I don’t have ideas yet …

15

You need to ensure that “-lPhysics” is present among used ROOT libraries (I guess you need to talk to your ATLAS colleagues about achieving it).
This library is automatically present in the output of “root-config --libs” and in the “ROOT_LIBRARIES” variable defined in the standard “ROOTConfig.cmake” file.

16

Hi Mazuza,

I myself am an ATLAS user, and I successfully use TLorentzVector within the AnalysisBase framework. In my code (which I can send you a link to if you think it’ll help), I have the following:

TLorentzVector lv_muon1;
lv_muon1.SetPtEtaPhiM(...);
// something else

P.S. Indeed, I did not have to change the CMakeLists.txt to accommodate the TLorentzVector instance.

17

Hi @yus,

thanks for the confirmation. I use it as well in ATHENA with no problems, so indeed it might be sth in the code that I run and I am not aware of. If you have time, could you please have a look? Here is the line in the code which can be seen only by ATLAS members:
https://gitlab.cern.ch/atlas-physics/beauty/rare/bmumu-run2/AnalysisCode/-/blob/master/BplusYield/Root/Process.cxx#L97
Note, running will not be out of the box but you can compile. Anyway the error is in the compilation step.

thanks in advance!

18

Dear all, if you think that this topic should be moved to a different place, please let me know or feel free to do. I am not aware of any. Thanks!

19

Yeah, I can reproduce the issue but I have no idea how to fix it. You may have better luck asking relevant experts by sending an email with your question to the hn-atlas-PATHelp@cern.ch mailing list. I’m sure somebody will know what to do.

20

Thanks for the check. I will send that mailing list.

21

Dear all,
to close this issue, the solution is indeed to add the linking to Physics library. I was looking at the wrong CMakeList file. One file is for building the release that I don’t touch, and the second is specific to my code, the linking should be done in the second.
@yus, I am not sure how it works for you with no modification, but the mailing list commented the following as I’ve asked how it can be:

"probably he is getting the dependency as a side effect of linking against an AnalysisBase package that links this library publicly. Relying on that is a bad idea in general as it’s entirely possible for that package to stop linking the library publicly (which then breaks your code)

thanks again,
Mazuza

1 Like