Bug #1909
Memory leak in PyGlobalErrorTracking
Start date:
12 February 2017
Due date:
% Done:
100%
Estimated time:
Workflow:
New Issue
Description
Patch
PyErr_SetString(PyExc_RuntimeError, (&exc)->what()); return NULL; } - // who owns memory? + // py_centroid/py_ellipse own all of their memory py_centroid = set_centroid(x_in); py_ellipse = set_variance(x_in); + // initialises with a refcnt 1 PyObject* ret_tuple = Py_BuildValue("OO", py_centroid, py_ellipse); - return ret_tuple; + // py_centroid and py_ellipse are initialised with a ref count = 1; + // BuildValue then adds a ref count; but only ret_tuple holds a reference + Py_DECREF(py_centroid); + Py_DECREF(py_ellipse); + return ret_tuple; //ret_tuple; }
Files
Updated by Rogers, Chris over 6 years ago
- File maus_resource_usage.png maus_resource_usage.png added
Resubmitted to test - minor style error and infinite loop in the unit test (oops).
Attached resource usage for tracking roughly 1200k tracks along the cooling channel. Note there is a slight leak, this is because I rebuild the field maps every ~ 4k events (I am doing a beam-based alignment). I don't think it is a leak in the tracking routines.
Note this took about 12 hours on my laptop running single threaded, so roughly 100k tracks per hour per core. Is that fast enough?
Updated by Rogers, Chris over 6 years ago
- Status changed from Open to Closed
- % Done changed from 0 to 100
Pushed to trunk