Re: Threading issue in cygwin python 2.5.1-2 ?
On Feb 13 09:35, Jim Kleckner wrote: What is the best way to proceed with this? It appears to have been a change since 1.5.18 if Jason's guess is correct. I can build a debug version of Python if that is useful. I can build a debug version of cygwin if that is useful although previous list comments suggest that it requires some deep knowledge to do/use properly. Building cygwin from CVS requires gcc, a spare build directory (don't build in the source dir), and the deep knowledge how to get rid of the optimizer flag when building. It boils down to Read http://cygwin.com/cvs.html [...] $ cvs co winsup $ mkdir ../build $ cd ../build $ ../src/configure $ make CFLAGS=-g CFLAGS_FOR_TARGET=-g Stop all Cygwin processes Replace /bin/cygwin1.dll with new-cygwin1.dll from your build dir. Copy cygwin1.dbg from the build dir to /bin. Start debugging. What would be helpful is a simple testcase in plain C which does not require an interpreter (python) to run. The less environment, the less code you need to reproduce a problem, the simpler to debug. As an off-topic side note, it sure would be nice to be able to use valgrind just once on cygwin! Easy. Just ask the valgrind guys to stop relying on non-portable Linux features. Corinna -- Corinna Vinschen Please, send mails regarding Cygwin to Cygwin Project Co-Leader cygwin AT cygwin DOT com Red Hat -- 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/
RE: Threading issue in cygwin python 2.5.1-2 ?
On 14 February 2008 09:29, Corinna Vinschen wrote: [ ... ] and the deep knowledge how to get rid of the optimizer flag when building. $ make CFLAGS=-g CFLAGS_FOR_TARGET=-g Didn't we decide that CXX_FLAGS_FOR_TARGET=-g was also necessary? cheers, DaveK -- Can't think of a witty .sigline today -- 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/
Re: Threading issue in cygwin python 2.5.1-2 ?
On Feb 14 10:25, Dave Korn wrote: On 14 February 2008 09:29, Corinna Vinschen wrote: [ ... ] and the deep knowledge how to get rid of the optimizer flag when building. $ make CFLAGS=-g CFLAGS_FOR_TARGET=-g Didn't we decide that CXX_FLAGS_FOR_TARGET=-g was also necessary? The above works for me. Corinna -- Corinna Vinschen Please, send mails regarding Cygwin to Cygwin Project Co-Leader cygwin AT cygwin DOT com Red Hat -- 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/
Re: Threading issue in cygwin python 2.5.1-2 ?
Thanks for running this. René Berber wrote: Jim Kleckner wrote: [snip] Would someone mind trying the following to see if you get the same behavior? cd /usr/lib/python2.5/test python testall.py Observe that it hangs at creating task 1. Yes. After a while of being idle threads go down from 11 to 9, but nothing else happens. And (using bash): cd /usr/lib/python2.5/test python testall.py testall.out and observe that test_wait4 fails. Yes. Testing finished, on the log I see a couple of tracebacks: test_wait (test.test_wait4.Wait4Test) ... Traceback (most recent call last): ERROR: test_wait (test.test_wait4.Wait4Test) test test_wait4 failed -- Traceback (most recent call last): I reinstalled cygwin to make sure I have 1.5.25-7. I downloaded the source for Python and rebuilt it to see if that would help. Not surprisingly, it didn't. It appears that Jason Tishler knows about these issues based on the CYGWIN-PATCHES/README file: As of Cygwin Python 2.4.3-1, the port has pthread-related issues that cause some threading features to fail (at least occassionally). AFAICT, this is due to a change in the Cygwin DLL some time after 1.5.18. See the test section for more details. [snip] Under XP Pro SP2, Cygwin 1.5.24-2, ntsec, and NTFS, Cygwin Python passes most normal (i.e., non -u option) tests. Unfortunately, some of the threading-related tests can cause the regression test to abort without any error messages. If one excludes these tests, then the regression test will run to completion. Additionally, if these tests are run individually, then they will pass. What is the best way to proceed with this? It appears to have been a change since 1.5.18 if Jason's guess is correct. I can build a debug version of Python if that is useful. I can build a debug version of cygwin if that is useful although previous list comments suggest that it requires some deep knowledge to do/use properly. Brian mentioned in cygwin-patches list single-stepping python using gdb to locate the previous pthread bug arising from inconsistent headers. How difficult is it do set that up? What are the prerequisites? As an off-topic side note, it sure would be nice to be able to use valgrind just once on cygwin! Thanks - Jim -- 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/
Re: Threading issue in cygwin python 2.5.1-2 ?
Jim Kleckner wrote: Dave Korn wrote: On 26 January 2008 02:27, Jim Kleckner wrote: ... 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. Would someone mind trying the following to see if you get the same behavior? cd /usr/lib/python2.5/test python testall.py Observe that it hangs at creating task 1. And (using bash): cd /usr/lib/python2.5/test python testall.py testall.out and observe that test_wait4 fails. ... Thanks - Jim -- 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/
Re: Threading issue in cygwin python 2.5.1-2 ?
Jim Kleckner wrote: [snip] Would someone mind trying the following to see if you get the same behavior? cd /usr/lib/python2.5/test python testall.py Observe that it hangs at creating task 1. Yes. After a while of being idle threads go down from 11 to 9, but nothing else happens. And (using bash): cd /usr/lib/python2.5/test python testall.py testall.out and observe that test_wait4 fails. Yes. Testing finished, on the log I see a couple of tracebacks: test_wait (test.test_wait4.Wait4Test) ... Traceback (most recent call last): ERROR: test_wait (test.test_wait4.Wait4Test) test test_wait4 failed -- Traceback (most recent call last): -- René Berber -- 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/
RE: Threading issue in cygwin python 2.5.1-2 ?
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? 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. cheers, DaveK -- Can't think of a witty .sigline today #!python # From http://aspn.activestate.com/ASPN/Cookbook/Python/Recipe/82965 This recipe describes how to handle asynchronous I/O in an environment where you are running Tkinter as the graphical user interface. Tkinter is safe to use as long as all the graphics commands are handled in a single thread. Since it is more efficient to make I/O channels to block and wait for something to happen rather than poll at regular intervals, we want I/O to be handled in separate threads. These can communicate in a threasafe way with the main, GUI-oriented process through one or several queues. In this solution the GUI still has to make a poll at a reasonable interval, to check if there is something in the queue that needs processing. Other solutions are possible, but they add a lot of complexity to the application. Created by Jacob Hall?n, AB Strakt, Sweden. 2001-10-17 import Tkinter import time import threading import random import Queue class GuiPart: def __init__(self, master, queue, endCommand): self.queue = queue # Set up the GUI console = Tkinter.Button(master, text='Done', command=endCommand) console.pack() # Add more GUI stuff here def processIncoming(self): Handle all the messages currently in the queue (if any). while self.queue.qsize(): try: msg = self.queue.get(0) # Check contents of message and do what it says # As a test, we simply print it print msg except Queue.Empty: pass print done processIncoming class ThreadedClient: Launch the main part of the GUI and the worker thread. periodicCall and endApplication could reside in the GUI part, but putting them here means that you have all the thread controls in a single place. def __init__(self, master): Start the GUI and the asynchronous threads. We are in the main (original) thread of the application, which will later be used by the GUI. We spawn a new thread for the worker. print __init__ self.master = master # Create the queue print Queue self.queue = Queue.Queue() # Set up the GUI part print GuiPart self.gui = GuiPart(master, self.queue, self.endApplication) # Set up the thread to do asynchronous I/O # More can be made if necessary self.running = 1 print running self.thread1 = threading.Thread(target=self.workerThread1) self.thread1.start() # Start the periodic call in the GUI to check if the queue contains # anything print peridicCall self.periodicCall() def periodicCall(self): Check every 100 ms if there is something new in the queue. print processIncoming self.gui.processIncoming() if not self.running: # This is the brutal stop of the system. You may want to do # some cleanup before actually shutting it down. print exiting import sys sys.exit(1) print self.master.after self.master.after(100, self.periodicCall) print done periodicCall def workerThread1(self): This is where we handle the asynchronous I/O. For example, it may be a 'select()'. One important thing to remember is that the thread has to yield control. print workerThread1 while self.running: # To simulate asynchronous I/O, we create a random number at # random intervals. Replace the following 2 lines with the real # thing. time.sleep(rand.random() * 0.3) msg = rand.random() self.queue.put(msg) def
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/
Re: Threading issue in cygwin python 2.5.1-2 ?
Brian Dessent wrote: Jim Kleckner wrote: Running it with idle does give the exception dialog. I can't seem to grab hold of anything to get a traceback. Suggestions? 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). 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 Thanks - Jim Note that there was a suspicious python test failure for test_wait4 with os.getpid() failing, but this may be unrelated. === /usr/lib/python2.5/test/testall.py partial output: test_wait4 Unhandled exception in thread started by bound method Wait3Test.f of test.test_wait3.Wait3Test testMethod=test_wait test_wait (test.test_wait4.Wait4Test) ... Traceback (most recent call last): File ./fork_wait.py, line 30, in f self.alive[id] = os.getpid() AttributeError: 'NoneType' object has no attribute 'getpid' Unhandled exception in thread started by bound method Wait3Test.f of test.test_wait3.Wait3Test testMethod=test_wait Traceback (most recent call last): File ./fork_wait.py, line 30, in f self.alive[id] = os.getpid() AttributeError: 'NoneType' object has no attribute 'getpid' Unhandled exception in thread started by bound method Wait3Test.f of test.test_wait3.Wait3Test testMethod=test_wait Traceback (most recent call last): File ./fork_wait.py, line 30, in f self.alive[id] = os.getpid() AttributeError: 'NoneType' object has no attribute 'getpid' Unhandled exception in thread started by bound method Wait3Test.f of test.test_wait3.Wait3Test testMethod=test_wait Traceback (most recent call last): File ./fork_wait.py, line 30, in f self.alive[id] = os.getpid() AttributeError: 'NoneType' object has no attribute 'getpid' FAIL == FAIL: test_wait (test.test_wait4.Wait4Test) -- Traceback (most recent call last): File /tmp/python.6884/usr/lib/python2.5/test/fork_wait.py, line 75, in test_wait self.wait_impl(cpid) File /tmp/python.6884/usr/lib/python2.5/test/test_wait4.py, line 29, in wait_impl self.assertEqual(status, 0, cause = %d, exit = %d % (status0xff, status8)) AssertionError: cause = 6, exit = 0 -- 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/
Re: Threading issue in cygwin python 2.5.1-2 ?
Jim Kleckner wrote: Jim Kleckner wrote: I tried running /lib/python2.5/test/test_thread.py and it hangs at the line below: *** 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 Hm. Redirecting output from test_thread.py lets it complete. python test_thread.py /tmp/t python testall.py redirected completes but hangs in same spot if not redirected. This is all using today's snapshot. Brian, you mentioned that you detected the other problem with single-stepping in GDB. Would you be able to publish the setup steps to enable me/others to find this sort of problem? It seems likely that the problem is in cygwin since the test passes with redirection and works in the stock Python25 distro. Potentially similar to the other thread issue you found? Thanks - Jim -- 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/
Re: Threading issue in cygwin python 2.5.1-2 ?
Jim Kleckner wrote: Jim Kleckner wrote: I tried running /lib/python2.5/test/test_thread.py and it hangs at the line below: *** 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 Hm. Redirecting output from test_thread.py lets it complete. python test_thread.py /tmp/t python testall.py redirected completes but hangs in same spot if not redirected. This is all using today's snapshot. And of course using strace causes it to run to completion. -- 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/
Re: Threading issue in cygwin python 2.5.1-2 ?
Jim Kleckner wrote: Jim Kleckner wrote: I tried running /lib/python2.5/test/test_thread.py and it hangs at the line below: *** 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 Hm. Redirecting output from test_thread.py lets it complete. python test_thread.py /tmp/t python testall.py redirected completes but hangs in same spot if not redirected. This is all using today's snapshot. And of course using strace causes it to run to completion even when not redirected. -- 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/
Re: Threading issue in cygwin python 2.5.1-2 ?
Jim Kleckner wrote: Jim Kleckner wrote: I get an exception running a Python example that uses threads that I downloaded from the net (ASPN): http://aspn.activestate.com/ASPN/Cookbook/Python/Recipe/82965 Would some kind soul try the example and let me know that it does/doesn't work for you? Setting debug print around the code suggests that the third Lock object created causes the exception. Thanks - Jim Not sure this is going to help ... $ /usr/bin/python Python 2.5.1 (r251:54863, Aug 30 2007, 08:07:01) [GCC 3.4.4 (cygming special, gdc 0.12, using dmd 0.125)] on cygwin Type help, copyright, credits or license for more information. Running the example on the above Python system I just see the command prompt return with no program output whatsoever: [EMAIL PROTECTED] ~/Projects/Python $ /usr/bin/python test03.py [EMAIL PROTECTED] ~/Projects/Python $ Under a standard Windows 2.5.1 it created a window then appeared to print random times until I clicked the Done button: C:\Steve\Projects\Pythonpython test0 0.303836168441 0.98021967508 0.254334126577 0.642678393476 0.782094370266 0.940786018121 0.0488669290821 0.812403721535 0.693703472455 0.723381783101 0.859300279852 0.706147636363 0.579343687831 0.336892085766 0.0564730443564 0.714308189887 0.42816364 0.912370764441 0.806818121522 0.189626500124 0.642553238166 0.217957344654 0.383676668709 0.904024479849 0.651319966186 0.65381986854 0.770733203355 0.114970365957 0.717903651883 0.716191537539 0.377106793004 0.137836788132 C:\Steve\Projects\Python regards Steve -- Steve Holden+1 571 484 6266 +1 800 494 3119 Holden Web LLC/Ltd http://www.holdenweb.com Skype: holdenweb http://del.icio.us/steve.holden --- Asciimercial -- Get on the web: Blog, lens and tag the Internet Many services currently offer free registration --- Thank You for Reading - -- 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/
Re: Threading issue in cygwin python 2.5.1-2 ?
Steve Holden wrote: Jim Kleckner wrote: Jim Kleckner wrote: I get an exception running a Python example that uses threads that I downloaded from the net (ASPN): http://aspn.activestate.com/ASPN/Cookbook/Python/Recipe/82965 Would some kind soul try the example and let me know that it does/doesn't work for you? Setting debug print around the code suggests that the third Lock object created causes the exception. Thanks - Jim Not sure this is going to help ... $ /usr/bin/python Python 2.5.1 (r251:54863, Aug 30 2007, 08:07:01) [GCC 3.4.4 (cygming special, gdc 0.12, using dmd 0.125)] on cygwin Type help, copyright, credits or license for more information. Running the example on the above Python system I just see the command prompt return with no program output whatsoever: [EMAIL PROTECTED] ~/Projects/Python $ /usr/bin/python test03.py So it fails, but doesn't bring up the exception dialog. [EMAIL PROTECTED] ~/Projects/Python $ Under a standard Windows 2.5.1 it created a window then appeared to print random times until I clicked the Done button: C:\Steve\Projects\Pythonpython test0 0.303836168441 0.98021967508 0.254334126577 ... Yep, that's what it should do. Thanks for checking. Jim -- 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/
Re: Threading issue in cygwin python 2.5.1-2 ?
Jim Kleckner wrote: Steve Holden wrote: Jim Kleckner wrote: Jim Kleckner wrote: I get an exception running a Python example that uses threads that I downloaded from the net (ASPN): http://aspn.activestate.com/ASPN/Cookbook/Python/Recipe/82965 Would some kind soul try the example and let me know that it does/doesn't work for you? Setting debug print around the code suggests that the third Lock object created causes the exception. Thanks - Jim Not sure this is going to help ... $ /usr/bin/python Python 2.5.1 (r251:54863, Aug 30 2007, 08:07:01) [GCC 3.4.4 (cygming special, gdc 0.12, using dmd 0.125)] on cygwin Type help, copyright, credits or license for more information. Running the example on the above Python system I just see the command prompt return with no program output whatsoever: [EMAIL PROTECTED] ~/Projects/Python $ /usr/bin/python test03.py So it fails, but doesn't bring up the exception dialog. That's right: nothing at all. But note I compiled this particular version myself, so I guess it's possible I didn't enable threads. [Re-installs standard 2.5.1 for Cygwin]. Strange how hotel network bandwidth always seems to drop to that of a piece of wet string when you really need performance ... oh well, at least now I know how long it take to download Python at 22.6 kb/s :-) Nope, sorry, same results after reverting to the standard install. Runs to completion with no error dialog nor output. regards Steve -- Steve Holden+1 571 484 6266 +1 800 494 3119 Holden Web LLC/Ltd http://www.holdenweb.com Skype: holdenweb http://del.icio.us/steve.holden --- Asciimercial -- Get on the web: Blog, lens and tag the Internet Many services currently offer free registration --- Thank You for Reading - -- 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/
Re: Threading issue in cygwin python 2.5.1-2 ?
On Wed, 5 Sep 2007, Steve Holden wrote: Running the example on the above Python system I just see the command prompt return with no program output whatsoever: [EMAIL PROTECTED] ~/Projects/Python $ /usr/bin/python test03.py So it fails, but doesn't bring up the exception dialog. That's right: nothing at all. But note I compiled this particular version myself, so I guess it's possible I didn't enable threads. What's the exit code? The behavior sounds suspiciously like a missing DLL case... Igor -- http://cs.nyu.edu/~pechtcha/ |\ _,,,---,,_[EMAIL PROTECTED] | [EMAIL PROTECTED] ZZZzz /,`.-'`'-. ;-;;,_Igor Peshansky, Ph.D. (name changed!) |,4- ) )-,_. ,\ ( `'-' old name: Igor Pechtchanski '---''(_/--' `-'\_) fL a.k.a JaguaR-R-R-r-r-r-.-.-. Meow! Belief can be manipulated. Only knowledge is dangerous. -- Frank Herbert -- 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/
Re: Threading issue in cygwin python 2.5.1-2 ?
Igor Peshansky wrote: On Wed, 5 Sep 2007, Steve Holden wrote: Running the example on the above Python system I just see the command prompt return with no program output whatsoever: [EMAIL PROTECTED] ~/Projects/Python $ /usr/bin/python test03.py So it fails, but doesn't bring up the exception dialog. That's right: nothing at all. But note I compiled this particular version myself, so I guess it's possible I didn't enable threads. What's the exit code? The behavior sounds suspiciously like a missing DLL case... [EMAIL PROTECTED] ~/Projects/Python $ /usr/bin/python test03.py [EMAIL PROTECTED] ~/Projects/Python $ echo $? 0 So, what does this tell us? regards Steve -- Steve Holden+1 571 484 6266 +1 800 494 3119 Holden Web LLC/Ltd http://www.holdenweb.com Skype: holdenweb http://del.icio.us/steve.holden --- Asciimercial -- Get on the web: Blog, lens and tag the Internet Many services currently offer free registration --- Thank You for Reading - -- 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/
Re: Threading issue in cygwin python 2.5.1-2 ?
Steve Holden wrote: Igor Peshansky wrote: On Wed, 5 Sep 2007, Steve Holden wrote: Running the example on the above Python system I just see the command prompt return with no program output whatsoever: [EMAIL PROTECTED] ~/Projects/Python $ /usr/bin/python test03.py So it fails, but doesn't bring up the exception dialog. That's right: nothing at all. But note I compiled this particular version myself, so I guess it's possible I didn't enable threads. What's the exit code? The behavior sounds suspiciously like a missing DLL case... [EMAIL PROTECTED] ~/Projects/Python $ /usr/bin/python test03.py [EMAIL PROTECTED] ~/Projects/Python $ echo $? 0 So, what does this tell us? Everything is just perfect! ;-) The value would be non-zero if it couldn't find a needed DLL. -- Larry Hall http://www.rfk.com RFK Partners, Inc. (508) 893-9779 - RFK Office 216 Dalton Rd. (508) 893-9889 - FAX Holliston, MA 01746 _ A: Yes. Q: Are you sure? A: Because it reverses the logical flow of conversation. Q: Why is top posting annoying in email? -- 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/
Re: Threading issue in cygwin python 2.5.1-2 ?
Larry Hall (Cygwin) wrote: Steve Holden wrote: Igor Peshansky wrote: On Wed, 5 Sep 2007, Steve Holden wrote: Running the example on the above Python system I just see the command prompt return with no program output whatsoever: [EMAIL PROTECTED] ~/Projects/Python $ /usr/bin/python test03.py So it fails, but doesn't bring up the exception dialog. That's right: nothing at all. But note I compiled this particular version myself, so I guess it's possible I didn't enable threads. What's the exit code? The behavior sounds suspiciously like a missing DLL case... [EMAIL PROTECTED] ~/Projects/Python $ /usr/bin/python test03.py [EMAIL PROTECTED] ~/Projects/Python $ echo $? 0 So, what does this tell us? Everything is just perfect! ;-) The value would be non-zero if it couldn't find a needed DLL. I also get 0 exit code even though there is a dialog box with the application error codes mentioned before. [EMAIL PROTECTED] ~]$ python aspn-threading-tkinter.py [EMAIL PROTECTED] ~]$ echo $? 0 [EMAIL PROTECTED] ~]$ -- 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/
Re: Threading issue in cygwin python 2.5.1-2 ?
Jim Kleckner wrote:
Larry Hall (Cygwin) wrote:
Steve Holden wrote:
Igor Peshansky wrote:
On Wed, 5 Sep 2007, Steve Holden wrote:
Running the example on the above Python system I just see the
command
prompt return with no program output whatsoever:
[EMAIL PROTECTED] ~/Projects/Python
$ /usr/bin/python test03.py
So it fails, but doesn't bring up the exception dialog.
That's right: nothing at all. But note I compiled this particular
version
myself, so I guess it's possible I didn't enable threads.
What's the exit code? The behavior sounds suspiciously like a
missing DLL
case...
[EMAIL PROTECTED] ~/Projects/Python
$ /usr/bin/python test03.py
[EMAIL PROTECTED] ~/Projects/Python
$ echo $?
0
So, what does this tell us?
Everything is just perfect! ;-)
The value would be non-zero if it couldn't find a needed DLL.
I also get 0 exit code even though there is a dialog box with the
application error codes mentioned before.
[EMAIL PROTECTED] ~]$ python aspn-threading-tkinter.py
[EMAIL PROTECTED] ~]$ echo $?
0
[EMAIL PROTECTED] ~]$
Ok, so I downloaded the python source and built a debug version
with:
export EXTRA_CFLAGS=-DPy_DEBUG -DPy_REF_DEBUG -DPy_TRACE_REFS
-DPYMALLOC_DEBUG -DCOUNT_ALLOCS
./configure --with-pydebug --prefix=$Prefix --mandir='${prefix}/share/man'
Now I run the example and similar to Steve it just exits with no dialog box.
With some extra print statements, it seems to disappear at the line:
self.master.after(100, self.periodicCall)
Running this under gdb gives:
(gdb) run aspn-threading-tkinter.py
Starting program: /usr/bin/python.exe aspn-threading-tkinter.py
Loaded symbols for /cygdrive/c/WINDOWS/system32/ntdll.dll
Loaded symbols for /cygdrive/c/WINDOWS/system32/kernel32.dll
Loaded symbols for /usr/bin/cygwin1.dll
Loaded symbols for /cygdrive/c/WINDOWS/system32/advapi32.dll
Loaded symbols for /cygdrive/c/WINDOWS/system32/rpcrt4.dll
Loaded symbols for /usr/bin/libpython2.5.dll
Program exited with code 0305.
(gdb)
Running it with idle does give the exception dialog.
I can't seem to grab hold of anything to get a traceback.
Suggestions?
# From http://aspn.activestate.com/ASPN/Cookbook/Python/Recipe/82965
This recipe describes how to handle asynchronous I/O in an environment where
you are running Tkinter as the graphical user interface. Tkinter is safe
to use as long as all the graphics commands are handled in a single thread.
Since it is more efficient to make I/O channels to block and wait for something
to happen rather than poll at regular intervals, we want I/O to be handled
in separate threads. These can communicate in a threasafe way with the main,
GUI-oriented process through one or several queues. In this solution the GUI
still has to make a poll at a reasonable interval, to check if there is
something in the queue that needs processing. Other solutions are possible,
but they add a lot of complexity to the application.
Created by Jacob Hall?n, AB Strakt, Sweden. 2001-10-17
import Tkinter
import time
import threading
import random
import Queue
class GuiPart:
def __init__(self, master, queue, endCommand):
self.queue = queue
# Set up the GUI
console = Tkinter.Button(master, text='Done', command=endCommand)
console.pack()
# Add more GUI stuff here
def processIncoming(self):
Handle all the messages currently in the queue (if any).
while self.queue.qsize():
try:
msg = self.queue.get(0)
# Check contents of message and do what it says
# As a test, we simply print it
print msg
except Queue.Empty:
pass
print done processIncoming
class ThreadedClient:
Launch the main part of the GUI and the worker thread. periodicCall and
endApplication could reside in the GUI part, but putting them here
means that you have all the thread controls in a single place.
def __init__(self, master):
Start the GUI and the asynchronous threads. We are in the main
(original) thread of the application, which will later be used by
the GUI. We spawn a new thread for the worker.
print __init__
self.master = master
# Create the queue
print Queue
self.queue = Queue.Queue()
# Set up the GUI part
print GuiPart
self.gui = GuiPart(master, self.queue, self.endApplication)
# Set up the thread to do asynchronous I/O
# More can be made if necessary
self.running = 1
print running
self.thread1 = threading.Thread(target=self.workerThread1)
self.thread1.start()
# Start the periodic call in the GUI to check if the queue contains
# anything
print peridicCall
self.periodicCall()
def periodicCall(self):
Check every 100 ms if there is something new in the queue.
Re: Threading issue in cygwin python 2.5.1-2 ?
Jim Kleckner wrote: Running it with idle does give the exception dialog. I can't seem to grab hold of anything to get a traceback. Suggestions? Thanks for providing a testcase. Should be fixed in CVS: http://www.cygwin.com/ml/cygwin-patches/2007-q3/msg00013.html Brian -- 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/
Re: Threading issue in cygwin python 2.5.1-2 ?
On Thu, Sep 06, 2007 at 12:01:25PM -0700, Brian Dessent wrote: Jim Kleckner wrote: Running it with idle does give the exception dialog. I can't seem to grab hold of anything to get a traceback. Suggestions? Thanks for providing a testcase. Should be fixed in CVS: http://www.cygwin.com/ml/cygwin-patches/2007-q3/msg00013.html I'm generating a snapshot now, too. Thanks very much for tracking this down Brian. This is how free software is supposed to work! cgf -- 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/
Re: Threading issue in cygwin python 2.5.1-2 ?
Christopher Faylor wrote: On Thu, Sep 06, 2007 at 12:01:25PM -0700, Brian Dessent wrote: Jim Kleckner wrote: Running it with idle does give the exception dialog. I can't seem to grab hold of anything to get a traceback. Suggestions? Thanks for providing a testcase. Should be fixed in CVS: http://www.cygwin.com/ml/cygwin-patches/2007-q3/msg00013.html I'm generating a snapshot now, too. Thanks very much for tracking this down Brian. This is how free software is supposed to work! Yes, thanks! I can confirm that the snapshot makes the test case run on my machine. Jim -- 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/
Re: Threading issue in cygwin python 2.5.1-2 ?
Brian Dessent wrote: Jim Kleckner wrote: Running it with idle does give the exception dialog. I can't seem to grab hold of anything to get a traceback. Suggestions? Thanks for providing a testcase. Should be fixed in CVS: http://www.cygwin.com/ml/cygwin-patches/2007-q3/msg00013.html Before I further debug my other code that stopped working, is it possible that more than just cygwin1.dll is affected by this include file inconsistency and need to be recompiled? In order to track down why it doesn't work, it might be useful to have that patch in a 1.5.24-based dll snapshot to isolate whether the remaining issues are introduced post 1.5.24 or not. I suspect that isn't too convenient though. -- 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/
Re: Threading issue in cygwin python 2.5.1-2 ?
Jim Kleckner wrote: Brian Dessent wrote: Jim Kleckner wrote: Running it with idle does give the exception dialog. I can't seem to grab hold of anything to get a traceback. Suggestions? Thanks for providing a testcase. Should be fixed in CVS: http://www.cygwin.com/ml/cygwin-patches/2007-q3/msg00013.html Before I further debug my other code that stopped working, is it possible that more than just cygwin1.dll is affected by this include file inconsistency and need to be recompiled? In order to track down why it doesn't work, it might be useful to have that patch in a 1.5.24-based dll snapshot to isolate whether the remaining issues are introduced post 1.5.24 or not. I suspect that isn't too convenient though. I tried the running /lib/python2.5/test/test_thread.py and it hangs at the line below: *** 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 -- 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/
Re: Threading issue in cygwin python 2.5.1-2 ?
Jim Kleckner wrote: I tried running /lib/python2.5/test/test_thread.py and it hangs at the line below: *** 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 Hm. Redirecting output from test_thread.py lets it complete. python test_thread.py /tmp/t python testall.py redirected completes but hangs in same spot if not redirected. This is all using today's snapshot. -- 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/
Re: Threading issue in cygwin python 2.5.1-2 ?
On Thu, Sep 06, 2007 at 02:51:52PM -0700, Jim Kleckner wrote: Brian Dessent wrote: Jim Kleckner wrote: Running it with idle does give the exception dialog. I can't seem to grab hold of anything to get a traceback. Suggestions? Thanks for providing a testcase. Should be fixed in CVS: http://www.cygwin.com/ml/cygwin-patches/2007-q3/msg00013.html Before I further debug my other code that stopped working, is it possible that more than just cygwin1.dll is affected by this include file inconsistency and need to be recompiled? In order to track down why it doesn't work, it might be useful to have that patch in a 1.5.24-based dll snapshot to isolate whether the remaining issues are introduced post 1.5.24 or not. I suspect that isn't too convenient though. We don't provide snapshots based on the 1.5.x branch. cgf -- 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/
Re: Threading issue in cygwin python 2.5.1-2 ?
Jim Kleckner wrote: I get an exception running a Python example that uses threads that I downloaded from the net (ASPN): http://aspn.activestate.com/ASPN/Cookbook/Python/Recipe/82965 Would some kind soul try the example and let me know that it does/doesn't work for you? Setting debug print around the code suggests that the third Lock object created causes the exception. Thanks - Jim -- 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/
Threading issue in cygwin python 2.5.1-2 ?
I get an exception running a Python example that uses threads that I downloaded from the net (ASPN): http://aspn.activestate.com/ASPN/Cookbook/Python/Recipe/82965 This may just be another case of threading doesn't work well. I'm including the test case. It fails with cygwin Python with a dialog that says: The instruction as 0x01 referenced memory at 0x. The memory could not be written. gdb doesn't seem to give any enlightenment. Would someone mind giving this example a try and, if it works for you on a current cygwin, post back to the list? If so, I'll include cygcheck output. This is the version that is failing: Cygwin current Python: Python 2.5.1 (r251:54863, May 18 2007, 16:56:43) [GCC 3.4.4 (cygming special, gdc 0.12, using dmd 0.125)] on cygwin Here are configurations that aspn.py does work: Stock 2.4 Windows Python: Python 2.4.2 (#67, Sep 28 2005, 12:41:11) [MSC v.1310 32 bit (Intel)] on win32 Stock 2.5 Windows Python: Microsoft Windows XP [Version 5.1.2600] Python 2.5.1 (r251:54863, Apr 18 2007, 08:51:08) [MSC v.1310 32 bit (Intel)] on win32 Ubuntu Dapper: Python 2.4.3 (#2, Oct 6 2006, 07:52:30) [GCC 4.0.3 (Ubuntu 4.0.3-1ubuntu5)] on linux2 Ubuntu Edgy: Python 2.4.4c1 (#2, Oct 11 2006, 21:51:02) [GCC 4.1.2 20060928 (prerelease) (Ubuntu 4.1.1-13ubuntu5)] on linux2 # From http://aspn.activestate.com/ASPN/Cookbook/Python/Recipe/82965 This recipe describes how to handle asynchronous I/O in an environment where you are running Tkinter as the graphical user interface. Tkinter is safe to use as long as all the graphics commands are handled in a single thread. Since it is more efficient to make I/O channels to block and wait for something to happen rather than poll at regular intervals, we want I/O to be handled in separate threads. These can communicate in a threasafe way with the main, GUI-oriented process through one or several queues. In this solution the GUI still has to make a poll at a reasonable interval, to check if there is something in the queue that needs processing. Other solutions are possible, but they add a lot of complexity to the application. Created by Jacob Hall?n, AB Strakt, Sweden. 2001-10-17 import Tkinter import time import threading import random import Queue class GuiPart: def __init__(self, master, queue, endCommand): self.queue = queue # Set up the GUI console = Tkinter.Button(master, text='Done', command=endCommand) console.pack() # Add more GUI stuff here def processIncoming(self): Handle all the messages currently in the queue (if any). while self.queue.qsize(): try: msg = self.queue.get(0) # Check contents of message and do what it says # As a test, we simply print it print msg except Queue.Empty: pass class ThreadedClient: Launch the main part of the GUI and the worker thread. periodicCall and endApplication could reside in the GUI part, but putting them here means that you have all the thread controls in a single place. def __init__(self, master): Start the GUI and the asynchronous threads. We are in the main (original) thread of the application, which will later be used by the GUI. We spawn a new thread for the worker. self.master = master # Create the queue self.queue = Queue.Queue() # Set up the GUI part self.gui = GuiPart(master, self.queue, self.endApplication) # Set up the thread to do asynchronous I/O # More can be made if necessary self.running = 1 self.thread1 = threading.Thread(target=self.workerThread1) self.thread1.start() # Start the periodic call in the GUI to check if the queue contains # anything self.periodicCall() def periodicCall(self): Check every 100 ms if there is something new in the queue. self.gui.processIncoming() if not self.running: # This is the brutal stop of the system. You may want to do # some cleanup before actually shutting it down. import sys sys.exit(1) self.master.after(100, self.periodicCall) def workerThread1(self): This is where we handle the asynchronous I/O. For example, it may be a 'select()'. One important thing to remember is that the thread has to yield control. while self.running: # To simulate asynchronous I/O, we create a random number at # random intervals. Replace the following 2 lines with the real # thing. time.sleep(rand.random() * 0.3) msg = rand.random() self.queue.put(msg) def endApplication(self): self.running = 0 rand = random.Random() root =
