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&atid=105470&func=detail&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

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

Logged In: YES 
user_id=832557

Here is more background info.

I built Python 2.3 (final) several times and ran "make test"
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 "test_ioctl failed
-- errors occurred in test.test_ioctl.IoctlTests".

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.

Logged In: YES 
user_id=6656

Oh good <wink>

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

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

Logged In: YES 
user_id=6656

Grr.

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

Logged In: YES 
user_id=6656

IIRC, Anthony wrote the test.

Anthony, any other ideas?

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 "./python
./Lib/test/test_ioctl.py" (after appropriately setting
LD_LIBRARY_PATH) was:

  Traceback (most recent call last):
    File "Lib/test/test_ioctl.py", line 2, in ?
      from test_support import TestSkipped, run_unittest
    File "/opt/src/Python-2.3/Lib/test/test_support.py",
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. ;)

Logged In: YES 
user_id=91293

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

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

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

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.

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.

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.

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.

Logged In: YES 
user_id=1188172

Verified. Closing accordingly.