[Python-bugs-list] [ python-Bugs-479981 ] test_socket fails when compiled with threads (HP-UX)
noreply@sourceforge.net
noreply@sourceforge.net
Thu, 13 Dec 2001 07:42:11 -0800
Bugs item #479981, was opened at 2001-11-09 05:01
You can respond by visiting:
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=479981&group_id=5470
Category: Threads
Group: Python 2.2
>Status: Closed
>Resolution: Wont Fix
Priority: 5
Submitted By: Nobody/Anonymous (nobody)
Assigned to: Nobody/Anonymous (nobody)
Summary: test_socket fails when compiled with threads (HP-UX)
Initial Comment:
Operating System HP-UX 11.0 (64 Bit)
I tried to compile Python 2.1.1 this thread support.
Doing so, the tests
test_socket and test_asynchat both failed
with "(9, 'Bad file number')"
The test_socket succeds if I compiled python without
threads, so I think it's an thread-problem.
The thread-test istself succeeds.
I think also, that python is correctly linked against
libpthread.
The same Problem occurs this Python 2.2.b1.
----------------------------------------------------------------------
>Comment By: Martin v. Löwis (loewis)
Date: 2001-12-13 07:42
Message:
Logged In: YES
user_id=21627
Closing it. It could be anything: a bug in Python, in the
operating system, or in gcc. Since none of the HP-UX users
is confirming the problem, it is unlikely that we can
resolve it.
----------------------------------------------------------------------
Comment By: Guido van Rossum (gvanrossum)
Date: 2001-12-11 06:24
Message:
Logged In: YES
user_id=6380
But how are we ever going to find out what to do about this?
I'm tempted to close this -- what good is keeping it open
going to do it?
----------------------------------------------------------------------
Comment By: Michael Hudson (mwh)
Date: 2001-12-11 06:10
Message:
Logged In: YES
user_id=6656
Chaned summary.
----------------------------------------------------------------------
Comment By: Nobody/Anonymous (nobody)
Date: 2001-11-15 08:15
Message:
Logged In: NO
1. As expected, there is no change whether to lock
gethostbyname or not.
2. gethostbyname is said to be threadsafe at least with
HPUX 11.00 and should it be on further releases.
HPUX 10.X don't support native Threads anyway
3. Python 2.1 run's on 32 Bit HP-UX-Machines
4. On 64 Bit HP-UX Machines I have found that some Patches
are nessesary.
I don't know what exact Patch is required but have some
experiences with HP-UX General-Release Patch-Bundles:
September 2000 - python failed
June 2001 or later - python works
maybe this helps someone
----------------------------------------------------------------------
Comment By: Martin v. Löwis (loewis)
Date: 2001-11-14 06:43
Message:
Logged In: YES
user_id=21627
Python puts a lock around gethostbyname if gethostbyname_r
is not available. I don't think that should cause a problem
even if gethostbyname is thread-safe. If you want to further
analyse this, you could try to put an && !defined(__hpux)
around the line
#define USE_GETHOSTBYNAME_LOCK
If you do, please report whether it works. In that case, it
would be good to know whether gethostbyname is thread-safe
on *all* HP-UX versions, or just on some.
Furthermore, since this wasn't reported before: Is it
specific to your installation, or reproducable on all
installations? Is it perhaps specific to 64-bit mode?
----------------------------------------------------------------------
Comment By: Nobody/Anonymous (nobody)
Date: 2001-11-12 02:12
Message:
Logged In: NO
Maybe the failure has to do with gethostbyname-stuff.
according the hpux-manpages theese reentrant interfaces are
obsolete:
int gethostent_r(struct hostent *result,
struct hostent_data *buffer);
int gethostbyname_r(const char *name,
struct hostent *result,
struct hostent_data *buffer);
int gethostbyaddr_r(const char *addr,
int len,
int type,
struct hostent *result,
struct hostent_data *buffer);
int sethostent_r(int stayopen, struct hostent_data
*buffer);
int endhostent_r(struct hostent_data *buffer);
The configure-script has correctly found, that there is only
a gethostbyname, but no gethostbyname_r.
according to the man-pages the call to gethostbyname IS
thread-save:
struct hostent *gethostent(void);
struct hostent *gethostbyname(const char *name);
struct hostent *gethostbyaddr(const char *addr,
int len,
int type);
...
MULTITHREAD USAGE
Thread Safe: Yes
Cancel Safe: Yes
Async-cancel Safe: No
Async-signal Safe: No
Is it a failure to expect the gethostbyname to be not
thread-save ?
----------------------------------------------------------------------
Comment By: Nobody/Anonymous (nobody)
Date: 2001-11-12 01:29
Message:
Logged In: NO
the complete compiler line used to link together the python
binary:
gcc -Wl,-E -Wl,+s -Wl,+b/mosquito/python/lib/python2.1/lib-
dynload -o python \
Modules/python.o \
libpython2.1.a -lnsl -ldld -lpthread -lm
The compiler I used is gcc 3.01.
I tried it out with the cc from HP - the same effect
After installing the Kernelpatch PHKL_25475, wich supersedes
both PHKL_23842 and PHKL_20942 the failure remains the same
----------------------------------------------------------------------
Comment By: Martin v. Löwis (loewis)
Date: 2001-11-09 16:13
Message:
Logged In: YES
user_id=21627
Can you please also check whether the patches PHKL_23842 (or
equivalent) and/or PHKL_20942.
The patch titles are
PHKL_23842 s700_800 11.00
signal,threads,spinlock,scheduler,IDS,q3p
PHKL_20942 s700_800 11.00
signal, nanosleep, spinlock, scheduler
It appears that HP-UX has a number of bugs where signals,
forking, and other aspects of the operating functionality
stop working in the presence of threads. If you don't have
these patches, it would be good if you could try to install
them, and report back whether it changes anything.
Notice that HP apparently has a number of patches with these
titles; they seem to be intended for different machines.
----------------------------------------------------------------------
Comment By: Martin v. Löwis (loewis)
Date: 2001-11-09 15:51
Message:
Logged In: YES
user_id=21627
What compiler are you using? Can you please report the
complete compiler line used to link together the python binary?
----------------------------------------------------------------------
You can respond by visiting:
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=479981&group_id=5470