Memory leak and bug in Global Track Matching
- 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.
Updated by Rogers, Chris about 6 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.
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!).