Project

General

Profile

Bug #1909

Memory leak in PyGlobalErrorTracking

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

Status:
Closed
Priority:
Normal
Assignee:
Category:
Python API
Target version:
-
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

maus_resource_usage.png (5.77 KB) maus_resource_usage.png Rogers, Chris, 13 February 2017 06:46
#1

Updated by Rogers, Chris over 6 years ago

Now in test...

#2

Updated by Rogers, Chris over 6 years ago

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?

#3

Updated by Rogers, Chris over 6 years ago

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

Pushed to trunk

Also available in: Atom PDF