Message154758
During Py_Finalize (pythonrun.c), it does the following:
1) suppress signal handling PyOs_FiniInterupts
2) clear caches
3) force gc collection; first for objects, then via wiping modules.
The problem is that for unix OSs, Modules/signal.c's PyOs_FiniInterrupts leaves itself in a state where its internal Handlers are effectively reset to NULL, except the various functions don't properly handle that scenario.
Attached is a test case demonstrating it; it segfaults on every python version I've tested (2.4->3.2; haven't tried 3.3).
Since this *only* occurs during the final gc sweep when modules are destroyed, its a bit of a pain in the ass to detect that we're in that scenario, and that we must not touch signal.getsignal lest it segfault the interp. That said,
def _SignalModuleUsable():
try:
signal.signal(signal.SIGUSR1, signal.signal(signal.SIGUSR1, some_handler))
return True
except (TypeError, AttributeError, SystemError):
# we were invoked in a module cleanup context.
return False
does manage to poke the api just right so that it can be detected w/out segfaulting the interp.
Finally, note that while folks could point at __del__... its not really at fault. Doing a proper weakref.ref finalizer can trigger the same- the fault is signal.c's PyOs_FiniInterrupts leaving the signal module in a bad state. For the testcase, I used __del__ just because it was quicker/less code to do so. |
|
Date |
User |
Action |
Args |
2012-03-02 10:41:33 | ferringb | set | recipients:
+ ferringb |
2012-03-02 10:41:33 | ferringb | set | messageid: <1330684893.81.0.620988158976.issue14173@psf.upfronthosting.co.za> |
2012-03-02 10:41:33 | ferringb | link | issue14173 messages |
2012-03-02 10:41:32 | ferringb | create | |
|