[issue1731706] tkinter memory leak problem

Guilherme Polo 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 ___

[issue1731706] tkinter memory leak problem

Martin v. Löwis 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 - go ahead! _

[issue1731706] tkinter memory leak problem

Guilherme Polo 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 problems), but this API

[issue1731706] tkinter memory leak problem

Robert Hancock 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 ___ Python tracker <

[issue1731706] tkinter memory leak problem

Guilherme Polo 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 (IIUC). Lik

[issue1731706] tkinter memory leak problem

Martin v. Löwis 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 (IIUC). Likewise for

[issue1731706] tkinter memory leak problem

Guilherme Polo 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 introduce memory lea

[issue1731706] tkinter memory leak problem

Martin v. Löwis 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 to fix this in 2

[issue1731706] tkinter memory leak problem

Guilherme Polo 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 fine to me too (

[issue1731706] tkinter memory leak problem

Martin v. Löwis added the comment: I think the patch is correct. gpolo, what's your opinion? ___ Python tracker ___ ___ Python-bugs-list mai

[issue1731706] tkinter memory leak problem

Guilherme Polo 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

[issue1731706] tkinter memory leak problem

Changes by Christian Heimes: -- versions: +Python 2.6 _ Tracker <[EMAIL PROTECTED]> _ ___ Python-bugs-list mailing list Unsubscribe: