Guilherme Polo ggp...@gmail.com added the comment:
Committed now.
trunk: r69376, r69377
release26-maint: r69378
py3k: r69380
release30-maint: r69381 (hand-merged, as you may notice I forgot to
split the patch in two again in py3k)
--
resolution: - fixed
status: open - closed
Robert Hancock hanc...@sedsystems.ca added the comment:
That's not really a meaningful difference, though.. if the application
uses this code continuously then the conditions will pile up in memory
until it fills up.
--
nosy: +robhancock1 -robhancock
Guilherme Polo ggp...@gmail.com added the comment:
That's not really a meaningful difference, though.. if the application
uses this code continuously then the conditions will pile up in memory
until it fills up.
I'm not trying to discourage you to do the complete fix (for these two
Martin v. Löwis mar...@v.loewis.de added the comment:
Still, the call fix should be backported to python 2.6 as it doesn't
depend on changing supported tcl versions and is also more severe.
That sounds like a good approach. If you can split the patch into two,
backporting only one of them -
Martin v. Löwis mar...@v.loewis.de added the comment:
I think the patch is correct. gpolo, what's your opinion?
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue1731706
___
Guilherme Polo ggp...@gmail.com added the comment:
Do we still want to say _tkinter.c supports tcl/tk from version 8.2 and
newer ? If yes, then we should add a no-op Tcl_ConditionFinalize when
using tcl older than 8.3, because that was when this function got added.
Besides that, the patch looks
Martin v. Löwis mar...@v.loewis.de added the comment:
Do we still want to say _tkinter.c supports tcl/tk from version 8.2 and
newer ? If yes, then we should add a no-op Tcl_ConditionFinalize when
using tcl older than 8.3, because that was when this function got added.
Good point. If we want
Guilherme Polo ggp...@gmail.com added the comment:
It is much more important to fix the memory leak anyway, it is possible
to notice real problems using test_tkleak1.py and watching the process
with ps or something else provided by the platform. Besides, not calling
ConditionFinalize doesn't
Martin v. Löwis mar...@v.loewis.de added the comment:
Besides, not calling ConditionFinalize doesn't introduce memory leaks
Are you sure about this? On Unix, TclpFinalizeCondition does
pthread_cond_destroy(pcondPtr);
ckfree((char *) pcondPtr);
both of which release memory
Guilherme Polo ggp...@gmail.com added the comment:
Besides, not calling ConditionFinalize doesn't introduce memory leaks
Are you sure about this? On Unix, TclpFinalizeCondition does
pthread_cond_destroy(pcondPtr);
ckfree((char *) pcondPtr);
both of which release memory
Guilherme Polo ggp...@gmail.com added the comment:
Sample attached for demonstrating the leak by missing a call to
Tkapp_CallDeallocArgs.
--
nosy: +gpolo
Added file: http://bugs.python.org/file12373/test_tkleak1.py
___
Python tracker
Changes by Christian Heimes:
--
versions: +Python 2.6
_
Tracker [EMAIL PROTECTED]
http://bugs.python.org/issue1731706
_
___
Python-bugs-list mailing list
Unsubscribe:
12 matches
Mail list logo