[ python-Bugs-780576 ] test_ioctl fails

Fri Sep 23 09:35:58 CEST 2005

Bugs item #780576, was opened at 2003-07-30 16:04
Message generated for change (Comment added) made by mdavidoff
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=780576&group_id=5470

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: Build
Group: Python 2.3
Status: Open
Resolution: None
Priority: 5
Submitted By: Jean M. Brouwers (jbrouwers)
Assigned to: Anthony Baxter (anthonybaxter)
Summary: test_ioctl fails

Initial Comment:
Test case test_ioctl fails when building Python 2.3 on
RedHat 8.0, but just one one and not another RedHat 8.0
machine.  The initial suspicion was that this failure
may be related to this bug report:

http://sourceforge.net/tracker/?group_id=5470&amp;atid=105470&amp;func=detail&amp;aid=777867

but that was reported on Debian unstable.  It could
still be a glibc bug that Python is tickling but the
glibc libraries are the same one both machines (at
least there is no difference in the version numbers
from rpm).

  rpm -qa | grep -i glibc
  glibc-devel-2.3.2-4.80.6
  glibc-kernheaders-2.4-7.20
  glibc-common-2.3.2-4.80.6
  glibc-2.3.2-4.80.6

----------------------------------------------------------------------

Comment By: Monte Davidoff (mdavidoff)
Date: 2005-09-23 00:35

Message:
Logged In: YES 
user_id=1200009

The fix for this bug was included in Patch 1284289:

Lib/test/test_ioctl.py -- Fixed bug in import statement for
test.test_support. Fixed bug where the test would fail if
the test suite was being run in the backgroud. In this case,
the TIOCGPGRP ioctl on /dev/tty returns the session ID, not
the process group ID.

See also bug 777867.

----------------------------------------------------------------------

Comment By: Hakanson (hakansonsf)
Date: 2004-08-31 15:30

Message:
Logged In: YES 
user_id=1103758

Sorry, that was not helpful:  I meant test TIOCGPGRP
on a pseudo-tty that the testing process creates.

Another alternative would be to test some STREAMS
ioctl against a stream/pipe that the process creates.

But yes, this quickly gets complicated.

----------------------------------------------------------------------

Comment By: Hakanson (hakansonsf)
Date: 2004-08-16 11:08

Message:
Logged In: YES 
user_id=1103758

Maybe test TIOCGPGRP on a file/directory that the test
creates anew, instead of /dev/tty.  That should definitely
match the process group of the current process.

----------------------------------------------------------------------

Comment By: Michael Hudson (mwh)
Date: 2004-08-14 06:53

Message:
Logged In: YES 
user_id=6656

Oh, crud.

However, if we don't test TIOCGPGRP, what *can* we test?

Perhaps we should just test that the call doesn't blow up.

----------------------------------------------------------------------

Comment By: Hakanson (hakansonsf)
Date: 2004-08-13 15:57

Message:
Logged In: YES 
user_id=1103758

Folks,

I recently completed a build of python-2.3.2 (I realize
2.3.4 is out, but this info should still be relevant) on
SPARC/Solaris-9, and as in this bug, the test_ioctl is
failing.  However, I believe I have found the cause, after
running the tests with "-v" added to TESTOPTS in the
Makefile.  Since I have found no other mention of this
particular cause for the failure, perhaps others will find
this information helpful.

The test is failing because the process group returned from
the OS (the getpgrp() system call) does not match the
process group associated with /dev/tty (as returned by the
TIOCGPGRP ioctl() call).  Now it turns out that this is not
really an error, because some command shells (ksh, csh,
perhaps bash), will assign each new command to a new process
group, in order to do job-control (^Z interruption, moving
to/from background, etc.).

So, at least on this platform, using ksh, the test_ioctl
will _always_ fail, since the "make" command gets a process
group different from that of the parent shell, and different
from /dev/tty's process group (which matches the parent shell).

Therefor it would probably be better to test some other
ioctl() call than the TIOCGPGRP call, or otherwise rework
the test so it doesn't fail under what can be normal
circumstances on some platforms.

Regards,

Marion

----------------------------------------------------------------------

Comment By: Michael Hudson (mwh)
Date: 2003-08-05 03:48

Message:
Logged In: YES 
user_id=6656

You're supposed to run

./python ./Lib/test/regrtest.py test_ioctl

or maybe

./python ./Lib/test/regrtest.py -v test_ioctl

----------------------------------------------------------------------

Comment By: Foo Man Bar (drauh)
Date: 2003-08-05 00:39

Message:
Logged In: YES 
user_id=91293

Blah. I was too hasty: while &quot;./python
./Lib/test/test_ioctl.py&quot; passed after making the
modification I mentioned, a re-run of &quot;make test&quot; at the top
level says that test_ioctl failed.  Before I did the &quot;make
test&quot;, I did make sure to delete test_ioctl.pyc.

----------------------------------------------------------------------

Comment By: Foo Man Bar (drauh)
Date: 2003-08-05 00:18

Message:
Logged In: YES 
user_id=91293

I compiled with gcc-3.2.3 (compiled from source) on a RH9
system.  The error message from doing &quot;./python
./Lib/test/test_ioctl.py&quot; (after appropriately setting
LD_LIBRARY_PATH) was:

  Traceback (most recent call last):
    File &quot;Lib/test/test_ioctl.py&quot;, line 2, in ?
      from test_support import TestSkipped, run_unittest
    File &quot;/opt/src/Python-2.3/Lib/test/test_support.py&quot;,
line 4, in ?
      raise ImportError, 'test_support must be imported from
the test package'
  ImportError: test_support must be imported from the test
package

In the file Lib/test/test_ioctl.py, if I replace:

  from test_support import TestSkipped, run_unittest

with

  from test.test_support import TestSkipped, run_unittest

the test passes as expected.  Gotta love error messages. ;)

----------------------------------------------------------------------

Comment By: Michael Hudson (mwh)
Date: 2003-08-01 09:21

Message:
Logged In: YES 
user_id=6656

IIRC, Anthony wrote the test.

Anthony, any other ideas?

----------------------------------------------------------------------

Comment By: Michael Hudson (mwh)
Date: 2003-08-01 09:20

Message:
Logged In: YES 
user_id=6656

Grr.

I wonder if we should find some other ioctl to test.

----------------------------------------------------------------------

Comment By: Jean M. Brouwers (jbrouwers)
Date: 2003-08-01 08:42

Message:
Logged In: YES 
user_id=832557

I ran both tests you requested, twice and all four passed. 
I also ran 'make tests' two more times and test_ioctl now
passes.

This is bizarre, but test_ioctl has failed only after a
fresh build, i.e. when running 'make clean; make install;
make test'.

----------------------------------------------------------------------

Comment By: Michael Hudson (mwh)
Date: 2003-08-01 04:21

Message:
Logged In: YES 
user_id=6656

Oh good &lt;wink&gt;

Can you try:

./python ./Lib/test/regrtest.py

(this should run all the tests)

and 

./python ./Lib/test/regrtest.py test_fork1 test_ioctl

(I *suspect* that it's test_fork1 that messes up the
environment such that the ioctl test fails, but it's just a
guess).

----------------------------------------------------------------------

Comment By: Jean M. Brouwers (jbrouwers)
Date: 2003-07-31 11:58

Message:
Logged In: YES 
user_id=832557

One more piece of data.  If I run the test as

   python  regrtest.py  -s  test_ioctl.py

it passsed every single time on the same machine where the
failures occurred.

----------------------------------------------------------------------

Comment By: Jean M. Brouwers (jbrouwers)
Date: 2003-07-31 09:54

Message:
Logged In: YES 
user_id=832557

Here is more background info.

I built Python 2.3 (final) several times and ran &quot;make test&quot;
as part of that.  The ioctl_test failed two out of three
times on one machine and did not fail on another machine. 
Different machines but the same RH 8 versions.

Also, I built several Python beta releases (2.3b1, 2.3b2 and
2.3c2 if I recall correctly) all just once and the test
failed there too.

I haven't checked further details and don't know whether
this is classified as Heisenbug-like behavior or not.  But
if the test fails, the error message is &quot;test_ioctl failed
-- errors occurred in test.test_ioctl.IoctlTests&quot;.

----------------------------------------------------------------------

Comment By: Michael Hudson (mwh)
Date: 2003-07-31 03:27

Message:
Logged In: YES 
user_id=6656

Does your failure exhibit the same heisenbug-like qualities
as #777867? (e.g. can you reproduce it running tests via
regrtest?  does it fail in isolation?)

Does it fail in the same way, i.e. returning different
numbers from the ioctl() call than the getpgrp() call?

It doesn't fail on my sorta RH 7.2 box, but I'm thinking of
upgrading soon anyway...

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=780576&group_id=5470