Project

General

Profile

Bug #1952

Memory leak and bug in Global Track Matching

Added by Rogers, Chris over 4 years ago. Updated over 4 years ago.

Status:
Closed
Priority:
Normal
Assignee:
Category:
Global Reconstruction
Target version:
-
Start date:
26 January 2018
Due date:
% Done:

100%

Estimated time:
Workflow:
New Issue

Description

Two problems:

  1. Global track matching had a memory leak
  2. Through tracks were dying for some reason.

Both have the same root cause; the error handling during track extrapolation was not well handled. This meant that for those tracks with no downstream detectors, track extrapolation failed at the EMR (energy loss causes track to stop and throw exception) so the gsl_odeiv_blah stuff was not freed correctly and the track was lost, where it should have been stored.


Files

maus_resource_usage.png (7.38 KB) maus_resource_usage.png Rogers, Chris, 26 January 2018 17:30
#1

Updated by Rogers, Chris over 4 years ago

I made a fix. Because the exception mechanism is a bit slow anyway, I changed from an exception-style error handling to a return code style of error handling during the tracking; and let the TrackMatching class sort it out. I did this both in my new code and in Jan's track propagation code. I also made some tweaks to the way the track propagation was done - it was sometimes missing out TOF0 during back propagations, owing to darkness and sinister evil.

Pushed to lp:~chris-rogers/maus/track-matching-tweaks. I ran a moderate test job - 1000 spills (3000 DAQ events). Memory usage:

so roughly 300 MB per 1000 spills. Typical runs are ~ 5000 spills so this may be tolerable? I guess this was pre-existing leak, unless some one tells me otherwise.

I ran the data through my analysis scripts and things look more reasonable than previously - i.e. a few % of events fail the track extrapolation, transmission is ~ 75 % for 10 mm beam (not 100 % like before!).

#2

Updated by Rogers, Chris over 4 years ago

Just finished running reco over a full run (10486) with final rsz 2427652 kB = 2.4 GB ... another memory leak or is this normal?

#3

Updated by Rogers, Chris over 4 years ago

  • Status changed from Open to Closed
  • % Done changed from 0 to 100

No one is complaining so I guess this is fixed.

Also available in: Atom PDF