pandora exception triggered by configuration error
source /cvmfs/uboone.opensciencegrid.org/products/setup_uboone.sh setup uboonecode v06_18_01 -q e10:debug mkdir developments cd developments/ mrb newDev source ../developments/localProducts_larsoft_v06_18_01_debug_e10/setup cd srcs/ mrb g uboonecode cd uboonecode/ mrbsetenv mrb i -j 4 lar -c prod_muminus_0-2.0GeV_isotropic_uboone.fcl -n 2 lar -c standard_g4_uboone.fcl -n 2 -s prod_muminus_0-2.0GeV_isotropic_uboone_*_gen.root lar -c standard_detsim_uboone.fcl -n 2 -s prod_muminus_0-2.0GeV_isotropic_uboone_*_gen_*_g4.root lar -c reco_uboone_mcc8_driver_stage1.fcl -n 2 -s prod_muminus_0-2.0GeV_isotropic_uboone_*_gen_*_g4_*_detsim.root lar -c reco_uboone_mcc8_driver_stage2.fcl -n 2 -s prod_muminus_0-2.0GeV_isotropic_uboone_*_gen_*_g4_*_detsim_*_reco1.root sed -i 's/microboone_reco_mcc8_producers.pandoraCosmicKalmanTrack.inputs.inputCaloLabel/#microboone_reco_mcc8_producers.pandoraCosmicKalmanTrack.inputs.inputCaloLabel/' fcl/reco/reco_uboone_mcc8.fcl mrb i -j 4 lar -c reco_uboone_mcc8_driver_stage2.fcl -n 2 -s prod_muminus_0-2.0GeV_isotropic_uboone_*_gen_*_g4_*_detsim_*_reco1.root
terminate called after throwing an instance of 'pandora::StatusCodeException' Aborted
Pandora driver modules don't try to delete an unexisting pandora any more.
This solves issue #14891 .
#3 Updated by Gianluca Petrillo over 3 years ago
- Category changed from Setup / Environment to External Packages
- % Done changed from 0 to 100
The exception is in fact from Pandora. This is what happens:
- a Pandora-driving module instance is constructed (in this case, was
- a module throws an exception during construction (for example, a configuration error from
- art intercepts the exception and asks all the constructed modules to destroy
- the Pandora-driving module throws an exception during destruction
- in this state (already at exception handling), the additional exception immediately calls
The exception is thrown because there is no Pandora instance yet, but the module on destruction demands its destruction. Pandora (
MultiPandoraApi::DeletePandoraInstances()) is not protected against asking for the destruction of a null Pandora instance.
The instance is not there yet because it is not created on module construction, but rather on
- the module should not attempt to destroy Pandora before it has been initialised; this is fixed with commit larpandora:b75736cd37c13422f1d2d932cfa49e6461fe2db7
Pandora should not allow exceptions to escape from destructors; the reason is apparent in the reported behaviour
- Pandora could take the extra step of checking for an invalid destruction request; but it is completely fair for
MultiPandoraApi::DeletePandoraInstances()to require correct input instead
Edited: Pandora was actually not allowing an exception escape a destructor, since
MultiPandoraApi::DeletePandoraInstances() is not a destructor. It was in fact
lar_pandora::LArPandora destructor which was careless in calling a throwing function without protection.