Stefan Krah added the comment:
One example of a leaked object is hexversion, from sysmodule.c:1615.
I tried adding it to sys_deletes[] in import.c, but it did not help.
See valgrind.out for other leaks.
--
___
Python tracker rep...@bugs.python.org
Stefan Krah added the comment:
IMO we have two references to many newly created values in _PySys_Init():
SET_SYS_FROM_STRING(hexversion,
PyLong_FromLong(PY_VERSION_HEX));
One from PyLong_FromLong() and the other from PyDict_SetItemString() in the
macro. So
Stefan Krah added the comment:
See also 31796b188bec.
--
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue10241
___
___
Python-bugs-list mailing list
Antoine Pitrou added the comment:
Does pulling the Py_DECREF before the if fix the leaks?
--
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue10241
___
Stefan Krah added the comment:
Antoine Pitrou rep...@bugs.python.org wrote:
Does pulling the Py_DECREF before the if fix the leaks?
Yes, but I get an additional failure in test_capi. Apparently not all values
require the DECREF. Got to look on a case by case basis.
--
Stefan Krah added the comment:
Valgrind is happy after the recent 5eb00460e6e8.
--
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue10241
___
___
Stefan Krah added the comment:
I'm getting a couple of Valgrind leaks, starting with 1edff836c954:
valgrind --suppressions=Misc/valgrind-python.supp --leak-check=full ./python -c
pass
All of them seem to be in _PySys_Init().
--
nosy: +skrah
Added file:
Antoine Pitrou added the comment:
Can you identify which objects those leaks point to?
The sys module is cleared at shutdown.
--
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue10241
___
Antoine Pitrou added the comment:
I'm closing this issue as fixed though I'm not entirely sure the fix is right.
The alpha cycle will allow us to get feedback on potential incompatibilities
with third-party software.
--
resolution: - fixed
stage: - committed/rejected
status: open -
Roundup Robot added the comment:
New changeset 1edff836c954 by Antoine Pitrou in branch 'default':
Issue #10241: Clear extension module dict copies at interpreter shutdown.
http://hg.python.org/cpython/rev/1edff836c954
--
___
Python tracker
Antoine Pitrou added the comment:
Re-applied patch after having fixed the tkinter issue.
--
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue10241
___
Roundup Robot added the comment:
New changeset 314a872f54e1 by Antoine Pitrou in branch 'default':
Backout 62658d9d8926 (issue #10241): it causes a crash at shutdown when
deallocating a Tkapp object.
http://hg.python.org/cpython/rev/314a872f54e1
--
Antoine Pitrou added the comment:
I backed out the changeset in time for the Alpha 1 release.
Further investigation should perhaps be made on the tkinter issue, but it's a
bit cumbersome: you need a full test run in non-parallel mode to exhibit the
segfault.
--
stage:
Antoine Pitrou added the comment:
Ok, the patch doesn't apply cleanly but looks good regardless.
(although I wonder whether you really reclaim significant stuff here: most C
extension dicts should be mostly references to C methods and types)
--
assignee: loewis -
nosy: +pitrou
type:
Antoine Pitrou added the comment:
I will still empty modules_by_index rather than Py_CLEAR it, though.
--
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue10241
___
Changes by Antoine Pitrou pit...@free.fr:
--
resolution: - fixed
stage: - committed/rejected
status: open - closed
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue10241
___
Roundup Robot added the comment:
New changeset 62658d9d8926 by Antoine Pitrou in branch 'default':
Issue #10241: Clear extension module dict copies at interpreter shutdown.
http://hg.python.org/cpython/rev/62658d9d8926
--
nosy: +python-dev
___
Python
Antoine Pitrou added the comment:
Reopening. This seems to produce segfaults on several of the buildbots, e.g.:
http://buildbot.python.org/all/builders/x86%20XP-4%203.x/builds/8947
http://buildbot.python.org/all/builders/x86%20Windows%20Server%202003%20%5BSB%5D%203.x/builds/1257
Changes by Arfrever Frehtes Taifersar Arahesis arfrever@gmail.com:
--
nosy: +Arfrever
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue10241
___
Antoine Pitrou added the comment:
I managed to get a core dump locally. Interestingly, it may be that the _tk
module is the culprit. The backtrace is the following:
#0 0x7ff6c5e14aab in raise () from /lib/x86_64-linux-gnu/libpthread.so.0
#1 0x0044e57e in faulthandler_fatal_error
Antoine Pitrou added the comment:
_tkinter uses PyType_FromSpec() to create its types and then adds them to the
module dict without increfing them, so there may be a refcount issue explaining
that those types get garbage collected before all their instances die.
--
Neil Schemenauer nas-pyt...@arctrix.com added the comment:
The attached patch seems better. The copies of module dicts stored in the
interpreter state are dereferenced when the interpreter shuts down.
--
Added file: http://bugs.python.org/file19509/module_m_copy2.txt
Neil Schemenauer nas-pyt...@arctrix.com added the comment:
Oops, my patch doesn't work since m_base can be shared by more than one module
instance. I guess a different solution would be to cleanup the m_copy
references on interpreter shutdown. Somehow they would have to be found though.
New submission from Neil Schemenauer nas-pyt...@arctrix.com:
I'm trying implement some saner module shutdown procedure (similar to issue
812369). One of the many problems I've run into is that the GC doesn't know
about the m_copy attribute of modules.
I think the attached patch is correct.
24 matches
Mail list logo
