[issue27889] ctypes interfers with signal handling
George Slavin added the comment: I can reproduce this issue with Python 2.7.12 and Python 3.5.2 on a Arch linux VM using the python script provided, but I think this is an error in the code. The repro is tied to the time.sleep call in the try block. If I do time.sleep(1), I can reproduce the issue almost every time (with or without ctypes). When the time.sleep() call is too short, you reach the finally block before the main thread receives the signal. Because you're in the finally block, the exception isn't caught. -- nosy: +gslavin ___ Python tracker <http://bugs.python.org/issue27889> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue27889] ctypes interfers with signal handling
George Slavin added the comment: Thanks for the reply! I've managed to reproduce the issue without using ctypes, so we can exclude ctypes as the cause of the problem :) The bug only occurs for me after hundreds of iterations of the script, so it is very intermittent. >From my results, it appears the signal handler is called, but the exception >isn't caught in the try block (this matches your result). >From the call stack it appears the exception handler is called at "print 'unexcepted'", which is after the try block. Interestingly, if I place a print after time.sleep, I cannot repro this issue. Maybe there is a race between the signal handler execution and execution of the try block in the main thread? Adding the print might slow down the main thread enough that the race disappears. I don't know the source that well, so I'll need to do some digging to get any more information. I hope this helps! -George Slavin -- ___ Python tracker <http://bugs.python.org/issue27889> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue27889] ctypes interfers with signal handling
George Slavin added the comment:
In case anyone else sees this thread, here's my trimmed down script to repro
the issue:
#!/usr/bin/env python2
import threading as mt
import signal
import time
import os
def sigusr2_handler(signum, frame):
raise RuntimeError('caught sigusr2')
signal.signal(signal.SIGUSR2, sigusr2_handler)
def sub(pid):
time.sleep(1)
os.kill(pid, signal.SIGUSR2)
try:
t = mt.Thread(target=sub, args=[os.getpid()])
t.start()
time.sleep(500)
except Exception as e:
print('except: %s' % e)
else:
print('unexcepted')
finally:
t.join()
When I run the above, I get the repro after hundreds of iterations. From these
results, it appears there is no guarentee that the signal handler will run
before the main thread continues execution at the time.sleep(500) line. This
would explain why we advance to the else clause before the exception is raised.
--
___
Python tracker
<http://bugs.python.org/issue27889>
___
___
Python-bugs-list mailing list
Unsubscribe:
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue27889] ctypes interfers with signal handling
George Slavin added the comment: The docs say the sleep call will end if a signal is caught, so once the main thread wakes, it won't go back to sleep. On Sep 6, 2016 12:35 AM, "Andre Merzky" wrote: > > Andre Merzky added the comment: > > Hi George, > > > From these results, it appears there is no guarentee that the signal > handler will run before the main thread continues execution at the > time.sleep(500) line. This would explain why we advance to the else clause > before the exception is raised. > > To me it looks like the problem pops up *way* before the `sleep(100)` (or > whatever) finishes, in fact it looks consistently like the sleep is indeed > interrupted after one second. I would it thus interpret differently, as > the code should not be able to advance to the `else` clause at that time. > > Is that different for you? > > -- > > ___ > Python tracker > <http://bugs.python.org/issue27889> > ___ > -- ___ Python tracker <http://bugs.python.org/issue27889> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue26351] Occasionally check for Ctrl-C in long-running operations like sum
George Slavin added the comment: I have a patch that checks for KeyboardInterrupt during builtin operations. This allows sum, max, min, list, dict, set, and tuple calls to be interrupted when they are working on infinite iterators. I've attached the patch, and a test I wrote to show that you can ctrl-c out of all the above calls. This is my first attempt at a patch, so I would appreciate any feedback on what I need to fix to allow it to be submitted :) -- keywords: +patch nosy: +gslavin Added file: http://bugs.python.org/file44746/KeyboardInterrupt.patch ___ Python tracker <http://bugs.python.org/issue26351> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue26351] Occasionally check for Ctrl-C in long-running operations like sum
George Slavin added the comment: I've attached the test for this patch (I couldn't figure out how to upload two files with one comment). -- Added file: http://bugs.python.org/file44747/test_sig_int_builtins.py ___ Python tracker <http://bugs.python.org/issue26351> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
