Project

General

Profile

Bug #16448

art should throw if Assns<A,B> is declared but Assns<B,A> is put

Added by Kyle Knoepfel about 3 years ago. Updated about 3 years ago.

Status:
Closed
Priority:
Normal
Assignee:
Kyle Knoepfel
Category:
Infrastructure
Target version:
2.07.01
Start date:
05/08/2017
Due date:
% Done:

100%

Estimated time:
Spent time:
8.00 h
Occurs In:
Scope:
Internal
Experiment:
-
SSI Package:
art
Duration:

Description

An issue recently arose in MicroBooNE where the following was declared in the producer's c'tor:

produces&lt;Assns&lt;recob::Track,recob::Vertex&gt;&gt;();

but an Assns<recob::Vertex,recob::Track> product was placed onto the event. This can cause problems for looking up the Assns product later in the same job.

Resolving this issue is not trivial--it requires understanding how the friendlyClassName of an Assns product is created and, consequently, how that should affect the product-checking done during the Event::commit stage.

History

#1 Updated by Kyle Knoepfel about 3 years ago

  • Status changed from New to Accepted

After discussion, there may be some inconsistencies with how the friendly class names are formed. Even if those inconsistencies are resolved, significant backwards compatibility issues arise. We will, therefore, discuss this at a later time.

#2 Updated by Kyle Knoepfel about 3 years ago

Inconsistencies in creating the friendly class name have been resolved with commit canvas:22a96e7. The issue was that for testing, the classes A and B were defined in an anonymous namespace. The friendly name of each class is therefore (anonymous namespace)::A. When that pattern is presented to the regex parser, the open parenthesis indicates the beginning of a group. The solution is to escape all parentheses.

In practice, this is unlikely to have been a problem because the context in which friendlyClassName() is called does not involve classes defined in an anonymous namespace. However, this inconsistency has at least been resolved. If this ever becomes necessary, the (e.g.) (anonymous namespace):: prefix will need to be replaced with something suitable for a ROOT file branch name.

The problem of detecting when an Assns<B,A> is placed onto the event instead of an Assns<A,B> has yet to be solved.

#3 Updated by Kyle Knoepfel about 3 years ago

  • Category set to Infrastructure
  • Status changed from Accepted to Resolved
  • Assignee set to Kyle Knoepfel
  • Target version set to 1209
  • % Done changed from 0 to 100
  • SSI Package art added

The solution was to replace BranchID-based product checking with TypeLabel-based checking. Unfortunately, a TypeLabel is larger in size than a BranchID, but it was partially mitigated by removing the BranchType member from the TypeLabel. It is now an error for an Assns product with reversed template parameters (with respect to the produces<> call) to be placed onto an event.

With this commit, the following error is also detected:

MyProducer::MyProducer(Parameters const&)
{
  produces<A,B>()
  produces<B,A>()
}

In this circumstance, an exception will be thrown that looks like:

cet::exception caught in art
---- LogicError BEGIN
  check_for_duplicate_Assns: An attempt has been made to call the equivalent of

     produces<art::Assns<B,A,void>>("")

  which results in a prepared ("friendly") name of:

     ABvoidart::Assns

  That friendly name has already been registered for this module.
  Please check to make sure that produces<> has not already been
  called for an Assns<> with reversed template arguments.  Such
  behavior is not supported.  Contact artists@fnal.gov for guidance.
---- LogicError END

Implemented with commit art:801c3bc9.

#4 Updated by Kyle Knoepfel about 3 years ago

  • Target version changed from 1209 to 2.07.01

#5 Updated by Kyle Knoepfel about 3 years ago

  • Status changed from Resolved to Closed

Also available in: Atom PDF