| msg27511 - (view) |
Author: Yang Zhang (yangzhang) |
Date: 2006-02-14 06:07 |
| Hi all, After many hours, I think I've found a bug in the logging module! If you add a (stdout) StreamHandler to a logger, then detach the terminal for that stdout, subsequent calls to log() will hang the calling thread. To reproduce this, write the following scripts (this was a small test case I came up with - maybe there's something simpler): $ cat tryhup.bash #!/usr/bin/env bash scp hup.* localhost: ssh localhost './hup.bash ; while true ; do sleep 1 ; done' $ cat hup.bash #!/usr/bin/env bash ./hup.py & $ cat hup.py #!/usr/bin/env python import time import logging f = file( '/tmp/hup.out', 'w' ) try: logging.basicConfig( filename = '/tmp/lup.out', filemode = 'w' ) # XXX PROBLEM LINE BELOW logging.getLogger('').addHandler( logging. StreamHandler() ) while True: f.write( '-------\n' ) f.flush() logging.critical( '======' ) time.sleep(1) finally: f.close() Run ./tryhup.bash. It will sit in an idle spin. Monitor the files /tmp/hup.out and /tmp/lup.out. Hit Ctrl-C on tryhup to kill it. The python process is still running, but is stalled (the .out files are no longer changing). If you remove the above labeled line, however, this doesn't happen. Can anybody please acknowledge this bug? Any temporary workarounds to this problem? Thanks in advance for looking into this and for hearing me in! |
|
|
| msg27512 - (view) |
Author: Vinay Sajip (vinay.sajip) *  |
Date: 2006-02-17 01:04 |
| Logged In: YES user_id=308438 Please provide more information about your OS - I ran these scripts on Ubuntu 5.10 and did not see the problems you mention. The script continues to run (printing dashes to the console), and hup.out/lup.out are also updated continuously. Also, note that the logging module merely opens the stream passed to the StreamHander for output, so check if in your configuration you get a hang just doing a write to sys.stderr. |
|
|
| msg27513 - (view) |
Author: Yang Zhang (yangzhang) |
Date: 2006-02-17 07:16 |
| Logged In: YES user_id=1207658 Hi, yes, after I submitted this bug I actually looked into logging.StreamHandler, and found that its code was not too complicated (as with everything Python :). I tried some more experiments, and found that the problem is in stderr, which throws an exception. The problem was that I couldn't see the exception (and didn't suspect that's what was happening), so the fact that the next line never came out led me to believe that the thread froze. Is stderr supposed to raise an exception like this? Is this a bug? Unfortunately, it's hard for me to tell what's going on (what the exception is that's being thrown). How do I tell what it's raising? (stderr is no longer avail. after all) I don't know how to catch an exception of any type and (say) print its str or repr value to a file so that I can tell what's going on. |
|
|
| msg27514 - (view) |
Author: Yang Zhang (yangzhang) |
Date: 2006-02-17 07:17 |
| Logged In: YES user_id=1207658 Hi, yes, after I submitted this bug I actually looked into logging.StreamHandler, and found that its code was not too complicated (as with everything Python :). I tried some more experiments, and found that the problem is in stderr, which throws an exception. The problem was that I couldn't see the exception (and didn't suspect that's what was happening), so the fact that the next line never came out led me to believe that the thread froze. Is stderr supposed to raise an exception like this? Is this a bug? Unfortunately, it's hard for me to tell what's going on (what the exception is that's being thrown). How do I tell what it's raising? (stderr is no longer avail. after all) I don't know how to catch an exception of any type and (say) print its str or repr value to a file so that I can tell what's going on. |
|
|
| msg27515 - (view) |
Author: Vinay Sajip (vinay.sajip) * |
Date: 2006-02-19 21:34 |
| Logged In: YES user_id=308438 I can't tell from the info you've given what the problem might be (e.g. state of redirections), but as it doesn't appear to be a logging bug, I'm closing this. By default, raiseExceptions is set to 1 in the logging package, so a handler's handleError should be called when an exception is raised in a handler. You catch an exception with a try/except clause, like so: try: # code which raises some exception except Exception, e: open('/tmp/exc.txt', 'w').write(str(e)) |
|
|