Project

General

Profile

Bug #1917

Event Mixing code has incorrect behavior when nSecondaries returns 0

Added by Rob Kutschke over 8 years ago. Updated over 8 years ago.

Status:
Closed
Priority:
Normal
Category:
Navigation
Target version:
Start date:
09/24/2011
Due date:
% Done:

100%

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

Description

In a common mode of operation, we choose the number of background events to mix into the current event by drawing a random variate from a Poisson distribution. This number is chosen by the nSecondaries() method of the mix detail class. When this method returns 0, the mixing template does the following:

1. The processEventIDs method of the mix detail class is correctly called with an input argument that has a length of 0.

2. All of the user registered mixOp methods are called with a stale input argument; the input argument points to the data from the previous event!

So there are two issues. First, the input argument to the mixOp methods should be a vector of length 0, not a stale vector. The subset of the data that I looked at appears to be an intact copy of the data from the previous event; I understand that this can be an accident but it seems prudent to make sure that the memory is not leaked.

Associated revisions

Revision b17fc5a7 (diff)
Added by Christopher Green over 8 years ago

Test for issue #1917.

Revision d59271de (diff)
Added by Christopher Green over 8 years ago

Test for issue #1917.

History

#1 Updated by Rob Kutschke over 8 years ago

I have added a stripped down mixing module to illustrate the problem
EventMixing/src/MixBug01_module.cc

and an fcl file to run it:

EventMixing/test/mixBug01.fcl

If you want to try this on oink you will have to copy the input event-data file.

#2 Updated by Rob Kutschke over 8 years ago

I have worked around this by saving the value of nSecondaries in member datum and just returning from mixOp methods that should never have been called. We should still fix this.

#3 Updated by Christopher Green over 8 years ago

  • Category set to Navigation
  • Status changed from New to Assigned
  • Assignee set to Christopher Green
  • Target version set to 0.07.16

The errant behavior has been observed in mu2e code; I will produce a test case and work on a fix for the 0.07.16 release.

#4 Updated by Christopher Green over 8 years ago

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

The issue was an unwanted protection around the per-event resize() of the container of incoming collections to be merged.

Fixed with d25d5de.

#5 Updated by Christopher Green over 8 years ago

  • Subject changed from Event Mixing code has incorrect behaving when nSecondaries returns 0 to Event Mixing code has incorrect behavior when nSecondaries returns 0

#6 Updated by Christopher Green over 8 years ago

  • Status changed from Resolved to Closed


Also available in: Atom PDF