classification
Title: test_pty fails on HP-UX and AIX when run after test_openpty
Type: behavior Stage:
Components: Tests Versions: Python 2.4
process
Status: closed Resolution: out of date
Dependencies: Superseder:
Assigned To: nnorwitz Nosy List: BreamoreBoy, ajaksu2, hoffman, mdr0, mlorenzen, mwh, nnorwitz, rptownsend, sable
Priority: normal Keywords:

Created on 2003-04-01 07:35 by rptownsend, last changed 2010-09-14 13:07 by sable. This issue is now closed.

Messages (11)
msg15337 - (view) Author: Richard Townsend (rptownsend) Date: 2003-04-01 07:35
Here is the output from test_pty.py:

capulet:dist/src > ./python Lib/test/test_pty.py
Calling master_open()
Got master_fd '3', slave_name '/dev/pts/0'
Calling slave_open('/dev/pts/0')
Got slave_fd '4'
Traceback (most recent call last):
  File "Lib/test/test_pty.py", line 58, in ?
    test_basic_pty()
  File "Lib/test/test_pty.py", line 29, in 
test_basic_pty
    if not os.isatty(slave_fd):
  File "Lib/test/test_pty.py", line 50, in handle_sig
    raise TestFailed, "isatty hung"
test.test_support.TestFailed: isatty hung


This was running Python 2.3a2 (downloaded from 
CVS on Sunday 30th March) built on HP-UX11i.
msg15338 - (view) Author: Michael Hudson (mwh) (Python committer) Date: 2003-04-01 10:26
Logged In: YES 
user_id=6656

Neal?  I thought you thought this was fixed?
msg15339 - (view) Author: Neal Norwitz (nnorwitz) * (Python committer) Date: 2003-04-01 16:02
Logged In: YES 
user_id=33168

I fixed the test hanging, but not the actual bug.  The bug
appears when running test_pty after test_openpty.  There's
some interaction, but I don't know what it is.  The problem
happens on AIX also.  I searched through some man pages, but
nothing leapt out at me.  I think I tried googling for the
answer to no avail. Any insight or ideas would be helpful. 
This may have started when adding /dev/ptmx (ptc for AIX)
support.
msg15340 - (view) Author: Neal Norwitz (nnorwitz) * (Python committer) Date: 2003-04-01 16:31
Logged In: YES 
user_id=33168

Actually, there is a 'fix' which is really a work-around the
problem.  You can disable os.openpty() in pty.master_open. 
I added a raise OSError at line 50 (before os.openpty()). 
This allows the test to pass.  I think Martin and I agreed
that globally disabling wasn't the best solution.  That
would probably be in some patch.

Also, just in case it isn't clear--if you run test_pty
BEFORE test_openpty, both tests pass.
msg15341 - (view) Author: Mark D. Roth (mdr0) Date: 2004-03-10 17:22
Logged In: YES 
user_id=994239

I'm running into this problem under both AIX 4.3.3 and 5.1.
 Is this going to cause a problem if I put python into
produciton, or is it "safe" to ignore it?
msg15342 - (view) Author: Richard Townsend (rptownsend) Date: 2004-07-12 08:30
Logged In: YES 
user_id=200117

This still happens with Python-2.4.0a1 on HP-UX11i
msg15343 - (view) Author: Michael Hoffman (hoffman) Date: 2005-01-25 16:29
Logged In: YES 
user_id=987664

This happens with Python 2.4 on Tru64Unix V5.1 when
compiling using gcc-3.4.3, but not if you use the vendor cc.
msg15344 - (view) Author: Neal Norwitz (nnorwitz) * (Python committer) Date: 2006-02-20 19:05
Logged In: YES 
user_id=33168

Can you test with the patch in bug report: 
https://sourceforge.net/tracker/index.php?func=detail&aid=1433877&group_id=5470&atid=105470
?  I wonder if that fixes the problem.  Though I'm not sure
the same code is executed or not.
msg15345 - (view) Author: Mark Lorenzen (mlorenzen) Date: 2006-03-07 12:32
Logged In: YES 
user_id=1469902

I have the same problem with Python 2.4.2 running on AIX 5.2.

The test test_pty hangs for 10 seconds after which it is
aborted by a time-out condition. I have traced the system
calls and it turns out that the following scenario occurs:

1) os.write(slave_fd, TEST_STRING_2[:5])
2) os.write(slave_fd, TEST_STRING_2[5:])
3) s2 = os.read(master_fd, 1024)
[...]
4) os.close(slave_fd)

At 3) we only read the first part of the string written in
1) and not the complete string written in both 1) and 2).
The close() call then hangs in 4) (as it is waiting for
slave_fd to be flushed?).

The solution is to continue reading until a newline
character is read ie. readling a complete line. The patch is
shown below.

*** Lib/test/test_pty.py.orig   2004-02-12 7:35:11.000000000
+0000
--- Lib/test/test_pty.py        2006-03-07 2:05:39.000000000
+0000
***************
*** 40,47 ****
      debug("Writing chunked output")
      os.write(slave_fd, TEST_STRING_2[:5])
      os.write(slave_fd, TEST_STRING_2[5:])
!     s2 = os.read(master_fd, 1024)
!     sys.stdout.write(s2.replace("\r\n", "\n"))
  
      os.close(slave_fd)
      os.close(master_fd)
--- 40,49 ----
      debug("Writing chunked output")
      os.write(slave_fd, TEST_STRING_2[:5])
      os.write(slave_fd, TEST_STRING_2[5:])
!     s2 = "";
!     while not s2 or s2[-1] != "\n":
!         s2 = s2 + os.read(master_fd, 1024)
!     sys.stdout.write(s2.replace("\r\n", "\n"));
  
      os.close(slave_fd)
      os.close(master_fd)
msg81496 - (view) Author: Daniel Diniz (ajaksu2) (Python triager) Date: 2009-02-09 21:45
Unless this still is a confirmed problem in supported platforms, closing
suggested.
msg114234 - (view) Author: Mark Lawrence (BreamoreBoy) * Date: 2010-08-18 15:32
Closed as suggested in msg81496.
History
Date User Action Args
2010-09-14 13:07:31sablesetnosy: + sable
2010-08-18 15:32:55BreamoreBoysetstatus: open -> closed

nosy: + BreamoreBoy
messages: + msg114234

resolution: out of date
2009-02-09 21:45:54ajaksu2setnosy: + ajaksu2
type: behavior
messages: + msg81496
components: + Tests, - Build
2003-04-01 07:35:41rptownsendcreate