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
test_curses skipped on buildbots #56878
Comments
When running regrtest with the -j and/or -w options, test_curses gets skipped, For the -w case (which applies to the buildbots), this is caused by sys.stdout For the -j case things aren't quite so straightforward - each test is run in a TLDR:
|
Correction: the offending options are -j and *-W* (display test output on |
I changed regrtest -W recently to only run the tests once using StringIO as stdout. So it's a regression in Python 3.3. Can't we create a dummy/temporary TTY for the curses tests using pty.openpty()? |
I would have thought so, but it seems that savetty() and endwin() both fail when test test_curses crashed -- Traceback (most recent call last):
File "/home/nadeem/code/cpython/python/Lib/test/test_curses.py", line 289, in test_main
main(stdscr)
File "/home/nadeem/code/cpython/python/Lib/test/test_curses.py", line 269, in main
curses.savetty()
_curses.error: savetty() returned ERR
During handling of the above exception, another exception occurred:
Traceback (most recent call last):
File "/home/nadeem/code/cpython/python/Lib/test/regrtest.py", line 1139, in runtest_inner
indirect_test()
File "/home/nadeem/code/cpython/python/Lib/test/test_curses.py", line 291, in test_main
curses.endwin()
_curses.error: endwin() returned ERR It might be that you need to close stdout and stderr so that there's only one |
New changeset 4358909ee221 by Nadeem Vawda in branch 'default': |
As noted in bpo-15664 this issue also affects "make test". |
Nadeem: is the failure you show in msg141798 with a version of test_curses that uses pty.openpty? If it isn't: I'd expect more test failures on buildbot machines where the buildbot agent is started as a system daemon, in which case the process doesn't have a tty at all. Using pty.openpty it would be possible to ensure that there is a pty that can be used for the test. I'll work on a patch. |
BTW. the documentation for curses.setupterm says: curses.setupterm([termstr, fd]) The first argument is actually named "term" in the C code. |
Yes, I tried the following change:
def test_main():
- if not sys.__stdout__.isatty():
- raise unittest.SkipTest("sys.__stdout__ is not a tty")
# testing setupterm() inside initscr/endwin
# causes terminal breakage
- curses.setupterm(fd=sys.__stdout__.fileno())
+ #curses.setupterm(fd=sys.__stdout__.fileno())
+ import pty
+ _, pty = pty.openpty()
+ curses.setupterm(fd=pty)
try:
stdscr = curses.initscr()
main(stdscr) (I've never used openpty, either in Python or in C, so I can't vouch for
Looking at the actual buildbot results, most of the *nix bots I checked So it looks like on most of the bots, buildbot is running without a tty. It'd be great if you can come up with a fix that gets the test running |
FYI I just added a reasonably generic function pty_run(script, input) -> output to Lib/test/test_readline.py:120 for bpo-26870. It runs a Python script string in a child process under a pseudo-terminal. If you need to drive the curses tests with a pseudo-terminal, my code may be useful. There were about six different bugs and platform-specific quirks to work around (affecting Open BSD, Linux and various OS X versions), so I recommend learning from my experience rather than doing it all from scratch :) Also, test_curses on Python 2 fails for me, but that is probably a separate bug. |
It was fixed in other way in bpo-42789. If __stdout__ is not a terminal, the code falls back to __stderr__, and it is not terminal either, it tries to open /dev/tty. If neither works, it uses a regular temporary file as terminal, but savetty()/resetty() and few tests are skipped. It would be better to use pty, but I found that it does not work if tests output more than 2 KB. For now I do not know how to fix it. |
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: