Problem 2380

Summary: warnings/behavior of physical,logical,region and solid stores
Product: Geant4 Reporter: Krzysztof Genser <resnegfk>
Component: geometry/managementAssignee: Gabriele Cosmo <Gabriele.Cosmo>
Status: RESOLVED WORKSFORME    
Severity: normal    
Priority: P4    
Version: 10.7   
Hardware: All   
OS: Linux   

Description Krzysztof Genser 2021-06-04 18:16:02 CEST 
A set of (misleading) warnings started to appear at program exit is some circumstances:

WARNING - Attempt to delete the solid store while geometry closed !
WARNING - Attempt to delete the logical volume store while geometry closed !
WARNING - Attempt to delete the physical volume store while geometry closed !
WARNING - Attempt to delete the region store while geometry closed !

They seem to be related to the singleton pattern implementation in the corresponding classes and perhaps recent changes in G4RunManagerKernel.
Comment 1 Gabriele Cosmo 2021-06-04 21:25:52 CEST 
Such problem usually happens if some wrong manipulations to the geometry is done (wrong deletion order of elements of the geometry or in wrong application state). It does not depend on the singletons.
Are you overloading the default behaviour of Geant4 and its run-manager?
Comment 2 Gabriele Cosmo 2021-06-07 09:35:28 CEST 
Proper destruction of objects should be assured if you explicitly delete the run-manager at the end of your main(). Are you doing so?
Comment 3 Krzysztof Genser 2021-06-09 04:22:15 CEST 
The G4RunManager is held by a unique_ptr in a module which is deleted by the processing framework before the framework exits.
Once the framework completes its execution, after printing its final message, the warning messages are printed at the very end of the lifetime of the entire executable.
Comment 4 Gabriele Cosmo 2021-06-09 09:15:20 CEST 
That explains the problem. Thanks for investigating.
Based on the current design in Geant4, derivates from G4RunManager (or pointers to G4RunManager itself) should not be defined as a smart pointer. It is instead expected the pointer to the run-manager is explicitly deleted at the end of the user application (or framework).
You may try to mimic the sequence of destruction made in G4RunManagerKernel, by explicitly opening the geometry somewhere in the framework code at job closure, and that may clear those warnings, but cannot guarantee that other problems in different areas may occur due to wrong deletion order of static instances.
Comment 5 Krzysztof Genser 2021-06-11 22:13:59 CEST 
It turned out to be a problem with the event processing framework used,
where during a TBB migration a class was missed while converting from
using bare pointers to smart pointers. Now fixed. Sorry for the false alarm.