This issue tracker has been migrated to GitHub, and is currently read-only.
For more information, see the GitHub FAQs in the Python's Developer Guide.

classification
Title: 2.3.3 hangs in test_fork1 and test_threadedtempfile
Type: Stage:
Components: Interpreter Core Versions: Python 2.3
process
Status: closed Resolution: wont fix
Dependencies: Superseder:
Assigned To: Nosy List: dcd, mwh, tim.peters
Priority: normal Keywords:

Created on 2004-01-21 22:28 by dcd, last changed 2022-04-11 14:56 by admin. This issue is now closed.

Messages (8)
msg19771 - (view) Author: David Dyck (dcd) Date: 2004-01-21 22:28
make test hangs in 2.3.3 
 test_fork1 and test_threadedtempfile

go get test to complete I needed to 
 ./python -E -tt ./Lib/test/regrtest.py -l -x
test_fork1 -x test_threadedtempfile

msg19772 - (view) Author: Tim Peters (tim.peters) * (Python committer) Date: 2004-01-22 01:18
Logged In: YES 
user_id=31435

Of course these tests pass on all the platforms the 
developers and testers used, else 2.3.3 wouldn't have been 
released.

So the most important bits of info are missing:  which OS, and 
which C compiler and runtime, and which thread 
implementation, are you using?
msg19773 - (view) Author: David Dyck (dcd) Date: 2004-01-22 01:41
Logged In: YES 
user_id=53855

thank you for reminding me of the questions I should have
answered
uname -a
Linux dd 2.4.25-pre6 #1 Fri Jan 16 13:23:13 PST 2004 i686
gcc -v
Reading specs from
/usr/lib/gcc-lib/i586-pc-linux-gnulibc1/egcs-2.91.66.1/specs
gcc version egcs-2.91.66.1 19990314/Linux (egcs-1.1.2
release)

libc.so.5.4.44

dd:lib$ which python
/usr/local/bin/python
dd:lib$ python -V
Python 2.3.3
dd:lib$ ldd /usr/local/bin/python
        libpthread.so.0 => /lib/libpthread.so.0 (0x4000c000)
        libdl.so.1 => /lib/libdl.so.1 (0x4001d000)
        libm.so.5 => /lib/libm.so.5 (0x40020000)
        libc.so.5 => /lib/libc.so.5 (0x40029000)

(my perl installation doesn't link
with any threads - I've don't
think any application on this linux
system have used pthread either)

msg19774 - (view) Author: Michael Hudson (mwh) (Python committer) Date: 2004-01-22 11:03
Logged In: YES 
user_id=6656

You have a 2.4 kernel and are linking against libc *5*?!  Why?

msg19775 - (view) Author: David Dyck (dcd) Date: 2004-01-23 05:00
Logged In: YES 
user_id=53855

Since you asked.

It is quite simple to upgrade the kernel, and I've been
doing it since 1996.  It's a bit more difficult to upgrade
libc's so I've stuck with what's working.

It's gotten to the point that I've been trying to see how long
I can go before I have to upgrade to libc6.  I'm hoping that
Python is portable enough that I don't have to upgrade my
libc to get it working (I didn't have to upgrade my libc to
get Perl running :-)
msg19776 - (view) Author: Michael Hudson (mwh) (Python committer) Date: 2004-01-23 10:29
Logged In: YES 
user_id=6656

Fair enough, I suppose.  I doubt you'll get threads working
on such a system, though, as python tickles bugs in old
versions of pthreads.  You can try passing --disable-threads
(think that's the right incantation) to configure.
msg19777 - (view) Author: David Dyck (dcd) Date: 2004-01-23 17:24
Logged In: YES 
user_id=53855

I was able to make some more progress, using
--without-threads
to disable the threads in v2.3.3 
    ./configure --without-threads && make

but I was surprised how threads were twisted into the rest
of the python modules (or at least their test cases

*** WARNING: renaming "_testcapi" since importing it failed:
Unable to resolve s
*** WARNING: renaming "_socket" since importing it failed:
Unable to resolve sym
*** WARNING: renaming "bsddb185" since importing it failed:
Unable to resolve sy
*** WARNING: renaming "dbm" since importing it failed:
Unable to resolve symbol
*** WARNING: renaming "_curses" since importing it failed:
Unable to resolve sym
*** WARNING: renaming "zlib" since importing it failed:
Unable to resolve symbol


*** WARNING: renaming "_ssl" since importing it failed: No
module named _socket
*** WARNING: renaming "_curses_panel" since importing it
failed: No module named

It was surprising that zlib would depend on threads but
more detail reveals the following from the build:
./python: can't resolve symbol 'PyThread_acquire_lock'
./python: can't resolve symbol 'PyThread_allocate_lock'
./python: can't resolve symbol 'PyThread_release_lock'

msg19778 - (view) Author: David Dyck (dcd) Date: 2004-01-24 00:04
Logged In: YES 
user_id=53855

As I mentioned in the 2004-01-23 17:24 message,
I was able to make some more progress, using
  --without-threads
to disable the threads in v2.3.3   (e.g.)
 ./configure --without-threads && make

I should have done a make clean first !!!!
then I received less errors.

  (I'd like to mark this as "resolved" to
the point that linux/libc5 is not expected
to have functional threads, as I'm not
looking for threads in Python at this time)

I'll look into the other errors and report them
separately.   For now
  ./configure --without-threads
is effective enough.


*** WARNING: renaming "bsddb185" since importing it failed:
Unable to resolve symbol
*** WARNING: renaming "dbm" since importing it failed:
Unable to resolve symbol
*** WARNING: renaming "_curses" since importing it failed:
Unable to resolve symbol
*** WARNING: renaming "_curses_panel" since importing it
failed: No module named _curses
History
Date User Action Args
2022-04-11 14:56:02adminsetgithub: 39849
2004-01-21 22:28:08dcdcreate