***Break*** segmentation violation problem

Newbie
#1

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?

#3

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

#4

Are you defining the type in the vectors?

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

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

#6

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 http://root.cern.ch/forum

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

report at http://root.cern.ch/bugs 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 ?? ()

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

#7

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

#8

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?

#9

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.