GitLab

The tests are failing running under valgrind now, because it detects memory leaks. To reproduce run

TEST_NAMES=test_gobject make -C /home/pexbot/.build-master/linux-x86_64/__root__/pexip/external/pygobject/tests/ check.valgrind

The leak:

==13836== 360 bytes in 15 blocks are definitely lost in loss record 1,438 of 2,554
==13836==    at 0x4C28C20: malloc (in /usr/lib/valgrind/vgpreload_memcheck-amd64-linux.so)
==13836==    by 0xBC21223: g_malloc (gmem.c:94)
==13836==    by 0xBC346B6: g_slice_alloc (gslice.c:1025)
==13836==    by 0xBC34915: g_slice_alloc0 (gslice.c:1051)
==13836==    by 0xB548E8B: _pygi_boxed_alloc (pygi-boxed.c:87)
==13836==    by 0xB548FDC: _boxed_new (pygi-boxed.c:111)
==13836==    by 0x4BC7A4: type_call.lto_priv.89 (typeobject.c:729)
==13836==    by 0x4CCB9A: PyObject_Call (abstract.c:2529)
==13836==    by 0x4CCB9A: do_call (ceval.c:4251)
==13836==    by 0x4CCB9A: call_function (ceval.c:4056)
==13836==    by 0x4CCB9A: PyEval_EvalFrameEx (ceval.c:2679)
==13836==    by 0x4CA8B0: PyEval_EvalCodeEx (ceval.c:3265)
==13836==    by 0x4CD97B: fast_function (ceval.c:4129)
==13836==    by 0x4CD97B: call_function (ceval.c:4054)
==13836==    by 0x4CD97B: PyEval_EvalFrameEx (ceval.c:2679)
==13836==    by 0x4E62E7: PyEval_EvalCodeEx (ceval.c:3265)
==13836==    by 0x4E62E7: function_call.lto_priv.290 (funcobject.c:526)
==13836==    by 0x4CF783: PyObject_Call (abstract.c:2529)
==13836==    by 0x4CF783: ext_do_call (ceval.c:4346)
==13836==    by 0x4CF783: PyEval_EvalFrameEx (ceval.c:2718)
==13836==    by 0x4E62E7: PyEval_EvalCodeEx (ceval.c:3265)
==13836==    by 0x4E62E7: function_call.lto_priv.290 (funcobject.c:526)
==13836==    by 0x504D47: PyObject_Call (abstract.c:2529)
==13836==    by 0x504D47: instancemethod_call.lto_priv.209 (classobject.c:2602)
==13836==    by 0x56F89C: PyObject_Call (abstract.c:2529)
==13836==    by 0x56F89C: slot_tp_call.lto_priv.1130 (typeobject.c:5432)
==13836==    by 0x4CCB9A: PyObject_Call (abstract.c:2529)
==13836==    by 0x4CCB9A: do_call (ceval.c:4251)
==13836==    by 0x4CCB9A: call_function (ceval.c:4056)
==13836==    by 0x4CCB9A: PyEval_EvalFrameEx (ceval.c:2679)
==13836==    by 0x4CA8B0: PyEval_EvalCodeEx (ceval.c:3265)
==13836==    by 0x4CD97B: fast_function (ceval.c:4129)
==13836==    by 0x4CD97B: call_function (ceval.c:4054)
==13836==    by 0x4CD97B: PyEval_EvalFrameEx (ceval.c:2679)
==13836==    by 0x4E62E7: PyEval_EvalCodeEx (ceval.c:3265)
==13836==    by 0x4E62E7: function_call.lto_priv.290 (funcobject.c:526)
==13836==    by 0x4CF783: PyObject_Call (abstract.c:2529)
==13836==    by 0x4CF783: ext_do_call (ceval.c:4346)
==13836==    by 0x4CF783: PyEval_EvalFrameEx (ceval.c:2718)
==13836== 
==13836== LEAK SUMMARY:
==13836==    definitely lost: 360 bytes in 15 blocks
==13836==    indirectly lost: 0 bytes in 0 blocks
==13836==      possibly lost: 125,472 bytes in 247 blocks
==13836==    still reachable: 4,215,917 bytes in 8,409 blocks
==13836==                       of which reachable via heuristic:
==13836==                         length64           : 40 bytes in 1 blocks
==13836==                         newarray           : 1,552 bytes in 17 blocks
==13836==         suppressed: 0 bytes in 0 blocks
==13836== Reachable blocks (those to which a pointer was found) are not shown.
==13836== To see them, rerun with: --leak-check=full --show-leak-kinds=all

I run bisect and found that the leak was introduced in this commit d08e244d. The commit before does not have it. I talked to @mathieudu about it and he asked to assign him to this issue.