Bug #1494

Trying to load nonexistent ParameterSet entries in module constructor terminates with no feedback

Added by Christopher Backhouse about 9 years ago. Updated about 9 years ago.

Target version:
Start date:
Due date:
% Done:


Estimated time:
Occurs In:
SSI Package:


We have several modules that use this pattern to load their configuration:

MyModule::MyModule(const fhicl::ParameterSet& pset)
: fMyParam(pset.get<int>("MyParam")) {

If one of these statements fails, because the parameter isn't defined in the fcl file, or the types don't match, then the job aborts with no output, all I see is:

++ constructing module:mymodule

Using gdb, I see that a fhicl::exception is thrown here, and then caught in Framework/Core/, where there is code that appears to intend to print it, but I don't see any output.

It would aid debugging if jobs didn't fail silently in this case.


#1 Updated by Christopher Green about 9 years ago

  • Category set to Infrastructure
  • Status changed from New to Feedback
  • Assignee set to Christopher Green

Hi Chris,

Unfortunately, the simple attempt to reproduce your observed problem with ART v0.07.04 does not succeed, viz:

arttest::MixAnalyzer::MixAnalyzer(fhicl::ParameterSet const &p)
  nSecondaries_(p.get<size_t>("numSecondaries", 1)),

      module_type: MixAnalyzer
      numSecondaries: 5
#      mixFilterLabel: mixFilter

  e1: [ mixAnalyzer ]
  end_paths: [ e1 ]

%MSG-i MF_INIT_OK:  art 22-Jul-2011 11:29:58 CDT JobSetup
Messagelogger initialization complete.
22-Jul-2011 11:29:59 CDT  Initiating request to open file ../ProductMix_r1.d/out.root
22-Jul-2011 11:30:00 CDT  Successfully opened file ../ProductMix_r1.d/out.root
%MSG-s ArtException:  MixAnalyzer:mixAnalyzer@Construction  22-Jul-2011 11:30:00 CDT ModuleConstruction
cet::exception caught in art
---- Can't find key BEGIN
---- Can't find key END


Please let me know how I can run exactly the .fcl which reproduces the problem for you, preferably against checked-in code if possible; otherwise please provide the module header, source and module files as an attachment to the issue or an email.

#2 Updated by Christopher Green about 9 years ago

From email updates by Chris B.:

I just ran into this again, with a different exception, and this time I am able to consistently reproduce it:

$ source /grid/fermiapp/nova/novaart/novasoft/setup/ -r S11.07.27

$ nova -c cosmictrackjob.fcl /nova/data/mc/S11.06.14/genie/ndos/sim_genie_nhc_simpleflux_swapping_none_ndos_10000_0.root

using gdml file /grid/fermiapp/nova/novaart/novasoft/releases/S11.07.27/Geometry/gdml/ndos.gdml for geometry
using root file /grid/fermiapp/nova/novaart/novasoft/releases/S11.07.27/Geometry/gdml/ndos.root for geometry
Detector geometry loaded from /grid/fermiapp/nova/novaart/novasoft/releases/S11.07.27/Geometry/gdml/ndos.gdml
++ constructing module:calhit
++ construction finished:calhit
++ constructing module:slicer
++ construction finished:slicer
++ constructing module:cosmictrack
++ construction finished:cosmictrack
++ constructing module:TriggerResults
++ construction finished:TriggerResults
++ constructing module:out1
++ construction finished:out1
++ beginJob module:calhit
++ beginJob finished:calhit
++ beginJob module:slicer
++ beginJob finished:slicer
++ beginJob module:cosmictrack
++ beginJob finished:cosmictrack
++ beginJob module:TriggerResults
++ beginJob finished:TriggerResults
++ beginJob module:out1
++ beginJob finished:out1
++ Job started
++++open input file
++++finished: open input file /nova/data/mc/S11.06.14/genie/ndos/sim_genie_nhc_simpleflux_swapping_none_ndos_10000_0.root
++ endJob module:calhit
++ endJob finished:calhit
++ endJob module:slicer
++ endJob finished:slicer
++ endJob module:cosmictrack
++ endJob finished:cosmictrack
++ endJob module:TriggerResults
++ endJob finished:TriggerResults
++ endJob module:out1
++ endJob finished:out1
++ Job ended

Under gdb, I see an exception raised:

0x00002aaab28c3cda in (anonymous namespace)::RootErrorHandler (level=2000,
    die=false, location=0x2aaaad4f63e6 "TTreeCloner::CollectBranches",
    message=0x669880 "The export branch and the import branch do not have the same streamer type. (The branch name is rawdata::RawDigits_daq__MCxxDAQ.obj.fMCBits.)")

The exception is expected. This input file is incompatible with the release I set up. I have seen this message successfully printed before, so I don't know what the difference is this time.

gdb shows the exception being caught again in art/Framework/Core/ but for whatever reason I don't see the message.

#3 Updated by Christopher Green about 9 years ago

  • Status changed from Feedback to Resolved
  • % Done changed from 0 to 100

I have traced the source of this behavior.

The exception is output, but due to a quirk of your .fcl file it is being hidden away, in warnings.log.

By specifying explicitly:

services.message: {}
you are disabling the default configuration of the message logger in favor of an empty one, meaning that output may go to cerr.log (prior to message facility initialization or after tear-down) or warnings.log. The use of the timing module (services.Timing: {}) tracing and summary (services.scheduler: { wantTracer: true wantSummary: true }) may also be contributing to the hiding of the exception.

In summary: the solution is:

  1. To either specify no message facility configuration at all; or explicitly specify the one you want; and
  2. Only use tracing, message summaries and the timing module where you are sure they will be useful.

#4 Updated by Christopher Green about 9 years ago

  • Status changed from Resolved to Closed

Also available in: Atom PDF