X-Recipient: archive-cygwin AT delorie DOT com
X-Spam-Check-By: sourceware.org
Message-ID: <479CEC96.1090607@kleckner.net>
Date: Sun, 27 Jan 2008 12:41:58 -0800
From: Jim Kleckner <jek-cygwin2 AT kleckner DOT net>
Reply-To: cygwin AT cygwin DOT com
User-Agent: Thunderbird 2.0.0.9 (Windows/20071031)
MIME-Version: 1.0
To: cygwin AT cygwin DOT com
Subject: Re: Threading issue in cygwin python 2.5.1-2 ?
References: <46D8A577 DOT 1060908 AT kleckner DOT net> <46DF52B8 DOT 7000509 AT kleckner DOT net>  <fbo5p9$34n$1 AT sea DOT gmane DOT org> <46DF9CAD DOT 6000503 AT kleckner DOT net>  <fbo7el$72j$1 AT sea DOT gmane DOT org> <Pine DOT GSO DOT 4 DOT 63 DOT 0709060944150 DOT 20529 AT access1 DOT cims DOT nyu DOT edu> <fbp2po$5mb$1 AT sea DOT gmane DOT org> <46E01E3C DOT 7000506 AT cygwin DOT com> <46E02134 DOT 3030400 AT kleckner DOT net> <46E03EFD DOT 3040806 AT kleckner DOT net> <46E04E85 DOT 59E9E910 AT dessent DOT net> <479A9A8F DOT 9090106 AT kleckner DOT net> <009001c860e9$dd4a0000$2e08a8c0 AT CAM DOT ARTIMI DOT COM>
In-Reply-To: <009001c860e9$dd4a0000$2e08a8c0@CAM.ARTIMI.COM>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
X-IsSubscribed: yes
Mailing-List: contact cygwin-help AT cygwin DOT com; run by ezmlm
List-Id: <cygwin.cygwin.com>
List-Subscribe: <mailto:cygwin-subscribe AT cygwin DOT com>
List-Archive: <http://sourceware.org/ml/cygwin/>
List-Post: <mailto:cygwin AT cygwin DOT com>
List-Help: <mailto:cygwin-help AT cygwin DOT com>, <http://sourceware.org/ml/#faqs>
Sender: cygwin-owner AT cygwin DOT com
Mail-Followup-To: cygwin AT cygwin DOT com
Delivered-To: mailing list cygwin AT cygwin DOT com

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/