[issue27889] ctypes interfers with signal handling

Andre Merzky report at bugs.python.org
Tue Sep 6 01:29:59 EDT 2016


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` clause when the exception arises.

The problem though is different: please feel free to set the sleep in the `try` block to `sleep(100)` -- and unless the thread creation and startup takes 99 seconds, you should *not* run into that race, the problem however persists:

-------------------------------------------------------
merzky at thinkie:~ $ grep -C 2 sleep bug.py

def sub(pid):
    time.sleep(1)
    os.kill(pid, signal.SIGUSR2)

--
    t = mt.Thread(target=sub, args=[os.getpid()])
    t.start()
    time.sleep(100)
except Exception as e:
    print 'except: %s' % e

merzky at thinkie:~ $ while true; do i=$((i+1)); echo -n "$i: "; python bug.py || break; done
1: except: caught sigusr2
2: except: caught sigusr2
3: except: caught sigusr2
4: Traceback (most recent call last):
  File "bug.py", line 30, in <module>
    print 'unexcepted'
  File "bug.py", line 14, in sigusr2_handler
    raise RuntimeError('caught sigusr2')
RuntimeError: caught sigusr2
------------------------------------------------------

In this case, the begaviour does depend on `ctypes` -- or at least I have not seen that problem without `ctypes` being used.

Thanks, Andre.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue27889>
_______________________________________


More information about the Python-bugs-list mailing list