Segmentation fault w/ bizarre error

Hi,

Does anyone know what the following error means (taken from gdb output):

Fatal: sizeof(::SoftLepton) == sizeof(ROOT::Shadow::SoftLepton) violated at line 969 of `/home/christos/workD0/Physics/Btagging/portJetQ_p140501/./fileHRdL8D.cxx’

Thanks.

–Christos

Found a relevant post on google (see here)

I was ready to give it a shot with a different ROOT version. However, I decided to split my input root file in two smaller ones first, and I didn’t get the segmentation fault again. So, “if it ain’t broken, don’t fix it”, I guess. :wink:

–Christos

Hi Christos,

The post you refered to is not revelant. It points only to a warning.

The assertion failure (a fatal error) means that
a) you generate the I/O for a non-TObject class
b) rootcint did not see the same version of the class SoftLepton as the compiler

It usually happens if you use #ifndef CINT inside you class to surround some of the data members. (it can also appears if you use virtual inheritance).

Now your fix seems very odd. The assertion has do with how the dictionary file are generated and compiled. ‘Splitting an input root file’ should have not effect on it. Now I may have mis-understood ‘input root file’, and you may be refering to what I would call a “linkdef” file. If this is the case, you may have slightly change the linkdef file (removed the ‘+’ for Lepton). Short of that, the assertion error should not have disappeared!

Cheers,
Philippe.

I’m glad you responded to this, because this problem just came back to haunt me!

[quote=“pcanal”]Hi Christos,
The assertion failure (a fatal error) means that
a) you generate the I/O for a non-TObject class
[/quote]

I do not understand what you mean by that. My input is a tree with a bunch of branches (each branch containing arrays of basic types)

Why would that happen?

Now, I do see the “#ifndef __CINT”: not in my code, but in code that my class uses. Does this mean that something is not done properly? This is a runtime problem, I get no errors/warnings while compiling. Would that go away with a different ROOT version?

My input was a large tree. Not knowing what the problem was, I decided to see if I could run on a smaller set of events. What I mean by “splitting the input” really is generating two smaller input files (events: 1, N/2 and N/2+1, N), instead of a big one (events: 1, N), and chain them together.

[quote]Now I may have mis-understood ‘input root file’, and you may be refering to what I would call a “linkdef” file. If this is the case, you may have slightly change the linkdef file (removed the ‘+’ for Lepton). Short of that, the assertion error should not have disappeared!
[/quote]

I did not change the linkdef file. I still have the + for my class. Otherwise, how would the code know about my class?

:confused:

I don’t really know how to track this down. The compiler is not complaining…

–Christos

PS % which root
/D0/ups/root/Linux-2-4/v3_05_00bKCC_4_0-exception-opt-thread/bin/root

Hi Christos,

The problem IS with in the file that declare the C++ class Lepton.
The problem will appear only if the library that defines it is loaded.
It is possible that this would only happens depending on the input file.

[quote]
Now, I do see the “#ifndef __CINT”: not in my code, but in code that my class uses. Does this mean that something is not done properly? This is a runtime problem, I get no errors/warnings while compiling. Would that go away with a different ROOT version? [/quote]

It is only detected at run-time because some of the compiler we support would not handle well the type of templated code required to detect this problem at compile time.

Check the class Lepton and regenerate its dictionary (after removing either the #ifndef CINT or the ‘+’ in the linkdef.h).

Cheers,
Philippe.

Ok, I had another look at the code that has the “#ifndef CINT” and I don’t really think this is any relevant (I don’t think it is used at all by my class). So, let’s assume that the problem is in my class for now.

This is the relevant “linkdef” file:

#ifdef __CINT__
#ifndef INCLUDE_BTAGGERCLASSES_LINKDEF
#define INCLUDE_BTAGGERCLASSES_LINKDEF
#pragma link C++ class SoftLepton+;
#pragma link C++ class Btagger+;
#endif // INCLUDE_BTAGGERCLASSES_LINKDEF
#endif // __CINT__

“SoftLepton” is a class used by class “Btagger”. Now, you are saying that I should give it another shot after I remove the (+) next to SoftLepton? Btagger? Both?

(what does that + do, by the way? :slight_smile: )

–Christos

A-ha! I had an idea.

I noticed that if I have a macro (my_macro.C) that calls my class (Btagger calling SoftLepton) and I change just SoftLepton, the code does not recompile (and the old version of SoftLepton is used). If, on the other hand, I edit my_macro.C, then the code gets recompiled and the new version of SoftLepton is loaded.

Could this be relevant? Is this what you were implying by removing those +'s from my class in the linkdef file?

–Christos

Hi Christos,

The ‘+’ tell rootcint to generate the I/O for the class. (or the newer version of the I/O is the class has a ClassDef).

Depending which version of ROOT you are using ACLiC may or may get the dependency right. Older version of ACLiC were only rebuilding if the macro or its header was touched. Newer version have a proper dependency check.

“I change just SoftLepton, the code does not recompile”, if you change SoftLepton significantly this would be a big problem (with undetermined behavior).

Those are ok. The #ifdef that would have been a problem would be inside the declaration of SoftLepton itself.

I now think that you problem is a build system problem. When you change the definition of SoftLepton you need to make sure that its dictionary is BOTH regenerated and recompiled.

Cheers,
Philippe.

I think I agree with you. This would explain why those segm. faults would occasionally disappear (for example, when replacing the input file by a chain of two smaller files: editing my_macro.C would force the code to recompile everything, so the latest version of my SoftLepton class would be picked up)

I never had a problem when my_macro.C (the macro calling my class) was forced to recompile. I now believe that the seg. faults where caused by the compiler using outdated SoftLepton libraries.

Thanks for helping me track this down! \:D/