Project

General

Profile

Bug #18626

new run-time dictionary error in v2_09_03

Added by Raymond Culbertson almost 2 years ago. Updated almost 2 years ago.

Status:
Closed
Priority:
Normal
Assignee:
Category:
I/O
Target version:
Start date:
12/27/2017
Due date:
% Done:

100%

Estimated time:
Spent time:
Occurs In:
Scope:
Internal
Experiment:
Mu2e
SSI Package:
art
Duration:

Description

Below is a error that only appears when mu2e uses art v2_09_03.
Below that, is how to reproduce it.
The error is that a class, KalRep, does not have a default constructor
so it can't be written and read back. I believe this class has
never had a default constructor and is not written out. In any case,
the same code runs without warning or error in v2_07_03 but error exits
in v2_09_03.
I'm not sure what dictionaries are generated since it does not appear
directly in classes_def.xml, but it does appear indirectly,
in art::Ptr<KalRep> and other ways, sometimes with "persistant=false".
It might be that this problem was always there and it was
just elevated to fatal, but we did not see it even as a warning before,
with v2_07_03.
Questions on how the code is designed and used should go to
. The class itself is in the BTrk product
$BTRK_INC/BTrk/KalmanTrack/KalRep.hh

during start up we get this warning

%MSG
%MSG-w TransientBranch: PostProcessEvent 26-Dec-2017 14:04:58 CST run: 1 subRun: 0 event: 1
BranchDescription::fluffTransients() called for the non-persistable
entity: KalRepart::Ptrs. Please check your experiment's policy
on the advisability of such products.

then the exe ends with

cet::exception caught in art
---- OtherArt BEGIN
---- FatalRootError BEGIN
Fatal Root Error: @SUB=TBufferFile::WriteObjectAny
since KalRep has no public constructor
which can be called without argument, objects of this class
can not be read with the current library. You will need to
add a default constructor before attempting to read it.
---- FatalRootError END
---- OtherArt BEGIN
---- FatalRootError BEGIN
Fatal Root Error: @SUB=TTree::SetEntries
Tree branches have different numbers of entries, with 1 maximum.
---- FatalRootError END
---- OtherArt END
---- OtherArt END
%MSG
Art has completed and will exit with status 1.

To reproduce, on any machine with /cvmfs/mu2e.opensciencegrid.org,

source /cvmfs/mu2e.opensciencegrid.org/setupmu2e-art.sh
git clone http://cdcvs.fnal.gov/projects/mu2eofflinesoftwaremu2eoffline/Offline.git
cd Offline
git checkout -b temp XYZ
source setup.sh
scons -j 20 >& build.log
mu2e -c Analyses/test/genReco.fcl

with XYZ being:
commit 9264edca8cae for working version in art v2_07_03
and 8e868ddf038 (branch art_v2_09_03) for error version in v2_09_03
The difference between these commits should only be technical
fixes for differences in art versions. You might notice the BTrk product
versions are different, but again the only difference is
technical changes following art and root versions.

History

#1 Updated by Kyle Knoepfel almost 2 years ago

  • Status changed from New to Assigned
  • Assignee set to Kyle Knoepfel

The failure has been reproduced. At this point, it is not clear what the cause of it is. Investigation continues.

#2 Updated by Kyle Knoepfel almost 2 years ago

Problem summary

The problem is understood. This is not a bug with Mu2e code; this is an art bug.

ROOT has allowed users to specify "persistent=false" in their classes_def.xml selection files for some time. This has provided a means of notifying both art and ROOT of not persisting objects of a given class type. art's ROOT I/O system is designed such that products whose persistent flag is set to false are not entered into the list of products to be written to disk. With art series 2.09, a product's persistence bit is unintentionally checked before it is set. This must be re-ordered.

Guidance for the future

Please do not add default c'tors for the product in question if it does not make sense to do so. Had Mu2e provided a dummy default c'tor, we may not have caught this bug as easily. My preference would be to issue an art version 2.09.04 that resolves this bug. Is that acceptable to you?

Within the next few weeks, we intend to release a version of art where users will be able to declare products as in-memory only:

produces<KalRepCollection>("finalColl", ProductFlavor::InMemoryOnly);

obviating the need for even declaring the KalRepCollection class in the classes_def.xml file.

#3 Updated by Kyle Knoepfel almost 2 years ago

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

Fix implemented with commit art:684b30c. In the meantime, a workaround is to explicitly "drop" the products--i.e. one can add the following lines to ensure that no ROOT I/O operations will take place:

outputs: {
  detectorOutput: {
    fileName: "genReco.art" 
    module_type: RootOutput
    outputCommands: [
      "keep *_*_*_*",                     # ("keep *_*_*_*" can be abbreviated to "keep *")
      "drop KalRepart::Ptrs_*_*_*",                                # normally not necessary
      "drop KalRepart::Ptrmu2e::TrackSummaryvoidart::Assns_*_*_*", # normally not necessary
      "drop KalRepmu2e::OwningPointerCollection_*_*_*",            # normally not necessary
      "drop mu2e::PhysicalVolumeInfomvstd::pairs_g4run_*_*" 
    ]
  }
}

Please advise whether you would like an art 2.09.04 version, or if you prefer to wait for an art 2.10 series, which is due to come out in a couple weeks' time. My preference is to make the bug-fix release, but I defer to your judgment.

#4 Updated by Kyle Knoepfel almost 2 years ago

  • Project changed from cet-is to art
  • Category set to I/O
  • Occurs In 2.09.03 added
  • SSI Package art added

#5 Updated by Kyle Knoepfel almost 2 years ago

  • Target version set to 2.09.04

#6 Updated by Kyle Knoepfel almost 2 years ago

  • Status changed from Resolved to Closed


Also available in: Atom PDF