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.

classification
Title: test_tcl and test_ttk_guionly don't like each other
Type: Stage:
Components: Tkinter Versions: Python 3.1, Python 2.7
process
Status: closed Resolution: fixed
Dependencies: Superseder:
Assigned To: Nosy List: eric.smith, gpolo, loewis
Priority: normal Keywords: patch

Created on 2009-02-01 04:45 by gpolo, last changed 2022-04-11 14:56 by admin. This issue is now closed.

Files
File name Uploaded Description Edit
dont_load_tk_in_tkintercreate.diff gpolo, 2009-02-06 16:45
protect_tk_loading.diff gpolo, 2009-02-07 19:27
Messages (17)
msg80901 - (view) Author: Guilherme Polo (gpolo) * (Python committer) 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) * (Python committer) 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) * (Python committer) 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) * (Python committer) 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 "<stdin>", line 1, in <module>
  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) * (Python committer) 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 "<stdin>", line 1, in <module>
 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) * (Python committer) 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) * (Python committer) 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) * (Python committer) 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) * (Python committer) 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) * (Python committer) 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) * (Python committer) 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) * (Python committer) 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 "<stdin>", line 1, in <module>
  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 "<stdin>", line 1, in <module>
  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) * (Python committer) 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) * (Python committer) Date: 2009-02-07 19:27
A bit cleaner patch.
msg81350 - (view) Author: Eric V. Smith (eric.smith) * (Python committer) Date: 2009-02-07 21:47
protect_tk_loading.diff works for me.
msg81486 - (view) Author: Eric V. Smith (eric.smith) * (Python committer) 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) * (Python committer) Date: 2009-02-09 20:55
Thanks Eric, committed in r69473.
History
Date User Action Args
2022-04-11 14:56:45adminsetgithub: 49372
2009-02-09 20:55:15gpolosetstatus: open -> closed
resolution: fixed
messages: + msg81488
2009-02-09 20:38:46eric.smithsetmessages: + msg81486
2009-02-07 21:47:48eric.smithsetmessages: + msg81350
2009-02-07 19:28:06gpolosetfiles: - checking_for_failed_tk_load.diff
2009-02-07 19:28:01gpolosetfiles: - checking_for_failed_tk_load-2.diff
2009-02-07 19:27:54gpolosetfiles: + protect_tk_loading.diff
messages: + msg81346
2009-02-06 22:16:17gpolosetmessages: + msg81308
2009-02-06 22:02:29eric.smithsetmessages: + msg81304
2009-02-06 20:57:42gpolosetfiles: + checking_for_failed_tk_load-2.diff
messages: + msg81299
2009-02-06 20:11:13eric.smithsetmessages: + msg81298
2009-02-06 19:42:16gpolosetnosy: + loewis
messages: + msg81295
2009-02-06 19:34:48gpolosetfiles: + checking_for_failed_tk_load.diff
messages: + msg81293
2009-02-06 18:21:29eric.smithsetmessages: + msg81290
2009-02-06 16:45:56gpolosetfiles: + dont_load_tk_in_tkintercreate.diff
keywords: + patch
messages: + msg81280
2009-02-06 16:32:13gpolosetmessages: + msg81279
2009-02-06 16:18:01gpolosetmessages: + msg81276
2009-02-06 16:07:10eric.smithsetmessages: + msg81273
2009-02-06 16:01:22gpolosetmessages: + msg81272
2009-02-06 15:46:53eric.smithsetnosy: + eric.smith
2009-02-01 04:45:08gpolocreate