Bug #1952
Memory leak and bug in Global Track Matching
100%
Description
Two problems:
- Global track matching had a memory leak
- 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
Updated by Rogers, Chris about 5 years ago
- File maus_resource_usage.png maus_resource_usage.png added
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!).
Updated by Rogers, Chris about 5 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?
Updated by Rogers, Chris almost 5 years ago
- Status changed from Open to Closed
- % Done changed from 0 to 100
No one is complaining so I guess this is fixed.