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