[Python-bugs-list] [Bug #110635] test_signal hangs when running as part of testall (PR#288)

noreply@sourceforge.net noreply@sourceforge.net
Tue, 19 Sep 2000 05:45:09 -0700


Bug #110635, was updated on 2000-Jul-31 14:09
Here is a current snapshot of the bug.

Project: Python
Category: Core
Status: Closed
Resolution: None
Bug Group: Platform-specific
Priority: 1
Summary: test_signal hangs when running as part of testall (PR#288)

Details: Jitterbug-Id: 288
Submitted-By: kessler@ccdc.cam.ac.uk
Date: Tue, 11 Apr 2000 06:58:39 -0400 (EDT)
Version: 1.6a2
OS: Irix6.3


Under Irix6.3 (python compiled in -n32 mode with MipsPro 7.2.1), test_signal
works fine (?) if you run it on its own:

>>> import test.test_signal
starting pause() loop...
call pause()...
+ kill -5 7487 
+ sleep 2 
handlerA (5, <frame object at 100cf928>)
pause() returned
call pause()...
+ kill -2 7487 
+ sleep 2 
handlerB (2, <frame object at 100cf928>)
HandlerBCalled exception caught
call pause()...
+ kill -3 7487 
KeyboardInterrupt (assume the alarm() went off)

however, as part of the test suite, this test hangs:

>>> import test.testall
[...]
test_signal
test_signal
+ sleep 2 
starting pause() loop...
call pause()...
+ kill -5 7454 
+ sleep 2 
+ kill -2 7454 
+ sleep 2 
+ kill -3 7454 





====================================================================
Audit trail:
Tue Jul 11 08:29:16 2000	guido	moved from incoming to open

Follow-Ups:

Date: 2000-Jul-31 14:09
By: none

Comment:
From: Guido van Rossum <guido@python.org>
Subject: Re: [Python-bugs-list] test_signal hangs when running as part of testall (PR#288)
Date: Tue, 11 Apr 2000 11:27:20 -0400

> Under Irix6.3 (python compiled in -n32 mode with MipsPro 7.2.1), test_signal
> works fine (?) if you run it on its own:
> 
> >>> import test.test_signal
> starting pause() loop...
> call pause()...
> + kill -5 7487 
> + sleep 2 
> handlerA (5, <frame object at 100cf928>)
> pause() returned
> call pause()...
> + kill -2 7487 
> + sleep 2 
> handlerB (2, <frame object at 100cf928>)
> HandlerBCalled exception caught
> call pause()...
> + kill -3 7487 
> KeyboardInterrupt (assume the alarm() went off)
> 
> however, as part of the test suite, this test hangs:
> 
> >>> import test.testall
> [...]
> test_signal
> test_signal
> + sleep 2 
> starting pause() loop...
> call pause()...
> + kill -5 7454 
> + sleep 2 
> + kill -2 7454 
> + sleep 2 
> + kill -3 7454 

Yes, I've seen this too.  Unfortunately, I don't have a clue, and I
don't have the time to delve into it...  I bet there's a compile time
#define that might do it.  It may have something to do with threads...

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


-------------------------------------------------------

Date: 2000-Aug-02 04:05
By: twouters

Comment:
Unsure if this is still an actual problem, but I've seen similar behaviour of test_signal on BSDI 4.0 and 4.0.1 systems, when Python was compiled with threads. The problem appeared to be the BSDI thread library, which had (among other things) problems with pause() in threaded code.

I haven't tried to enable threading on 4.0.x for a while, since new systems are 4.1, and 4.1 works properly with threads.

Does disabling threads fix the problem ? (Or perhaps *en*abling them, if they weren't ?)


-------------------------------------------------------

Date: 2000-Sep-07 15:01
By: jhylton

Comment:
Please do triage on this bug.
-------------------------------------------------------

Date: 2000-Sep-07 15:02
By: jhylton

Comment:
Please do triage on this bug.
-------------------------------------------------------

Date: 2000-Sep-18 18:35
By: jhylton

Comment:
I've got no hope of fixing an IRIX bug.  At least you've used IRIX <0.2 wink>

-------------------------------------------------------

Date: 2000-Sep-18 18:51
By: gvanrossum

Comment:
I've got no hope either. I'll write the submittor. I've lowered the priority to 1 -- meaning I won't lose sleep over this.
-------------------------------------------------------

Date: 2000-Sep-19 05:45
By: gvanrossum

Comment:
Original submittor lost access to SGI hardware. Closing since there's not much we can do about this.
-------------------------------------------------------

For detailed info, follow this link:
http://sourceforge.net/bugs/?func=detailbug&bug_id=110635&group_id=5470