Repository navigation
test_tk/test_tkk_guionly fails on OS X if run from buildbot slave daemon -- crashes Python #52962
Description
| BPO | 8716 |
|---|---|
| Nosy | @ronaldoussoren, @pitrou, @vstinner, @ned-deily, @bitdancer |
| Files |
Note: these values reflect the state of the issue at the time it was migrated and might not reflect the current state.
Show more details
GitHub fields:
assignee = 'https://github.com/ned-deily'
closed_at = <Date 2011-07-08.21:47:00.348>
created_at = <Date 2010-05-14.18:21:49.692>
labels = ['tests', 'expert-tkinter', 'type-crash']
title = 'test_tk/test_tkk_guionly fails on OS X if run from buildbot slave daemon -- crashes Python'
updated_at = <Date 2013-07-23.08:55:04.785>
user = 'https://bugs.python.org/janssen'bugs.python.org fields:
activity = <Date 2013-07-23.08:55:04.785>
actor = 'ronaldoussoren'
assignee = 'ned.deily'
closed = True
closed_date = <Date 2011-07-08.21:47:00.348>
closer = 'ned.deily'
components = ['Tests', 'Tkinter']
creation = <Date 2010-05-14.18:21:49.692>
creator = 'janssen'
dependencies = []
files = ['17359', '22527', '22529']
hgrepos = []
issue_num = 8716
keywords = ['patch']
message_count = 34.0
messages = ['105733', '105735', '105740', '105852', '105853', '105854', '105855', '105876', '114910', '114919', '119317', '119319', '138514', '139518', '139527', '139531', '139532', '139533', '139534', '139535', '139536', '139540', '139543', '139737', '139738', '139739', '139843', '139849', '139905', '139906', '139915', '139916', '140041', '193590']
nosy_count = 8.0
nosy_names = ['ronaldoussoren', 'janssen', 'pitrou', 'vstinner', 'gpolo', 'ned.deily', 'r.david.murray', 'python-dev']
pr_nums = []
priority = 'normal'
resolution = 'fixed'
stage = 'resolved'
status = 'closed'
superseder = None
type = 'crash'
url = 'https://bugs.python.org/issue8716'
versions = ['Python 3.1', 'Python 2.7', 'Python 3.2']
Activity
janssen commentedon May 14, 2010
test_tk fails on OS X if test is run from a daemon process without the privilege to access the window server, say a buildbot slave without anyone logged in to the console. The Tk support needs to check whether it has access rights to the window server before trying to access it.
Workaround is to log buildbot into the console of the OS X machine (which usually but not always works), or to run tests manually.
janssen commentedon May 14, 2010
[More info from Ronald Oussoren]
This is a bug in Tk:
This is running /usr/bin/python in a session as a user that doesn't have access to the GUI. The text above says that there is an uncaught ObjC exception, caused by the lack of a connection to the window server. Tk should have converted that to its own style of errors but didn't.
janssen commentedon May 14, 2010
It's fairly easy to create a restricted process tree for testing. ssh into a Mac which has no one logged into the console, from another machine, and use that connection to launch an xterm or Xemacs window to the other machine. Then log out of the ssh session. The session running in the xterm will now have no access privileges to the window server, and can be used for testing.
ronaldoussoren commentedon May 16, 2010
I've filed an issue for this in the Tcl/Tk tracker: <https://sourceforge.net/tracker/?func=detail&aid=3002320&group_id=10894&atid=110894\>
(Assuming that this is the canonical tracker for the Tcl/Tk project, it was the first hit in google for 'tk bug tracker').
ronaldoussoren commentedon May 16, 2010
BTW. Another way of testing, assuming you have two accounts: use 'su - otheraccount' to get a shell session as another user then try to start tk using:
This will currently crash the interpreter due to an uncaught Objective-C exception (as seen in msg105735)
ronaldoussoren commentedon May 16, 2010
The attached patch is a first start at working around the crash. With this patch I can use Tk without a crash:
This isn't ideal though, especially because the patch requires that you build using an SDK or explicitly specify a deployment target (MACOSX_DEPLOYMENT_TARGET=10.5) during build.
Another reason to dislike this: the errors are swallowed instead of propagated to Python code.
I haven't checked yet if this patch allows you to run the tests without crashing.
ronaldoussoren commentedon May 16, 2010
Something I forgot to mention: the patch introduces "_tkinter.m" to enable compiling the _tkinter extension as Objective-C code. The compiler also supports passing "-x objective-c" to compile _tkinter.c in Objective-C mode, but this flag must be specified early on the GCC command-line and I haven't been able to trick distutils in passing the flags at the right place yet.
Just adding ['-x', 'objective-c'] to the extra_compile_args argument to Extension does not work: that appends the flags to the compiler command-line while the -x flag only works when it is before the name of the source file(s).
ronaldoussoren commentedon May 16, 2010
Tk has a different tracker than tcl itself, the upstream issue is now <https://sourceforge.net/tracker/?func=detail&aid=3002484&group_id=12997&atid=112997\>
bitdancer commentedon Aug 25, 2010
I just ran into this while trying to run the test suite with -uall while sshed into an OSX machine and running a non-framework build. This makes it kind of hard to run the full test suite.
Is there some way to detect that we don't have access to the window server and skip the test? It's going to fail anyway, so even once the crash bug is fixed skipping the test when we don't have access to the window server is the right thing to do.
ronaldoussoren commentedon Aug 25, 2010
In python 2.x 'MacOS.WMAvailable()' returns True if the windowserver is available.
The whole MacOS extension is gone in 3.x, although it should be easy enough to reimplement WMAvailable() using ctypes.
bitdancer commentedon Oct 21, 2010
Only OSX 10.4.0 I can run test_tk:
rdmurray@buddy:~/python/py3k>./python.exe -m test.regrtest -uall test_tk
[1/1] test_tk
Thu Oct 21 12:41:16 buddy.home.bitdance.com python.exe[93560] <Error>: kCGErrorFailure: Set a breakpoint @ CGErrorBreakpoint() to catch errors as they are logged.
_RegisterApplication(), FAILED TO establish the default connection to the WindowServer, _CGSDefaultConnection() is NULL.
1 test OK.
But test_ttk_guionly crashes with the abort trace after printing the above. I presume this means test_ttk_guionly was factored out at some point after this issue was raised, but it is interesting that test_tk produces the warning about the window connection but only _guionly crashes.
[-]test_tk fails on OS X if run from buildbot slave daemon -- crashes Python[/-][+]test_tk/test_tkk_guionly fails on OS X if run from buildbot slave daemon -- crashes Python[/+]11 remaining items
ned-deily commentedon Jul 1, 2011
Hold off on the buildbot changes for the moment. I have an idea for a possible workaround/solution.
python-dev commentedon Jul 4, 2011
New changeset ea02eca122b5 by Ned Deily in branch '2.7':
Issue bpo-8716: Avoid crashes caused by Aqua Tk on OSX when attempting to run
http://hg.python.org/cpython/rev/ea02eca122b5
New changeset 279488f5a171 by Ned Deily in branch '3.2':
Issue bpo-8716: Avoid crashes caused by Aqua Tk on OSX when attempting to run
http://hg.python.org/cpython/rev/279488f5a171
New changeset 5b5a33196916 by Ned Deily in branch 'default':
Issue bpo-8716: Avoid crashes caused by Aqua Tk on OSX when attempting to run
http://hg.python.org/cpython/rev/5b5a33196916
ned-deily commentedon Jul 4, 2011
Let's try this: when running under OS X, the tk and ttk test runners now perform their initial Tk-available sanity check in a subprocess rather than in the main interpreter process. If the subprocess fails, the tests are skipped. There are some differences in behavior across the various OS X releases - 10.4 crashes in more cases than 10.5 and 10.6 - but this should cover them all. I'll leave this open for a while. Please log any buildbot regressions here.
python-dev commentedon Jul 4, 2011
New changeset 06cb0d602468 by Ned Deily in branch '2.7':
Issue bpo-8716: Fix errors in the non-OS X path of the 27 backport.
http://hg.python.org/cpython/rev/06cb0d602468
vstinner commentedon Jul 5, 2011
Build #200 (revision 6abbc5f68e20eb01094dbbcf486c2ba0e1e4fa77) of "AMD64 Snow Leopard 2 2.7" crashed:
test_ttk_guionly
make: *** [buildbottest] Segmentation fault
http://www.python.org/dev/buildbot/all/builders/AMD64%20Snow%20Leopard%202%202.7/builds/200/
runtktests.check_tk_availability() creates a Tkinter.Button() in a subprocess. It should maybe try to create a ttk.Button() for test_ttk_guionly instead of Tkinter.Button().
ronaldoussoren commentedon Jul 5, 2011
python2.7 has MacOS.WMAvailable(). When that function returns False the Tkinter tests should be disabled.
The function is not available in Python 3, but is easy enough to implement using ctypes.
ned-deily commentedon Jul 5, 2011
That's puzzling. That particular segfault failure is on test_ttk_guionly but test_tk apparently passed earlier in the run and it seems that this buildbot is being run with a window manager connection available (the changes that I added did not raise an exception and the DISPLAY env variable is set). Further, it's an intermittent segfault. At the moment, for this buildbot (http://www.python.org/dev/buildbot/all/buildslaves/parc-snowleopard-1), in recent builds only 2.7 builds 202 and 200 have the segfault; 2.7 builds 203 and 201 do not nor do any of the recent 3.2 or 3.x builds. So, while the fixes I checked in do appear to prevent segfaults in the "headless" operation case (I was able to reproduce and test this on my systems), these two buildbot segfaults appear to have a different root cause. I am going to temporarily add Ronald's suggested test for 2.7 in hopes of confirming that the window manager connection is indeed not the issue on the buildbot. I would also be interested in confirmation that what is checked in now prevents the segfaults when running the tests under a headless ssh.
With regard to "untktests.check_tk_availability() creates a Tkinter.Button() in a subprocess. It should maybe try to create a ttk.Button() for test_ttk_guionly instead of Tkinter.Button()": ttk is not necessarily available in older versions of Tk. The tests are structured to test for Tk availability first and then separately for ttk availability.
python-dev commentedon Jul 5, 2011
New changeset 18ce15f841cf by Ned Deily in branch '2.7':
Issue bpo-8716: Add temporary code for 2.7 to help diagnose buildbot failure.
http://hg.python.org/cpython/rev/18ce15f841cf
python-dev commentedon Jul 6, 2011
New changeset b5accd8adc3e by Ned Deily in branch '2.7':
Issue bpo-8716: Back out temporary changeset 18ce15f841cf
http://hg.python.org/cpython/rev/b5accd8adc3e
New changeset b5ac5e25d506 by Ned Deily in branch '2.7':
Issue bpo-8716: Instead of relying on Aqua Tk exceptions to detect lack of
http://hg.python.org/cpython/rev/b5ac5e25d506
New changeset b58b0c5c7e96 by Ned Deily in branch '3.2':
Issue bpo-8716: Instead of relying on Aqua Tk exceptions to detect lack of
http://hg.python.org/cpython/rev/b58b0c5c7e96
New changeset 2f7e353f9e83 by Ned Deily in branch 'default':
Issue bpo-8716: Instead of relying on Aqua Tk exceptions to detect lack of
http://hg.python.org/cpython/rev/2f7e353f9e83
ned-deily commentedon Jul 6, 2011
Despite evidence to the contrary, the temporary MacOS.WMAvailable code showed that there was *not* a window manager connection. I'm still not sure what the difference in environments is (perhaps it is just due to a different version of Tcl/Tk on the buildbot) nor why the buildbot only fails intermittently. In any case, I've taken Ronald's suggestion and replaced the Tk-in-a-subprocess sanity check with a ctypes version of what MacOS.WMAvailable did. Let's see what how well that works.
ned-deily commentedon Jul 8, 2011
I haven't seen any failures yet so let's close it.
ronaldoussoren commentedon Jul 23, 2013
I just noticed that the Tk tests still get skipped on my machine, and rediscovered this issue. The reason that MacOS.WMAvailable() returns False on the buildbot is because it runs "./python.exe", which is not part of an application bundle and therefore has no GUI access.
To easily reproduce with a framework install:
Note that MacOS.WMAvailable() returns True when you run
the python/pythonw when you are logged in to the machine
Now copy /Library/Framework/Python.frameworks/Versions/Current/Resources/Python.app/Contents/MacOS/Python to "python.exe"
Run "./python.exe" and note that MacOS.WMAvailable() now returns
False (and that sys.prefix still refers to the framework)