[issue27889] ctypes interfers with signal handling

Change by Eryk Sun : -- resolution: -> out of date stage: -> resolved status: open -> closed ___ Python tracker ___ ___ Python-bug

[issue27889] ctypes interfers with signal handling

Andre Merzky added the comment: FWIW, a workaround seems to be a nested try/except clause: try: try: do_lots_of_work() except RuntimeError as e: print 'signal handling worked' except RuntimeError: print 'signal handling delayed' I did a stress test over 100k runs, and got no unexp

[issue27889] ctypes interfers with signal handling

Andre Merzky added the comment: I would appreciate any suggestion on how to avoid this problem -- otherwise it seems that I can't reliably use signals in threaded contexts at all :( Thanks, Andre. -- ___ Python tracker

[issue27889] ctypes interfers with signal handling

Andre Merzky added the comment: I think we are on the same page then, thanks. AFAIU, the C-level signal handler results in a flag being set, which is evaluated at some later point in time[1], after a certain number of opcodes have been executed. Could it be that those opcodes blindly contin

[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

[issue27889] ctypes interfers with signal handling

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 raise

[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

[issue27889] ctypes interfers with signal handling

Andre Merzky added the comment: Also thanks for the reply! :) Interesting that our results differ: as said, my code stumbles over it rather frequently, and I can't reproduce w/o ctypes activities. But indeed, the latter might just reinforce a race condition which is present either way...

[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 app

[issue27889] ctypes interfers with signal handling

Andre Merzky added the comment: > The repro is tied to the time.sleep call in the try block. If I do > time.sleep(1) Yes - if both sleeps, the one in the `try` block and the one in the thread's routine (`sub`) are equal, then you'll have the typical race, and you can well be in the `finally`

[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

[issue27889] ctypes interfers with signal handling

Andre Merzky added the comment: I also see the problem on 2.7.11, on MacOS, but with significantly lower frequency. I can't tell if that is due to changes in Python, the different architecture, or whatever... $ python -V Python 2.7.11 $ uname -a Darwin cameo.local 14.4.0 Darwin Kernel Versio

[issue27889] ctypes interfers with signal handling

Andre Merzky added the comment: I can confirm the same unexpected behavior for Python 2.7.6 / Linux radical 4.2.0-25-generic #30~14.04.1-Ubuntu (2nd attempt) Python 2.7.9 / Linux login1.stampede.tacc.utexas.edu 2.6.32-431.17.1.el6.x86_64 (32nd attempt) Python 2.7.10 / Linux gordon-ln2.sdsc.edu

[issue27889] ctypes interfers with signal handling

Andre Merzky added the comment: Thanks for checking! I use: $ uname -a Linux thinkie 3.11-2-amd64 #1 SMP Debian 3.11.8-1 (2013-11-13) x86_64 GNU/Linux $ python -V Python 2.7.5+ Note that the problem does not occur on every run -- but in more than 50% of the cases, for me. I am on a somewha

[issue27889] ctypes interfers with signal handling

Eryk Sun added the comment: I can't reproduce this issue in 2.7.11 on Linux. I also don't see how it could be related to ctypes. It doesn't meddle with signal handlers, and neither does Linux libuuid -- not as far I as I can tell with breakpoints set on signal() and sigaction(). Please provide

[issue27889] ctypes interfers with signal handling

New submission from Andre Merzky: Summary: A thread uses signals to the MainThread to signal an abnormal condition. The main thread is expected to get that signal, invoke the signal handler, and raise an exception. In combination with 'ctypes' calls, that does not happen. Consider the fol