Project

General

Profile

Bug #14891

pandora exception triggered by configuration error

Added by Giuseppe Cerati over 3 years ago. Updated over 3 years ago.

Status:
Closed
Priority:
Normal
Category:
External Packages
Target version:
-
Start date:
12/27/2016
Due date:
% Done:

100%

Estimated time:
Spent time:
Occurs In:
Experiment:
-
Co-Assignees:
Duration:

Description

Recipe:

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

Output:

terminate called after throwing an instance of 'pandora::StatusCodeException'
Aborted

Associated revisions

Revision b75736cd (diff)
Added by Gianluca Petrillo over 3 years ago

Pandora driver modules don't try to delete an unexisting pandora any more.

This solves issue #14891 .

Revision b2881955 (diff)
Added by Gianluca Petrillo over 3 years ago

Pandora driver modules don't try to delete an unexisting pandora any more.

This solves issue #14891 .

History

#1 Updated by Giuseppe Cerati over 3 years ago

  • Subject changed from andora exception triggered by configuration error to pandora exception triggered by configuration error

#2 Updated by Gianluca Petrillo over 3 years ago

  • Category set to Setup / Environment
  • Status changed from New to Assigned
  • Assignee set to Gianluca Petrillo

I can reproduce the problem.

#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:

  1. a Pandora-driving module instance is constructed (in this case, was MicroBooNEPandora)
  2. a module throws an exception during construction (for example, a configuration error from Track3DKalmanHit)
  3. art intercepts the exception and asks all the constructed modules to destroy
  4. the Pandora-driving module throws an exception during destruction
  5. in this state (already at exception handling), the additional exception immediately calls terminate()

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 BeginJob() stage.

The problems:

  1. the module should not attempt to destroy Pandora before it has been initialised; this is fixed with commit larpandora:b75736cd37c13422f1d2d932cfa49e6461fe2db7
  2. Pandora should not allow exceptions to escape from destructors; the reason is apparent in the reported behaviour
  3. 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.

#4 Updated by Gianluca Petrillo over 3 years ago

  • Status changed from Assigned to Resolved

#5 Updated by Gianluca Petrillo over 3 years ago

With the fix, in the reported test case the configuration exception is correctly printed on screen, and the job is ended gracefully.

#6 Updated by Tingjun Yang over 3 years ago

Thanks for solving this puzzle.

#7 Updated by Gianluca Petrillo over 3 years ago

  • Status changed from Resolved to Closed


Also available in: Atom PDF