Threading issue in cygwin python 2.5.1-2 ?

[Jim Kleckner]

Dave Korn wrote:
> On 26 January 2008 02:27, Jim Kleckner wrote:
>
>   
>>> Thanks for providing a testcase.  Should be fixed in CVS:
>>> <http://www.cygwin.com/ml/cygwin-patches/2007-q3/msg00013.html>
>>>       
>> I have a python application that works fine
>> on Linux and Mac but fails with Cygwin.
>>
>> I tried using snapshot:
>>  cygwin-inst-20080122.tar.bz2
>> but it still fails.  (In addition, stdout appears to not get flushed in
>> that snapshot).
>>     
>
>   That's presumably a snapshot of 1.7.0, which is pretty work-in-progressy at
> the moment?
>
>   
Yes, but I thought I would pre-empt the "did you try a snapshot" question ;)
>> Is it the case that the patch to the header
>> file requires the recompilation of applications
>> and libraries that use threading to make them work?
>>
>> See these messages for context:
>>  http://cygwin.com/ml/cygwin/2007-09/msg00120.html
>>  http://cygwin.com/ml/cygwin/2006-12/msg00451.html
>>  http://cygwin.com/ml/cygwin/2006-05/msg00125.html
>>     
>
>   The two testcases I found in those threads (attached) both WJFFM under
> cygwin 1.5.25-7 but fail under 1.5.23-2.  If you can reproduce that and your
> program still fails, it's probably a different issue.
>   

Thanks for giving that a try, Dave.

I restored 1.5.25-7 and confirmed that test_wait4 succeeds standalone.
Note that the test_wait4 test fails when run with:
    python testall.py >& testall.out
Note that it does make a difference if output is redirected.
If you type:
    python testall.py
then it hangs at the point of testing threads:
    *** Changing thread stack size ***
    caught expected ValueError setting stack_size(4096)
    successfully set stack_size(262144)
    successfully set stack_size(1048576)
    successfully set stack_size(0)
    trying stack_size = 262144
    creating task 1

Note the message from the test output that "verbose mode"
can influence the results:
  CAUTION:  stdout isn't compared in verbose mode:
  a test that passes in verbose mode may fail without it.

I would be curious if you also can reproduce this behavior.


The reason that threading is implicated is that the code
just exits mysteriously when several Lock objects are created.
In this code snippet below, commenting out the third lock creation
allows it to run further (but fail later).  In fact, commenting out any
one of the three lock object initializers will allow it to go further.
On the third lock creation it just returns to the shell prompt.

        self.m_queue     = Queue.Queue()
        # State variables:
        self.m_listening = 0
        self.m_random    = 0
        self.m_guiLock   = threading.Lock()
        if self.m_debug > 0: print "Listener: thread gui lock:", 
self.m_guiLock
        self.m_startLock = threading.Lock()
        if self.m_debug > 0: print "Listener: thread start lock:", 
self.m_startLock
        # Commenting out this line allows the execution to go further:
        self.m_randLock  = threading.Lock()
       #self.m_randLock  = None
        if self.m_debug > 0: print "Listener: thread rand lock:", 
self.m_randLock

The obvious ex-vivo test of creating some Queues and Locks succeeds.
I also tried just adding some threading.Lock() creations to "foo2.py"
but that wasn't enough to cause the problem.

This is particularly hard to debug because it doesn't give error messages
or things to manipulate.  It just "goes away".

I can try some single-stepping in GDB if someone has a recipe to follow.
Suggestions?

For now, I just don't run the application on Cygwin...


--
Unsubscribe info:      http://cygwin.com/ml/#unsubscribe-simple
Problem reports:       http://cygwin.com/problems.html
Documentation:         http://cygwin.com/docs.html
FAQ:                   http://cygwin.com/faq/