New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Consolidate gui available checks in test.support #62804
Comments
Current situation: test.support.requires starts with On windows, _is_gui_available() uses ctypes to determine that there really is a graphics screen. On other systems, it just returns True, even when it should return False. The _is_gui_available check is repeated with each requires('gui') call even though all after the first would be redundant if False were somehow recorded. I think it should be. test/test_ttkguionly first tries to import _tkinter, as does test_idle, which initializes tcl/tk. It then calls tkinter.test.support.check_tk_availability. That either does a 'darwin'-ctypes check similar to the one for Windows in _is_gui_available (again to avoid a crash), or it tries to create a tk widget and looks for a TclError. Given that tcl has already been initialized successfully, the widget creation check is a gui-available check for non-Darwin systems. A global in tkinter.test.support records the result of the check so it is only run once. If 'gui' is in use_resources, test_idle just does the widget check for *nix gui availability. It records a negative result by removing 'gui' from use_resources. The tkinter system does not work for Idle because Idle tests use unittest test discovery instead of tkinter's custom test discovery. Given that, splitting test_idle into test_idle_text and test_idle_gui seems to not be possible. Anyway, if test_idle were to be split, categories like '_windows', '_dialogs', and '_extensions' would be much more sensible and useful. ----------------
----- |
I think it is fine to backport this, since it only affects tests, and allows the backported idle tests to be consistent. For 3/4, I agree that requires should skip always if the GUI infrastructure is not available. The "don't skip if main" logic is appropriate only for deciding whether or not to run the tests when the test suite is invoked directly (as opposed to through regrtest), not for deciding whether or not to run them when the actual resource is being checked. |
Here's a patch for 3.4, and some sample verbose output[1] from the AMD64 Win7 buildbot (which runs buildbot as a service, and thus has no gui available). |
If there are no objections forthcoming, I'll try to get this applied to 3.4/3.5 later this week, then look into backporting to 2.7. |
New changeset 5f75eadecff1 by Zachary Ware in branch '2.7': New changeset eb361f69ddd1 by Zachary Ware in branch '3.4': New changeset 82caec3865e3 by Zachary Ware in branch 'default': |
Thank you Zach. |
New changeset 7ecb6e4b1077 by Ned Deily in branch '3.4': New changeset 7f6d9990a9b1 by Ned Deily in branch 'default': |
For some reason, the newly-added Tk instantiation check causes the OS X Cocoa Tk to segfault when tests are run under regrtest -jn option, which causes each test to be run under a separate subprocess called from a separate thread. Somewhat surprisingly, the segfault doesn't seem to happen under the same conditions with 2.7, only with 3.4 and default, so there is something more at play here. But with the imminent tagging of 3.4.1rc1, I think it is better to disable the check for 3.4 (and default) on OS X pending further investigation. The check is redundant: if Tk doesn't work for some reason, the individual test should fail anyway, just a bit later. |
Thanks Ned. Unfortunately, I don't have a Mac to test on, so I can't help much with figuring out what's going on. |
New changeset fef11a65a5e5 by Ned Deily in branch '2.7': |
Earlier I noted: "Somewhat surprisingly, the segfault doesn't seem to happen under the same conditions with 2.7". I'm not sure now how I came to that conclusion then but it is incorrect: the segfault definitely also occurs under the same conditions with 2.7, at least when using the current ActiveTcl 8.5.15. It did not seem to fail with the Apple system Tk 8.5.9, a more plausible result than not failing at all with 2.7. Next step: test with various Cocoa Tk versions. |
The previous segfaults on OS X have been isolated to a problem in Cocoa Tk and an issue has been opened about it on the Tk issue tracker. See bpo-22770 for details. Changesets applied to _is_gui_available() in that issue should prevent the segfaults by ensuring that Tk completes necessary initialization before the Tcl interpreter instance is destroyed and a new one created. So _is_gui_available() is now enabled on OS X and we can close this issue. |
Thanks for tracking it down, Ned! |
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:
bugs.python.org fields:
The text was updated successfully, but these errors were encountered: