Issue 13089: parsetok.c: memory leak (original) (raw)

Issue13089

Created on 2011-10-02 08:50 by skrah, last changed 2022-04-11 14:57 by admin. This issue is now closed.

Messages (3)
msg144763 - (view) Author: Stefan Krah (skrah) * (Python committer) Date: 2011-10-02 08:50
Seen in test_mailbox: ==31621== 6 bytes in 2 blocks are definitely lost in loss record 27 of 10,370 ==31621== at 0x4C2154B: malloc (vg_replace_malloc.c:236) ==31621== by 0x5271A5: parsetok (parsetok.c:179) ==31621== by 0x526E8A: PyParser_ParseStringFlagsFilenameEx (parsetok.c:67) ==31621== by 0x4BC385: PyParser_ASTFromString (pythonrun.c:1898) ==31621== by 0x4BC1E1: Py_CompileStringExFlags (pythonrun.c:1842) ==31621== by 0x478AB8: builtin_compile (bltinmodule.c:626) ==31621== by 0x5759F3: PyCFunction_Call (methodobject.c:84) ==31621== by 0x48F2CF: ext_do_call (ceval.c:4292) ==31621== by 0x489992: PyEval_EvalFrameEx (ceval.c:2646) ==31621== by 0x48E67B: fast_function (ceval.c:4068) ==31621== by 0x48E3C7: call_function (ceval.c:4001) ==31621== by 0x4895E1: PyEval_EvalFrameEx (ceval.c:2605)
msg153458 - (view) Author: Meador Inge (meador.inge) * (Python committer) Date: 2012-02-16 04:18
Stefan, how did you reproduce this? I tried: 1. Uncommenting '#define Py_USING_MEMORY_DEBUGGER' in 'Objects/obmalloc.c'. 2. Configuring with './configure --without-pymalloc'. 3. Running 'valgrind --tool=memcheck --log-file=leaks.txt --leak-check=full --suppressions=Misc/valgrind-python.supp ./python -m test test_mailbox'. When performing the above I only see leaks in import: ==2683== 256 bytes in 1 blocks are definitely lost in loss record 3,234 of 4,881 ==2683== at 0x4A074CD: malloc (vg_replace_malloc.c:236) ==2683== by 0xD0753A1: PyInit_atexit (atexitmodule.c:294) ==2683== by 0x49AE0B: _PyImport_LoadDynamicModule (importdl.c:85) ==2683== by 0x498740: import_submodule (import.c:3338) ==2683== by 0x4989CA: load_next (import.c:3149) ==2683== by 0x499005: import_module_level.isra.10 (import.c:2842) ==2683== by 0x499759: PyImport_ImportModuleLevelObject (import.c:2904) ==2683== by 0x4729EA: builtin___import__ (bltinmodule.c:195) ==2683== by 0x5064E9: PyObject_Call (abstract.c:2150) ==2683== by 0x473E3E: PyEval_CallObjectWithKeywords.constprop.8 (ceval.c:3931) ==2683== by 0x477D83: PyEval_EvalFrameEx (ceval.c:2332) ==2683== by 0x4752FB: PyEval_EvalCodeEx (ceval.c:3426)
msg153509 - (view) Author: Stefan Krah (skrah) * (Python committer) Date: 2012-02-16 22:55
Yes, that's basically what I did, but using the latest revision I cannot reproduce the parsetok leak either. The atexit leak is an old friend (#11826), so I think we can close this one for now.
History
Date User Action Args
2022-04-11 14:57:22 admin set github: 57298
2012-02-16 22:55:10 skrah set status: open -> closedresolution: out of datemessages: + stage: needs patch -> resolved
2012-02-16 04🔞58 meador.inge set messages: +
2012-02-15 01:50:24 pitrou set nosy: + benjamin.peterson
2011-11-19 20:02:52 petri.lehtinen set nosy: + petri.lehtinen
2011-10-02 15:11:20 meador.inge set nosy: + meador.inge
2011-10-02 08:50:15 skrah create