test failure on ARM

[amcnabb8]

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 << ----------------------

[Thomas Kluyver]

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.

[amcnabb8]

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. :(

[amcnabb8]

By the way, the other tests seem to be working, right? Is there anything that's different about this particular test?

[Thomas Kluyver]

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.

[amcnabb8]

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?

[Thomas Kluyver]

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.

[amcnabb8]

It looks like it's possible to get an ARM virtual machine in Fedora:

http://fedoraproject.org/wiki/Architectures/ARM/F19/Installation#For_Versatile_Express_Emulation_with_QEMU

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

[Thomas Kluyver]

Thanks. I've subscribed to the Fedora bug so I can get updates from it.

[amcnabb8]

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)

[Thomas Kluyver]

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

[Thomas Kluyver]

@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

[amcnabb8]

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.

[Thomas Kluyver]

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.

[amcnabb8]

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?

[Thomas Kluyver]

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 the spawn class in pexpect (both old and new). The new pexpect adds a spawnu class which is roughly equivalent to spawn 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.

[amcnabb8]

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.

[Thomas Kluyver]

I'm an IPython core developer, so I'll see to it that it supports the new pexpect ;-)

[amcnabb8]

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).

[Thomas Kluyver]

We still support regular (old) pexpect, so hopefully there will be little or nothing that needs to change.

[amcnabb8]

Great. So, when do you expect to make the first numbered release on the pexpect github?

[Thomas Kluyver]

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.