***Break*** segmentation violation problem

I am trying to compile and run a macro mini.C for an ATLAS project.

When I add the following lines of code it produces a Break segmentation violation when I try to do mini.Loop(). I used a MakeClass() to produce mini.C and mini…h.

        std::vector<float> e_pt; std::vector<float> mu_pt; 
	std::vector<float> e_phi; std::vector<float> mu_phi;
	std::vector<float> e_eta; std::vector<float> mu_eta;

	for (size_t lep_i=0; lep_i<lep_n; lep_i++) // loop over leptons to fill e_pt,mu_phi etc
    {
		if (lep_type->at(lep_i) == 11)  // if electron
		{
			e_pt.push_back(lep_pt->at(lep_i));
			e_phi.push_back(lep_phi->at(lep_i));
			e_eta.push_back(lep_eta->at(lep_i));
		}
	    if (lep_type->at(lep_i) == 13)  // if muon
		{
			mu_pt.push_back(lep_pt->at(lep_i));
			mu_phi.push_back(lep_phi->at(lep_i));
			mu_eta.push_back(lep_eta->at(lep_i));
		}
    }

What is wrong?

Can you post the backtrace of the crash? To do so, if you compile your macro, you can add “g” at the end, like

.x myProg.C++g

Are you defining the type in the vectors?

std::vector<Double_t> e_pt, mu_pt;
etc.

I defined the type as std::vector<double> e_pt; mu_pt; etc.
Is that fine?

I think the problem might be with me using the lines

int e_index = std::distance(e_pt.begin(), std::max_element(e_pt.begin(), e_pt.end()));
int mu_index = std::distance(mu_pt.begin(), std::max_element(mu_pt.begin(), mu_pt.end()));

after the block of code in the original post.

When I deleted these two lines the code runs fine.

But I had already made sure to do

#include < algorithm>
#include < iterator>
#include < cmath>

at the start.

The output from

.x mini.C++g

is

Info in : script has already been loaded in interpreted mode
Info in : unloading /afs/hep.man.ac.uk/u/taeny/./mini.C and compiling it
Info in TUnixSystem::ACLiC: creating shared library /afs/hep.man.ac.uk/u/taeny/./mini_C.so

The break segmentation error is

Jiachen Guo

Tue 10/1/2019 3:27 PM

*** Break *** segmentation violation

===========================================================

There was a crash.

This is the entire stack trace of all threads:

===========================================================

#0 0x000000368b0ac89e in waitpid () from /lib64/libc.so.6

#1 0x000000368b03e4e9 in do_system () from /lib64/libc.so.6

#2 0x00007efe71af7ebd in TUnixSystem::StackTrace() () from /cvmfs/sft.cern.ch/lcg/releases/ROOT/6.14.04-0d8dc/x86_64-slc6-gcc62-opt/lib/libCore.so

#3 0x00007efe71afa624 in TUnixSystem::DispatchSignals(ESignals) () from /cvmfs/sft.cern.ch/lcg/releases/ROOT/6.14.04-0d8dc/x86_64-slc6-gcc62-opt/lib/libCore.so

#4

#5 0x00007efe70da4b79 in ?? ()

#6 0x000000368bc010b0 in ?? () from /lib64/libdl.so.2

#7 0x000000368bc010c4 in dlsym_doit () from /lib64/libdl.so.2

#8 0x000000368ac0e5e9 in _dl_catch_error () from /lib64/ld-linux-x86-64.so.2

#9 0x00007efe6489ca50 in ?? () from /cvmfs/sft.cern.ch/lcg/releases/ROOT/6.14.04-0d8dc/x86_64-slc6-gcc62-opt/lib/libHist.so

#10 0x00000000047c9aa0 in ?? ()

#11 0x0000001100000000 in ?? ()

#12 0x00007efe6489ca50 in ?? () from /cvmfs/sft.cern.ch/lcg/releases/ROOT/6.14.04-0d8dc/x86_64-slc6-gcc62-opt/lib/libHist.so

#13 0x00000000047b0f30 in ?? ()

#14 0x0000003f02404ca0 in ?? ()

#15 0x00007efe6489ca50 in ?? () from /cvmfs/sft.cern.ch/lcg/releases/ROOT/6.14.04-0d8dc/x86_64-slc6-gcc62-opt/lib/libHist.so

#16 0x00000000047b0f30 in ?? ()

#17 0x00007efe6d7cfc50 in ?? () from /cvmfs/sft.cern.ch/lcg/releases/ROOT/6.14.04-0d8dc/x86_64-slc6-gcc62-opt/lib/libCling.so

#18 0x0000000000000000 in ?? ()

===========================================================

The lines below might hint at the cause of the crash.

You may get help by asking at the ROOT forum ROOT Forum

Only if you are really convinced it is a bug in ROOT then please submit a

report at Sign in to GitHub · GitHub Please post the ENTIRE stack trace

from above as an attachment in addition to anything else

that might help us fixing this issue.

===========================================================

#5 0x00007efe70da4b79 in ?? ()

#6 0x000000368bc010b0 in ?? () from /lib64/libdl.so.2

#7 0x000000368bc010c4 in dlsym_doit () from /lib64/libdl.so.2

#8 0x000000368ac0e5e9 in _dl_catch_error () from /lib64/ld-linux-x86-64.so.2

#9 0x00007efe6489ca50 in ?? () from /cvmfs/sft.cern.ch/lcg/releases/ROOT/6.14.04-0d8dc/x86_64-slc6-gcc62-opt/lib/libHist.so

#10 0x00000000047c9aa0 in ?? ()

#11 0x0000001100000000 in ?? ()

#12 0x00007efe6489ca50 in ?? () from /cvmfs/sft.cern.ch/lcg/releases/ROOT/6.14.04-0d8dc/x86_64-slc6-gcc62-opt/lib/libHist.so

#13 0x00000000047b0f30 in ?? ()

#14 0x0000003f02404ca0 in ?? ()

#15 0x00007efe6489ca50 in ?? () from /cvmfs/sft.cern.ch/lcg/releases/ROOT/6.14.04-0d8dc/x86_64-slc6-gcc62-opt/lib/libHist.so

#16 0x00000000047b0f30 in ?? ()

#17 0x00007efe6d7cfc50 in ?? () from /cvmfs/sft.cern.ch/lcg/releases/ROOT/6.14.04-0d8dc/x86_64-slc6-gcc62-opt/lib/libCling.so

#18 0x0000000000000000 in ?? ()

===========================================================

Note that the MakeClass mode and std::vector do not mix well …

How should I go about doing it then?

Perhaps just use a fixed array that is long enough so that all entries can fit inside?

If you use MakeClass that is indeed what you need to do. Note that MakeSelector (in the latest version of ROOTi and if the data was stored as an std::vectror) and RDataFrame can give you access to the data as std::vector.