This is the mail archive of the cygwin mailing list for the Cygwin project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: Threading issue in cygwin python 2.5.1-2 ?


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/


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]