- edited description
test failure on ARM
Fedora recently started using ARM machines to build some packages, and I found that one of the tests in pexpect-u is failing with a timeout. Here is the specific output:
+ nosetests
........E...............................................................................
======================================================================
ERROR: This tests that we can send all special control codes by name.
----------------------------------------------------------------------
Traceback (most recent call last):
File "/builddir/build/BUILD/pexpect-u-2.5.1/pexpect/tests/test_ctrl_chars.py", line 62, in test_sendcontrol
child.expect ('[0-9]+\r\n')
File "/builddir/build/BUILD/pexpect-u-2.5.1/pexpect/__init__.py", line 1354, in expect
return self.expect_list(compiled_pattern_list, timeout, searchwindowsize)
File "/builddir/build/BUILD/pexpect-u-2.5.1/pexpect/__init__.py", line 1368, in expect_list
return self.expect_loop(searcher_re(pattern_list), timeout, searchwindowsize)
File "/builddir/build/BUILD/pexpect-u-2.5.1/pexpect/__init__.py", line 1452, in expect_loop
raise TIMEOUT (str(e) + '\n' + str(self))
TIMEOUT: Timeout exceeded in read_nonblocking().
<pexpect.spawn object at 0x1ea2d30>
version: 2.5.1
command: /usr/bin/python
args: ['/usr/bin/python', 'getch.py']
searcher: searcher_re:
0: re.compile("[0-9]+
")
buffer (last 100 chars): ^A
before (last 100 chars): ^A
after: <class 'pexpect.TIMEOUT'>
match: None
match_index: None
exitstatus: None
flag_eof: False
pid: 27055
child_fd: 3
closed: False
timeout: 30
delimiter: <class 'pexpect.EOF'>
logfile: None
logfile_read: None
logfile_send: None
maxread: 2000
ignorecase: False
searchwindowsize: None
delaybeforesend: 0.05
delayafterclose: 0.1
delayafterterminate: 0.1
-------------------- >> begin captured stdout << ---------------------
pexpect.tests.test_ctrl_chars.TestCtrlChars.test_sendcontrol
--------------------- >> end captured stdout << ----------------------
Comments (22)
-
reporter -
repo owner I don't know much about ARM or the subtleties of controlling child processes - I only really forked pexpect to add Python 3 support. Any help finding and fixing issues like this would be much appreciated.
-
reporter I have no idea, either. I would have assumed that everything was about the same, and unfortunately, I don't actually have direct access to any ARM machine to try anything on. :(
-
reporter By the way, the other tests seem to be working, right? Is there anything that's different about this particular test?
-
repo owner I don't think so. Is the failure reproducible? Timeout errors can sometimes occur just by chance, especially if the test runner is slow or busy.
-
reporter It's failed during three different test builds that were spread over a few weeks. That and the timeout is 30 seconds, which seems really long even on a busy machine. Wouldn't it normally take a fraction of a second?
-
repo owner Yeah, that sounds like it's a real failure, then.
The only thing I can think of is that that line in the test is inside a loop of the letters of the alphabet - try printing each letter out as it is tested, so that we can find out which control character is causing the problem.
I don't really have access to an ARM machine either. There are a few Raspberry Pis around the office (I'm in Berkeley now), but I've never played with one, so it would probably take a while to get set up.
-
reporter It looks like it's possible to get an ARM virtual machine in Fedora:
Though I certainly won't get to this today.
By the way, I've opened up a Fedora bug for this, too: https://bugzilla.redhat.com/show_bug.cgi?id=999174
-
repo owner Thanks. I've subscribed to the Fedora bug so I can get updates from it.
-
reporter Zbigniew Jędrzejewski-Szmek has dug into this a little, and it looks like there might be a problem with the assumptions behind a lot of the tests:
pexpect uses a pty, so it sees both sides of the converstation: ====================================================================== FAIL: test_readlines (__main__.TestCaseMisc) ---------------------------------------------------------------------- Traceback (most recent call last): File "pexpect/tests/test_misc.py", line 56, in test_readlines AssertionError: readlines() did not work. page='abc\r\n123abc\r\n\r\n123\r\n' ---------------------------------------------------------------------- ... and it is expecting page == 'abc\r\nabc\r\n123\r\n123\r\n'. Another failure is: ====================================================================== FAIL: test_readline (__main__.TestCaseMisc) ---------------------------------------------------------------------- Traceback (most recent call last): File "pexpect/tests/test_misc.py", line 36, in test_readline AssertionError: readline(2) did not return 'abc\r\n'. Returned: '123abc\r\n' ---------------------------------------------------------------------- I think those tests should fail on other archs too, given appropriate delays. Try installing this program as 'cat' in the path for pexpect and run the tests: #!/usr/bin/python -u import sys, time, random while True: line = sys.stdin.readline() if not line: break time.sleep(random.random()) sys.stderr.write(line)
-
repo owner Note that I have a new fork of pexpect which keeps backwards compatibility better, and I'm in discussions with the original author to make that the official continuation of pexpect. https://github.com/pexpected/pexpect
-
repo owner @amcnabb8 I've run into the original error now on a slow machine, and hopefully fixed it. The test process is trying to send a control character before the child process is prepared to receive it. See this commit in my new fork:
https://github.com/pexpect/pexpect/commit/a6a7923837e2a9d7129bd69b4ee2bb34cb19f955
-
reporter I'm really confused now about what the official home of pexpect is. Is it pexpect on bitbucket, or is it pexpected on github, or is it pexpect on github? It would be very, very helpful to have a single unambiguous home for the latest pexpect, whatever it happens to be.
-
repo owner I know, sorry about the confusion. Short answer: pexpect on Github.
Long answer:
- It used to be on Sourceforge
- I forked it here (bitbucket)
- The original author got round to putting it on Github under his own account, but then went dormant again.
- I felt that I'd taken the wrong approach with my original fork, and made a new fork (pexpected) on Github, with a collaborator.
- I told Noah, the original author, about this, and he said I could use the name pexpect. So I renamed the new fork on Github to pexpect.
-
reporter The long answer is really helpful. Would you mind posting a similar explanation along with a redirect at: https://bitbucket.org/takluyver/pexpect/overview ?
Are there any backwards compatibility issues from pexpect-u to the new pexpect that I should try to warn Fedora users about?
-
repo owner Good point, I'll do that.
The new pexpect keeps closer to the original API of pexpect than pexpect-u did. The major difference is that the
spawnb
class in pexpect-u is closer to thespawn
class in pexpect (both old and new). The new pexpect adds aspawnu
class which is roughly equivalent tospawn
in pexpect-u. I appreciate that will cause some pain for Fedora packages that got switched to pexpect-u and back again, but hopefully not too drastic. -
reporter The main package to be concerned about is ipython, and by the way, this isn't so much a problem with the Fedora package as with the upstream project itself. If the upstream ipython project supports the new pexpect, then it shouldn't be any trouble to switch the Fedora package over.
-
repo owner I'm an IPython core developer, so I'll see to it that it supports the new pexpect ;-)
-
reporter That's reassuring. :) Is it supported in current versions of ipython? Fedora 18 has 0.13.2; I'm not sure which version Fedora 19 is expected to have, but it would be nice to get the test failures straightened out before Fedora 19 is released (soon).
-
repo owner We still support regular (old) pexpect, so hopefully there will be little or nothing that needs to change.
-
reporter Great. So, when do you expect to make the first numbered release on the pexpect github?
-
repo owner I hope to have a beta within a week or so - I'm beating tests and docs into shape now. Oh, and I'll be numbering it 3.0, since so long has passed since there was an official pexpect release.
- Log in to comment