Project

General

Profile

Bug #2332

mu2e dumpDataProducts crash

Added by Andrei Gaponenko almost 8 years ago. Updated almost 8 years ago.

Status:
Closed
Priority:
Normal
Category:
I/O
Target version:
Start date:
12/19/2011
Due date:
% Done:

100%

Estimated time:
Occurs In:
Scope:
Internal
Experiment:
-
SSI Package:
Duration:

Description

Dear Experts,

One of my jobs wrote out a data file that can't be checked with
the mu2e "standard" dumpDataProducts job:

bash$ mu2e -c Analyses/test/dumpDataProducts.fcl -s vd16v4.unreadable.root
Segmentation fault (core dumped)

The job that produced the "unreadable" file was successful, I did not
notice any exceptions and the exit code was zero. This is reproducible.

Can you please fix the data file inspection code?

I put the "unreadable" file at

/afs/fnal.gov/files/home/room3/gandr/unreadable-test-case/vd16v4.unreadable.root

The file should contain 200 events, each holding a default-constructed
copy of StepPointMCCollection. The filter module source and config
files are in the same directory, along with the data_extMonFNAL.root
file that was used as an input to the "filtering" job.

Andrei

g4keep.fcl (1.73 KB) g4keep.fcl Dumper work on the output of this script. Andrei Gaponenko, 12/20/2011 10:20 AM
g4drop.fcl (1.76 KB) g4drop.fcl Dumper crashes on the output file Andrei Gaponenko, 12/20/2011 10:20 AM
FilterVDHits_module.cc (2.52 KB) FilterVDHits_module.cc The (rudimentary) filter source. Andrei Gaponenko, 12/20/2011 10:20 AM

Related issues

Has duplicate art - Bug #2343: file merge crashClosed12/27/2011

Associated revisions

Revision 9b5c4b5a (diff)
Added by Christopher Green almost 8 years ago

Modify tests to detect issue #2332.

History

#1 Updated by Andrei Gaponenko almost 8 years ago

Hi,

Here is more information about the problem. I prepared two .fcl files
that differ by only one line (barring the trivial arbitrary-name
differences): the g4drop.fcl has the "drop _virtualdetector*"
command added. That data product is preserved in g4keep.fcl (but
several other ones are dropped in both cases).

The output file produced by "mu2e -c Mu2eG4/test/g4keep.fcl"
can be analyzed by with Analyses/test/dumpDataProducts.fcl.

The output file produced by "mu2e -c Mu2eG4/test/g4drop.fcl"
causes the the dumper job to crash.

The "virtualdetector" product is special because it is used as an
input by the filter. That is, it looks like we can add compressed
version of a product to the event, but are not allowed to drop the
original uncompressed version after it.

All the files that are needed to reproduce that are attached to the
issue. I am working on top of the official mu2e CVS HEAD, with
the last commit by Rob on 2011-12-16 17:18:41 "Add items 14 through 17".

Andrei

#2 Updated by Andrei Gaponenko almost 8 years ago

The feature request #2325 is related to this issue, may be they both can be solved together.

Andrei

#3 Updated by Christopher Green almost 8 years ago

  • Category set to I/O
  • Status changed from New to Assigned
  • Assignee set to Christopher Green

This problem is being investigated.

#4 Updated by Christopher Green almost 8 years ago

  • % Done changed from 0 to 10

This issue is confirmed as a bug wherein the metadata for files from which products have been dropped is incorrect. Further characterization will, I'm afraid, have to wait until the new year.

Unfortunately, this issue is not related in any way to issue #2325: a file with incorrect metadata such as this will be unreadable for any purpose, not just by the product dumper.

Can you tell me how many products you expected to keep, and what they were?

For now, please try to avoid dropping products from your files. If however, you have a file with definitely-dropped products that can still be read successfully, we would be happy to hear about it.

Thanks,
Chris.

#5 Updated by Andrei Gaponenko almost 8 years ago

Hi Chris,

Yes, I am able to read files with dropped data products. (Those that crash the dumper.) It is very good to have your confirmation that the data I read should be valid and the fact that my reading jobs do not crash is not an accident.

Can you tell me how many products you expected to keep, and what they were?

Well, my current .fcl file has:

    outputCommands:   [ "keep *_fvd16_*_*" ]

that is, I only want to keep data products made by a specific (filter) module and not write out anything else. I've been producing a StepPointMCCollection, have just added a SimParticleCollection and still have to see if the reading continues to work.

Thank you,
Andrei

#6 Updated by Andrei Gaponenko almost 8 years ago

Just noticed that a part of my previous update was gobbled up by the formatter. Try again:

    outputCommands:   [ "keep *_fvd16_*_*" ]

#7 Updated by Christopher Green almost 8 years ago

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

The problem has been characterized, isolated, understood and fixed with 3781450.

Regression tests are now in ART to ensure the ongoing good behavior of the restored feature.

Basically, the problem was only triggered if one dropped a product that had children (if a module reads product A and puts product B into the event, then A is a parent of B). In this case, the metadata for the product was written to the file even though the data product itself was not. If a product with no children is dropped (which is what our tests did initially) then the metadata are dropped also and there is no problem.

In the case where the metadata are retained but the product is not, upon reading the file the RootInputFile must update the metadata to indicate that the branch is missing before that branch is read from the event (or run, or subrun) tree. This code had not survived the IO changes between 0.07.16 and 1.00.00. Equivalent functionality has been restored with 3781450.

The good news is that files that were written with faulty ART versions will be readable automatically when the fix is released since the problem was in the reading, not the writing.

Apologies for the inconvenience caused by this bug.

#8 Updated by Christopher Green almost 8 years ago

  • Target version set to 1.00.07

#9 Updated by Christopher Green almost 8 years ago

  • Status changed from Resolved to Closed


Also available in: Atom PDF