Bug #14430

Art v2_05_00 failed assertion.

Added by Herbert Greenlee about 4 years ago. Updated almost 4 years ago.

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


Estimated time:
Spent time:
Occurs In:
SSI Package:


$ lar -c copy.fcl -s ~greenlee/crash.root
04-Nov-2016 13:31:21 CDT  Initiating request to open input file "/nashome/g/greenlee/crash.root" 
04-Nov-2016 13:31:23 CDT  Opened input file "/nashome/g/greenlee/crash.root" 
04-Nov-2016 13:31:28 CDT  Opened output file with pattern "%ifb_%tc_merged.root" 
%MSG-w FastCloning:  PostSourceSubRun 04-Nov-2016 13:31:29 CDT PostBeginRun
Fast cloning deactivated for this input file due to ROOT version used to write it (< 6.00/01)
having a different splitting policy.
lar: /scratch/workspace/nu-release-build/v2_06_02/s43-e10/debug/build/art/v2_05_00/src/art/Framework/IO/Root/ void {anonymous}::maybeInvalidateRangeSet(art::BranchType, const art::RangeSet&, art::RangeSet&): Assertion `!principalRS.ranges().empty()' failed.

Seems to be related to reading older format data.

Here's the complete fcl file:

$ cat copy.fcl
process_name: Copy

  module_type: RootInput
  maxEvents:  10        # Number of events to create


 #define the output stream, there could be more than one if using filters 
 stream1:  [ out1 ]
 #end_paths is a keyword and contains the paths that do not modify the art::Event, 
 #ie analyzers and output streams.  these all run simultaneously
 end_paths:     [ stream1 ]  

   module_type: RootOutput
   fileName:    "merged.root" 
   compressionLevel: 1

Related issues

Related to art - Bug #13564: Assertion failure on maybeInvalidateRangeSet(): Assertion `!principalRS.ranges().empty()' failed.Closed08/16/2016

Has duplicate uBooNE code - Bug #14401: Art v2_05_00 failed assertion.Closed11/04/2016

Associated revisions


#1 Updated by Lynn Garren about 4 years ago

Is this issue addressed by #14378?

#2 Updated by Herbert Greenlee about 4 years ago

Upon further investigation, this assertion first appeared in larsoft v06_04_00 (art v2_03_00). Therefore, this is not consistent with issue #14378.

Note that the program only crashes if you run using the debug build. In the prof build, which has assertions disabled, the program runs and there are no unusual error messages (but who knows if it is working correctly).

#3 Updated by Kyle Knoepfel about 4 years ago

  • Related to Bug #13564: Assertion failure on maybeInvalidateRangeSet(): Assertion `!principalRS.ranges().empty()' failed. added

#4 Updated by Gianluca Petrillo about 4 years ago

  • Has duplicate Bug #14401: Art v2_05_00 failed assertion. added

#5 Updated by Christopher Green about 4 years ago

  • Description updated (diff)
  • Status changed from New to Feedback
  • Assignee set to Christopher Green
  • Target version set to 2.06.00
  • SSI Package art added
  • SSI Package deleted ()

What is the latest version / qualifier set of uboone code with which this can this be reproduced, please?

#6 Updated by Christopher Green about 4 years ago

  • Status changed from Feedback to Assigned

I have successfully reproduced the failure with uboonecode v06_13_01 (art v2_05_00). Working now.

#7 Updated by Christopher Green about 4 years ago

  • Status changed from Assigned to Resolved
  • % Done changed from 0 to 100
After analysis, we have determined that the assert() that is firing in this case is erroneous in the specific case, and overly paranoid in the general. For the upcoming release we will remove the assert; in the meantime a suitable workaround would be to use the profile build for files that:
  1. are produced by art < 2.01.00; and
  2. contain runs and/or subruns that are empty of events.

Resolved with d763c7d.

#8 Updated by Kyle Knoepfel almost 4 years ago

  • Status changed from Resolved to Closed

Also available in: Atom PDF