Bug #10194
Crash when running MicroBooNE Geant4 simulation
Description
On behalf of Herbert Greenlee, reported by e-mail:
In larsoft/uboonecode v04_23_00, I started getting the following error
from deep in art framework code in an integration test that used to work.
.
Art version, which did not change from previous working release, is
v1_15_02.
.
The input file on uboonegpvmXX is
.
/uboone/data/users/greenlee/crash/crash.root
.
Fcl file is attached.
.
Here is an error message from prof build:
.
%MSG-s ArtException: PostOpenFile 18-Sep-2015 00:11:30 CDT BeforeEvents
cet::exception caught in art
---- LogicError BEGIN
makePartner Attempted to make partner of a product that does not know how!
Please report to the ART framework developers.
cet::exception caught in EventProcessor and rethrown
---- LogicError END
%MSG
.
The debug build just segfaults.
What does this error message mean?
The configuration file used for was standard_g4_uboone.fcl.
History
#1 Updated by Gianluca Petrillo over 5 years ago
- Category set to Simulation
- Status changed from New to Assigned
- Assignee set to Gianluca Petrillo
Analysis¶
In profiling mode, the output quoted by the reporter is shown.
In debug mode, a straight segmentation fault is produced; backtrace fails to trace back to art (or anything), landing on a nobody's memory that is not even supposed to be executable.
The crash happens in an obscure point outside LArSoft code, in some ROOT code typically related to input/output.
Incremental simplification of the code around the crash allowed to point to the module MCReco, and the most recent change was in its data product MCShower.
There are two necessary and sufficient conditions for the crash: running a module (e.g., MCReco) that promises that produces<sim::MCShower>() and running ROOT output (RootOutput module).
In this situation, the crash happens after the beginJob() phase, before the beginRun() phase.
Explanation¶
The issue arises from a a last-minute change to sim::MCShower I had made without being careful enough.
The data product sim::MCShower had an empty destructor (against good practise).
It can't be removed because the data product has virtual methods (against good practise).
Since I don't know if some piece of code is relying on the virtualness, I did not remove it.
But I did change the empty destructor to one declared and defined in the class declaration with = default.
That is not understood by CINT, so I moved the destructor into the part that is hidden from it (#ifndef __GCCXML__).
Turns out, all the other virtual functions are also hidden, so now Reflex sees a class with no virtual table (since there are no virtual members) while art sees a class with a virtual table.
The error message does not reflect the problem.
#2 Updated by Gianluca Petrillo over 5 years ago
- Status changed from Assigned to Resolved
- % Done changed from 0 to 100
A fix is pushed to develop branch of lardata.
The fix is trivial: the declaration of the destructor appears again in a place where Genreflex can see it, while the definition is hidden.
The fixed code successfully runs lar -c standard_g4_uboone.fcl -s crash.root.
#3 Updated by Lynn Garren over 5 years ago
- Status changed from Resolved to Closed