Re: Can we reproduce this?

[Inyeol]
> > > > > When I try 'make test' during building python2.3a1 with
> > > > > gcc2.95.3 in Solaris8, it stops at 'test_signal' - it stays
> > > > > there until the process is killed via kill -9.

[Others]
> > > > This is a known problem, which occurs in the farm as well. We
> > > > have as yet no good leads.

[Neal]
> > > I just ran test_socket a bunch of times on our sun without
> > > problems.  I believe Martin von Loewis and Andrew Koenig also
> > > use a solaris box fairly regularly.  (Hopefully Martin is
> > > reading this list and can confirm.)
> > > 
> > > So the problem may be limited to the snake farm and a few other
> > > boxes.

[Guido]
> > Most likely it's dependent on a particular combination of software
> > versions.  It's worth trying to find out which versions the snake-farm
> > and inyeol's box have in common.

[Neal]
> Looks like I goofed.  I thought this problem affected 2.2.2+ as well.
> So I didn't spent any time hunting down the problem.  However, the
> problem does not affect 2.2.2.
> 
> 2.2.2+ runs all tests to completion.  There is a problem that
> _socket.so isn't built due to libssl issues.  I don't think this
> changes anything although test_asynchat and test_socket fail.
> test_queue succeeds.  More on the significance of these tests in a
> bit.
> 
> 2.3 runs test_signal by itself ok.  test_signal only hangs when run
> with any one of these 4 tests: test_asynchat, test_logging,
> test_queue, and test_socket.

> When I run the 2.3 tests like:
> 
>         ./python -E -tt ./Lib/test/regrtest.py \
>                   -x test_asynchat test_logging test_queue test_socket
> 
> everything works.
> 
> One thing these 4 tests share is threads.  I arrived at this
> conclusion by the following:
> 
>         1. found one test that caused test_signal to hang (test_asynchat)
>         2. ran all tests -x test_asynchat, test_signal still hung
>         3. looked for possible issues, determined the likely problem 
>            to be threading
>         4. ran all tests -x all modules which import thread*
>                 (test_asynchat test_fork1 test_logging test_queue test_socket)>         5. tried removing each of those, only test_fork1 runs ok with
>                 test_signal
> 
> I built 2.3 on proton, 2.2 on fafner.  I tried running the 2.2 and 2.3
> tests on both machines.  So it's possibly a build env't on proton,
> but it's not a runtime env't since the problem is the same on both boxes.
> 
> Anybody have any clues?  I'll continue to investigate.

I was going to suggest threads as well -- threads and signals mix
notoriously poorly.

But what could be the difference between 2.2.2 and 2.3 here?  Scan the
revisions of the pthread and thread code -- I think there were changes
related to threads.

Maybe dummy_thread has something to do with this?  (I doubt it, but
who knows, maybe there are in fact no threads on that platform.)

Does Solaris have something like strace?  That might give a clue
(compare a 2.2.2 and a 2.3 run).

I don't think changes in the Queue module or its unit tests are that
significant, so I think we have to look for changes in the thread
implementation.

That's all I can think of for now.

--Guido van Rossum (home page: http://www.python.org/~guido/)