| msg80901 - (view) |
Author: Guilherme Polo (gpolo) *  |
Date: 2009-02-01 04:45 |
| Recently I've added this test named test_ttk_guionly, and I noticed some buildslaves went red, like amd64 gentoo trunk and x86 FreeBSD trunk (I though there were others for the reason I'm going to say next, but didn't found on a quick look). amd 64 gentoo trunk is failing with: . . test_ttk_guionly test_ttk_guionly skipped -- ttk not available: no display name and no $DISPLAY environment variable . . test_tcl remoteFailed: [Failure instance: Traceback (failure with no frames): twisted.internet.error.ConnectionLost: Connection to the other side was lost in a non-clean fashion. ] When it is not test_tcl, it is test_ttk_guionly. I tried duplicating the issue here by creating a buildmaster and a buildslave, used same options to build and to run tests, also tried enabling and disabling pty (I've found some old emails about problems involving pty), but couldn't duplicate it. So I followed a build on this buildslave "amd 64 gentoo trunk" and noticed it took a long time from the time it started running test_tcl till when the error appeared, which makes me imagine there is some problem regarding X server authorization. Now this is when I started checking how many other slaves were failing with the same error, and then I found this "x86 FreeBSD trunk" which failed with the following message: . . test_ttk_guionly test_ttk_guionly skipped -- ttk not available: can't find package tile . . test_tcl XIO: fatal IO error 9 (Bad file descriptor) on X server ":0.0" after 25 requests (23 known processed) with 1 events remaining. *** Error code 1 This second bot had DISPLAY set, while the first didn't (although its TERM is set to xterm). I wonder if the first error ends up being the same as this second one. I'm asking myself if test_ttk_guionly is so wrong that it should be disabled everywhere, and even if it gets disabled, what if in the future another test comes in and "conflicts" with test_tcl ? |
|
|
| msg81272 - (view) |
Author: Guilherme Polo (gpolo) * |
Date: 2009-02-06 16:01 |
| Eric, I noticed you said Fedora 6, so I checked which tcl/tk it includes and apparently it is 8.4.13, is that correct ? I tried using tcl/tk 8.4.13 and I managed to hang it too :) Try running test_tcl followed by test_ttk_guionly with regrtest. |
|
|
| msg81273 - (view) |
Author: Eric V. Smith (eric.smith) * |
Date: 2009-02-06 16:07 |
| Yes, I have these installed: tcl-8.4.13-3.fc6 tcl-devel-8.4.13-3.fc6 tk-8.4.13-3.fc6 tk-devel-8.4.13-3.fc6 When I run "./python Lib/test/regrtest.py test_tcl test_ttk_guionly", it hangs. |
|
|
| msg81276 - (view) |
Author: Guilherme Polo (gpolo) * |
Date: 2009-02-06 16:18 |
| > When I run "./python Lib/test/regrtest.py test_tcl test_ttk_guionly", it > hangs. I have isolated it now: Traceback (most recent call last): File "", line 1, in File "/home/gpolo/python-dev/python-trunk/Lib/lib-tk/Tkinter.py", line 1649, in loadtk self.tk.loadtk() _tkinter.TclError: no display name and no $DISPLAY environment variable >>> Tkinter.Tk() hang! Very nice, much more "solvable" now after getting to know the tcl/tk version. |
|
|
| msg81279 - (view) |
Author: Guilherme Polo (gpolo) * |
Date: 2009-02-06 16:32 |
| After "I have isolated it now:", there should be this interactive session (but gmail ate it apparently): >>> import os >>> del os.environ['DISPLAY'] >>> import Tkinter >>> t = Tkinter.Tcl() >>> t.loadtk() Traceback (most recent call last): File "", line 1, in File "/home/gpolo/python-dev/python-trunk/Lib/lib-tk/Tkinter.py", line 1649, in loadtk self.tk.loadtk() _tkinter.TclError: no display name and no $DISPLAY environment variable >>> Tkinter.Tk() hang! |
|
|
| msg81280 - (view) |
Author: Guilherme Polo (gpolo) * |
Date: 2009-02-06 16:45 |
| Ok, I've found the cause of the problem and the patch attached should solve it but shouldn't be applied! This was just a quick fix I did to confirm what I expected, I will add something more correct later. _tkinter is aware of this deadlock that we are getting (see Tkapp_TkInit), but it is not collaborating to solve it. The problem is avoided if we always use "loadtk" in Tkinter.py instead of using "create" to load tk. |
|
|
| msg81290 - (view) |
Author: Eric V. Smith (eric.smith) * |
Date: 2009-02-06 18:21 |
| The patch does solve the problem for me. It no longer hangs when running either: ./python Lib/test/regrtest.py test_tcl test_ttk_guionly or: ./python Lib/test/regrtest.py ------------- ... test_traceback test_transformer test_ttk_guionly test_ttk_guionly skipped -- ttk not available: Calling Tk_Init again after a previous call failed might deadlock test_ttk_textonly test_tuple ... ------------- Thanks for tracking this down. |
|
|
| msg81293 - (view) |
Author: Guilherme Polo (gpolo) * |
Date: 2009-02-06 19:34 |
| Here is a better patch, for some definition of better. It syncs the failed attempt to load tk that may occur in _tkinter.Tkapp_TkInit, _tkinter.Tcl_AppInit and tkappinit.Tcl_AppInit. And that is done only for tk < 8.4.14 now. Said that, I'm a bit worried about the (new macro) TK_VERSION_HEX in _tkinter and tkappinit, maybe it is time to add a _tkinter.h ? |
|
|
| msg81295 - (view) |
Author: Guilherme Polo (gpolo) * |
Date: 2009-02-06 19:42 |
| Any chance you can look at the proposed patch, Martin ? I found out that it was you who reported this deadlock back then, so you might want to review the patch. |
|
|
| msg81298 - (view) |
Author: Eric V. Smith (eric.smith) * |
Date: 2009-02-06 20:11 |
| The second patch (checking_for_failed_tk_load.diff) also works for me. |
|
|
| msg81299 - (view) |
Author: Guilherme Polo (gpolo) * |
Date: 2009-02-06 20:57 |
| Found a place still out of sync, it is fixed on this new patch. To reproduce the problem with the previous patch try this: import os del os.environ['DISPLAY'] import Tkinter Tkinter.Tk() Tkinter.Tcl().loadtk() # should hang now (with a proper tk version) |
|
|
| msg81304 - (view) |
Author: Eric V. Smith (eric.smith) * |
Date: 2009-02-06 22:02 |
| With the second patch installed, your code snippet does indeed hang for me. With the third patch installed, I get: [trunk]$ ./python Python 2.7a0 (trunk:69369M, Feb 6 2009, 14:59:32) [GCC 4.1.2 20070626 (Red Hat 4.1.2-13)] on linux2 Type "help", "copyright", "credits" or "license" for more information. >>> import os >>> del os.environ['DISPLAY'] >>> import Tkinter Tkinter.Tk() >>> Tkinter.Tk() Traceback (most recent call last): File "", line 1, in File "/root/python/trunk/Lib/lib-tk/Tkinter.py", line 1643, in __init__ self.tk = _tkinter.create(screenName, baseName, className, interactive, wantobjects, useTk, sync, use) _tkinter.TclError: no display name and no $DISPLAY environment variable >>> Tkinter.Tcl().loadtk() # should hang now (with a proper tk version) Traceback (most recent call last): File "", line 1, in File "/root/python/trunk/Lib/lib-tk/Tkinter.py", line 1649, in loadtk self.tk.loadtk() _tkinter.TclError: Calling Tk_Init again after a previous call failed might deadlock Which I assume is the expected behavior. Also with the third patch installed, the regrtest's all pass. |
|
|
| msg81308 - (view) |
Author: Guilherme Polo (gpolo) * |
Date: 2009-02-06 22:16 |
| > Eric Smith added the comment: > . > . > Which I assume is the expected behavior. Yes it is expected. > > Also with the third patch installed, the regrtest's all pass. > Very nice. And Eric, thanks for the patience and for testing them all. |
|
|
| msg81346 - (view) |
Author: Guilherme Polo (gpolo) * |
Date: 2009-02-07 19:27 |
| A bit cleaner patch. |
|
|
| msg81350 - (view) |
Author: Eric V. Smith (eric.smith) * |
Date: 2009-02-07 21:47 |
| protect_tk_loading.diff works for me. |
|
|
| msg81486 - (view) |
Author: Eric V. Smith (eric.smith) * |
Date: 2009-02-09 20:38 |
| The current patch (protect_tk_loading.diff) looks reasonable to me, and it solves my problem with the tests hanging. So I'd suggest you commit the patch, insofar it improves on the current situation. I'm not an expert in tk, however. So if you're looking for advice from someone knowledgeable on tk's inner workings, you'll need to get someone else involved. |
|
|
| msg81488 - (view) |
Author: Guilherme Polo (gpolo) * |
Date: 2009-02-09 20:55 |
| Thanks Eric, committed in r69473. |
|
|