@@ -247,6 +247,50 @@ been received, you must either explicitly interrupt execution by throwing
247
247
});
248
248
}
249
249
250
+ What is a highly conclusive and simple way to find memory leaks (e.g. in pybind11 bindings)?
251
+ ============================================================================================
252
+
253
+ Use ``while True `` & ``top `` (Linux, macOS).
254
+
255
+ For example, locally change tests/test_type_caster_pyobject_ptr.py like this:
256
+
257
+ .. code-block :: diff
258
+
259
+ def test_return_list_pyobject_ptr_reference():
260
+ + while True:
261
+ vec_obj = m.return_list_pyobject_ptr_reference(ValueHolder)
262
+ assert [e.value for e in vec_obj] == [93, 186]
263
+ # Commenting out the next `assert` will leak the Python references.
264
+ # An easy way to see evidence of the leaks:
265
+ # Insert `while True:` as the first line of this function and monitor the
266
+ # process RES (Resident Memory Size) with the Unix top command.
267
+ - assert m.dec_ref_each_pyobject_ptr(vec_obj) == 2
268
+ + # assert m.dec_ref_each_pyobject_ptr(vec_obj) == 2
269
+
270
+ Then run the test as you would normally do, which will go into the infinite loop.
271
+
272
+ **In another shell, but on the same machine ** run:
273
+
274
+ .. code-block :: bash
275
+
276
+ top
277
+
278
+ This will show:
279
+
280
+ .. code-block ::
281
+
282
+ PID USER PR NI VIRT RES SHR S %CPU %MEM TIME+ COMMAND
283
+ 1266095 rwgk 20 0 5207496 611372 45696 R 100.0 0.3 0:08.01 test_type_caste
284
+
285
+ Look for the number under ``RES `` there. You'll see it going up very quickly.
286
+
287
+ **Don't forget to Ctrl-C the test command ** before your machine becomes
288
+ unresponsive due to swapping.
289
+
290
+ This method only takes a couple minutes of effort and is very conclusive.
291
+ What you want to see is that the ``RES `` number is stable after a couple
292
+ seconds.
293
+
250
294
CMake doesn't detect the right Python version
251
295
=============================================
252
296
0 commit comments