Skip to content
GitLab
Projects Groups Topics Snippets
  • /
  • Help
    • Help
    • Support
    • Community forum
    • Submit feedback
    • Contribute to GitLab
  • Register
  • Sign in
  • pygobject pygobject
  • Project information
    • Project information
    • Activity
    • Labels
    • Members
  • Repository
    • Repository
    • Files
    • Commits
    • Branches
    • Tags
    • Contributor statistics
    • Graph
    • Compare revisions
  • Issues 178
    • Issues 178
    • List
    • Boards
    • Service Desk
    • Milestones
  • Merge requests 28
    • Merge requests 28
  • CI/CD
    • CI/CD
    • Pipelines
    • Jobs
    • Artifacts
    • Schedules
  • Deployments
    • Deployments
    • Environments
    • Releases
  • Packages and registries
    • Packages and registries
    • Container Registry
    • Model experiments
  • Monitor
    • Monitor
    • Incidents
  • Analytics
    • Analytics
    • Value stream
    • CI/CD
    • Repository
  • Activity
  • Graph
  • Create a new issue
  • Jobs
  • Commits
  • Issue Boards
Collapse sidebar
  • GNOMEGNOME
  • pygobjectpygobject
  • Issues
  • #176

Memory leaks detected by valgrind

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.

Assignee
Assign to
Time tracking