[ python-Bugs-780576 ] test_ioctl fails
SourceForge.net
noreply at sourceforge.net
Mon Aug 16 20:08:18 CEST 2004
Bugs item #780576, was opened at 2003-07-30 16:04
Message generated for change (Comment added) made by hakansonsf
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=780576&group_id=5470
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&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
----------------------------------------------------------------------
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 "./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.
----------------------------------------------------------------------
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 "./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. ;)
----------------------------------------------------------------------
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 <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).
----------------------------------------------------------------------
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 "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".
----------------------------------------------------------------------
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
More information about the Python-bugs-list
mailing list