➜
This issue tracker has been migrated to GitHub,
and is currently read-only.
For more information,
see the GitHub FAQs in the Python's Developer Guide.
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) *  |
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) * |
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) * |
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 -> closed resolution: out of date messages: + msg153509 stage: needs patch -> resolved |
| 2012-02-16 04:18:58 | meador.inge | set | messages: + msg153458 |
| 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 | |