GNOME Bugzilla – Bug 744638
python console blocks TERM signal ... then bus errors
Last modified: 2015-03-30 14:48:10 UTC
Recipe: Start fresh copy of gnumeric. Menu --> tools --> python console Over in the window that started gnumeric, hit ^C^C^C^C^C^C^C^C Observe that has no effect. Not good. In the python console window, type something, e.g. asdf <enter> Observe: CRITICAL **: gnm_py_interpreter_run_string: assertion 'stringio_module != NULL' failed That is immediately followed by bus error. All this is 100% reproducible chez moi. gnumeric --version gnumeric version '1.12.21' datadir := '/usr/share/gnumeric/1.12.21' libdir := '/usr/lib/gnumeric/1.12.21' uname -a Linux asclepias 3.18.0+ #2 SMP Sun Dec 21 18:25:03 MST 2014 x86_64 x86_64 x86_64 GNU/Linux
"Over in the window that started gnumeric, hit ^C^C^C^C^C^C^C^C" Which window would that be? A terminal window? THen please file the bug against the terminal window program.
Yes, that would be a terminal window. You know, the kind of window where it makes sense to type ^C. It's a bit odd that ^C behaves as expected when gnumeric is running without the python console ... but not with. It seems unlikely that filing a bug against xterm will make the gnumeric bus error go away.
We really should make the python console go away... That is a pieve of Gnumeric that does not get any tlc.
Also note that the terminal window plays no essential role in the bug(s) being reported. You can start gnumeric some other way if you like. You can send it SIGINT some other way if you like. The fact remains, it responds to the signal in a reasonable way without the python console, but not with. The original report suggested a terminal window because that is a convenient way to see the CRITICAL error and see the bus error.
We do not block SIGTERM. Or any other signal for that matter. However, I have noticed that during the build process we do various introspection tasks using tools written (by other people) in python. These tools clearly mess with Ctrl-C. Hence I believe this might be a python problem.
Created attachment 297557 [details] [review] Initial patch We might test for the signal type and only quit if it is SIGINT. Interupting with ^C and this patch results in many leaks, but I suppose it is not that important to exit properly in such a case.
Created attachment 297558 [details] [review] Initial patch Removed unraled changes from the patch, sorry for the noise.
Will that patch make up busy-wait?
some kind of, I suppose, but it is active only when the python console is opened, and I just found it is not enough, if I close the console and type Ctrl+C in the terminal, gnumeric does not terminates, we need that when the python loader is active instead.
Confirmed, just using a ptthon function such as py_bitand eats the signals.
Created attachment 297651 [details] [review] enhanced patch
May be we can use PySignal_SetWakeupFd() instead, but it will need more work (and may be another thread just to wait for any input).
Comment on attachment 297651 [details] [review] enhanced patch This is not the right thing to do, we might have several interpreters at once.
Created attachment 299096 [details] [review] Patch
Using threads just for monitoring a signal looks worse (and not so easily portable). So I'd vote for this busy-wait solution (does something only when idle).
If we're busy-waiting, can we do it with a timeout using idle priority? Say every 100ms.
we might use: g_timeout_add_full (G_PRIORITY_LOW, 100, (GSourceFunc) cb_test_signals, gnm_python_obj, NULL); That would result in a call every 100ms if and only if there is not anything else to do.
This problem has been fixed in our software repository. The fix will go into the next software release. Once that release is available, you may want to check for a software upgrade provided by your Linux distribution.