I need to trap the SIGINT (^C) signal in an application I am
writing, but I get an error that says:
Traceback (most recent call last):
File "xxxx", line 330, in ?
signal.signal(signal.SIGINT, self.SigIntHandler)
SystemError: error return without exception set
A search of the web indicates that this was a bug fixed in
2.4.2.4, but we are using 2.4.1.2 and are stuck with it.
Assuming I am correct that this is a bug that has been fixed
since 2.4.1.2, is there any work-around that would allow us
to trap the SIGINT signal short of upgrading to a newer
version?
I need to trap the SIGINT (^C) signal in an application I am
writing, but I get an error that says:
Traceback (most recent call last):
File "xxxx", line 330, in ?
signal.signal(signal.SIGINT, self.SigIntHandler)
SystemError: error return without exception set
This error is because wx.App is doing this:
signal.signal(signal.SIGINT, signal.SIG_DFL)
and so when you set the new signal and it tries to return the current
value it returns NULL (SIG_DFL) so Python thinks that an exception
occurred but there wasn't one set.
A search of the web indicates that this was a bug fixed in
2.4.2.4, but we are using 2.4.1.2 and are stuck with it.
It still makes the above signal call. IIRC, the bug that was fixed
was dealing with the SystemError when some other Python code has already
cleared SIGINT.
Assuming I am correct that this is a bug that has been fixed
since 2.4.1.2, is there any work-around that would allow us
to trap the SIGINT signal short of upgrading to a newer
version?
In your class derived from wx.App add a __init__ that does everything
that wx.App.__init__ does except for the signal call. I'll add a flag
to future versions that can make that signal call optional.
···
--
Robin Dunn
Software Craftsman http://wxPython.org Java give you jitters? Relax with wxPython!
Hmm, nice theory but I just browsed through the source code
and there is no call to signal.signal. I couldn't even find
a single package that imports the 'signal' package in fact.
--David
···
On Fri, Apr 30, 2004 at 06:16:41PM -0700, Robin Dunn wrote:
David Morris wrote:
>
>Assuming I am correct that this is a bug that has been fixed
>since 2.4.1.2, is there any work-around that would allow us
>to trap the SIGINT signal short of upgrading to a newer
>version?
In your class derived from wx.App add a __init__ that does everything
that wx.App.__init__ does except for the signal call. I'll add a flag
to future versions that can make that signal call optional.
Assuming I am correct that this is a bug that has been fixed
since 2.4.1.2, is there any work-around that would allow us
to trap the SIGINT signal short of upgrading to a newer
version?
In your class derived from wx.App add a __init__ that does everything
that wx.App.__init__ does except for the signal call. I'll add a flag
to future versions that can make that signal call optional.
Hmm, nice theory but I just browsed through the source code
and there is no call to signal.signal. I couldn't even find
a single package that imports the 'signal' package in fact.
Sorry, I must have mis-remembered, I thought that the signal code was added earlier than 2.4.2.4. This is what was added to wxApp.__init__:
# Set the default handler for SIGINT. This fixes a problem
# where if Ctrl-C is pressed in the console that started this
# app then it will not appear to do anything, (not even send
# KeyboardInterrupt???) but will later segfault on exit. By
# setting the default handler then the app will exit, as
# expected (depending on platform.)
try:
import signal
signal.signal(signal.SIGINT, signal.SIG_DFL)
except:
pass
But it still may not help you catch SIGINT yourself because of what is mentioned in the comment above. I think there is something going on with the signal at the toolkit level (the issue mentioned above was on wxGTK) that is not playing nice with Python's signal module.
···
On Fri, Apr 30, 2004 at 06:16:41PM -0700, Robin Dunn wrote:
--
Robin Dunn
Software Craftsman http://wxPython.org Java give you jitters? Relax with wxPython!