Bug #940

Event display unable to gracefully pass

Added by Brian Rebel almost 10 years ago. Updated almost 10 years ago.

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


Estimated time:
Occurs In:
SSI Package:


I am running nova through the event display configuration, ie

nova -c /nova/app/users/brebel/artnova/test/job/evd.fcl /nova/app/users/brebel/artnova/test/job/cosmics_reco.root

which attempts to draw tracks stored in the cosmics_reco.root file. The drawing is done through EventDisplay/RecoBaseDrawer.cxx using the art::Event::getView() method to extract prongs from the event. The problem is that if no track was reconstructed for the event, the following message is emitted

nova: /home/greenc/work/cet-is/art-devel/art/Framework/Core/Schedule.h:400: void art::Schedule::processOneOccurrence(typename T::MyPrincipal&) [with T = art::OccurrenceTraits<art::EventPrincipal, (art::BranchActionType)0u>, typename T::MyPrincipal = art::EventPrincipal]: Assertion `action != actions::SkipEvent' failed.
Abort (core dumped)

The core dump appears to be generated by the art::Event::getView() failing to find any rb::Track collection in the event.

Associated revisions

Revision 879b74de (diff)
Added by Marc Paterno almost 10 years ago

Fix issue #940

Add new test for the issue, including a new analyzer
and a new service for testing.

Cleanup up layout of Schedule. Move the logic for writing
the summary to its own member function.
Add EndJobFailure error code, and use it.
Remove unwanted assertions and improve error messages.


#1 Updated by Marc Paterno almost 10 years ago

  • Category set to Event Loop
  • Status changed from New to Assigned
  • Assignee set to Marc Paterno
  • Priority changed from Normal to High

I have isolated the source of the failure. The member function EventDisplay::postProcessEvent is registered as a callback for the postProcessEvent signal. This function allows exceptions from code it calls to propagate out of the function. Because of the nature of the use of callback functions in art, the framework can not sensibly continue from such an exception, and the program will be shut down. The current failure because of an assertion was an attempt to identify a logic error, which attempt was incorrect (and will be fixed).

The important part of the solution for NOvA will be modification of the EventDIsplay::postProcessEvent function to prevent the emission of all but intentionally fatal exceptions.

Marc with work with Brian on implementing this solution.

#2 Updated by Marc Paterno almost 10 years ago

  • Status changed from Assigned to Resolved

Brian and I made the modifications to the NOvA event display code to prevent emission of non-fatal errors.

#3 Updated by Marc Paterno almost 10 years ago

If an exception is thrown from a callback while no module is active, the EventProcessor should now shut down cleanly, rather than aborting due to an assertion failure.

#4 Updated by Christopher Green almost 10 years ago

  • Status changed from Resolved to Reviewed

#5 Updated by Christopher Green almost 10 years ago

  • Target version set to 0.4.3
  • % Done changed from 0 to 100

#6 Updated by Christopher Green almost 10 years ago

  • Status changed from Reviewed to Closed

Also available in: Atom PDF