Hi All,
Geany currently uses SIGQUIT to terminate a running program (using the execute menu item or toolbar button when it shows the stop icon). This has always been the case since the stop button was added.
There is a big comment in the code explaining why SIGQUIT is used, and its problems:
/* Unix: SIGQUIT is not the best signal to use because it causes a core dump (this should not * perforce necessary for just killing a process). But we must use a signal which we can * ignore because the main process get it too, it is declared to ignore in main.c. */
Another problem reported (https://sourceforge.net/tracker/?func=detail&atid=787791&aid=3607564...) and confirmed by Matthew is that it doesn't work!
For xfce4-terminal and gnome-terminal at least, xterm is ok!
My understanding of Unix/Linux signals is that the comment above is wrong and always has been wrong, a signal sent to a child process by a parent process does not get delivered to the parent.
I don't know if anybodys memory is good enough to remember why the comment was thought to be correct (it was 2006 when it was committed).
For me simply using SIGTERM instead of SIGQUIT works fine, but does anybody have any more insight, since we don't want to have Geany stop unexpectedly when a user stops their running program.
Otherwise I'll change it in a few days.
Cheers Lex
On 11/03/2013 10:18, Lex Trotman wrote:
Hi All, [...] My understanding of Unix/Linux signals is that the comment above is wrong and always has been wrong, a signal sent to a child process by a parent process does not get delivered to the parent.
I don't know if anybodys memory is good enough to remember why the comment was thought to be correct (it was 2006 when it was committed).
Perhaps it was a misunderstanding -- signals sent to the parent will hit the child process, but not the other way around. (If it did, kill %1 in your shell would kill your shell as well.)
For me simply using SIGTERM instead of SIGQUIT works fine, but does anybody have any more insight, since we don't want to have Geany stop unexpectedly when a user stops their running program.
How about SIGINT, and failing which, notifying the user that the program refuses to stop, and allowing for SIGTERM or SIGKILL?
On 11 March 2013 14:58, Chow Loong Jin hyperair@gmail.com wrote:
On 11/03/2013 10:18, Lex Trotman wrote:
Hi All, [...] My understanding of Unix/Linux signals is that the comment above is wrong and always has been wrong, a signal sent to a child process by a parent process does not get delivered to the parent.
I don't know if anybodys memory is good enough to remember why the comment was thought to be correct (it was 2006 when it was committed).
Perhaps it was a misunderstanding -- signals sent to the parent will hit the child process, but not the other way around. (If it did, kill %1 in your shell would kill your shell as well.)
For me simply using SIGTERM instead of SIGQUIT works fine, but does anybody have any more insight, since we don't want to have Geany stop unexpectedly when a user stops their running program.
How about SIGINT, and failing which, notifying the user that the program refuses to stop, and allowing for SIGTERM or SIGKILL?
Well, sigterm is the canonical terminate signal (it is called SIG**TERM** after all :).
Some programs catch SIGTERM so they can terminate nicely like closing files properly, so its a good idea to use it.
One day someone will re-write Geany's terminate handler to be legal and Geany will do the same :)
Cheers Lex
-- Kind regards, Loong Jin
Devel mailing list Devel@lists.geany.org https://lists.geany.org/cgi-bin/mailman/listinfo/devel
On 11/03/13 05:17, Lex Trotman wrote:
On 11 March 2013 14:58, Chow Loong Jin hyperair@gmail.com wrote:
On 11/03/2013 10:18, Lex Trotman wrote:
Hi All, [...] My understanding of Unix/Linux signals is that the comment above is wrong and always has been wrong, a signal sent to a child process by a parent process does not get delivered to the parent.
I don't know if anybodys memory is good enough to remember why the comment was thought to be correct (it was 2006 when it was committed).
Perhaps it was a misunderstanding -- signals sent to the parent will hit the child process, but not the other way around. (If it did, kill %1 in your shell
Without having checked the whole history, I'm pretty much sure I wrote the comment and so also chose SIGQUIT. I vaguely remember some issues with the signals sent to the child processes and then Geany suddenly quit because it also received the signal or at least it seemed so to me. Well, it was back in 2006. It might also be that the behaviour I experienced was caused by another bug and I misinterpreted it and wrongly related it to the sent signal. As long as SIGTERM reliably works, I'd be fine with. I'd say now is a good time to check it in since 1.23 is just out and now master is allowed to new cool stuff again :).
One day someone will re-write Geany's terminate handler to be legal and Geany will do the same :)
Ah nice, you do volunteer for that task!
:)
Regards, Enrico
On Mon, 11 Mar 2013 13:18:10 +1100 Lex Trotman elextr@gmail.com wrote:
Geany currently uses SIGQUIT to terminate a running program (using the execute menu item or toolbar button when it shows the stop icon). This has always been the case since the stop button was added.
There is a big comment in the code explaining why SIGQUIT is used, and its problems:
/* Unix: SIGQUIT is not the best signal to use because it causes a core dump (this should not * perforce necessary for just killing a process). But we must use a signal which we can * ignore because the main process get it too, it is declared to ignore in main.c. */
...
My understanding of Unix/Linux signals is that the comment above is wrong and always has been wrong, a signal sent to a child process by a parent process does not get delivered to the parent.
When you execute a gdb -exec-interrupt command in debugger or Scope, a SIGINT is sent to the inferior, and to gdb, and to Geany. But if you start gdb from a terminal, the signal is sent to inferior only.
debugger moves gdb/inferior to a new process group, which sometimes fails. Scope disables SIGINT in Geany while debugging.
glib spawn is much more complex than a normal fork/exec...
On 13 March 2013 04:47, Dimitar Zhekov dimitar.zhekov@gmail.com wrote:
On Mon, 11 Mar 2013 13:18:10 +1100 Lex Trotman elextr@gmail.com wrote:
Geany currently uses SIGQUIT to terminate a running program (using the execute menu item or toolbar button when it shows the stop icon). This has always been the case since the stop button was added.
There is a big comment in the code explaining why SIGQUIT is used, and its problems:
/* Unix: SIGQUIT is not the best signal to use because it causes acore dump (this should not * perforce necessary for just killing a process). But we must use a signal which we can * ignore because the main process get it too, it is declared to ignore in main.c. */
...
My understanding of Unix/Linux signals is that the comment above is wrong and always has been wrong, a signal sent to a child process by a parent process does not get delivered to the parent.
When you execute a gdb -exec-interrupt command in debugger or Scope, a SIGINT is sent to the inferior, and to gdb, and to Geany. But if you start gdb from a terminal, the signal is sent to inferior only.
debugger moves gdb/inferior to a new process group, which sometimes fails.
Sounds like -exec-interrupt is sending to the process group, (see kill(2) with a negative number) which it would have inherited from Geany and so includes Geany in it.
Scope disables SIGINT in Geany while debugging.
glib spawn is much more complex than a normal fork/exec...
And mysterious, unless you read the source, but then you can't rely on that either.
Cheers Lex
-- E-gards: Jimmy _______________________________________________ Devel mailing list Devel@lists.geany.org https://lists.geany.org/cgi-bin/mailman/listinfo/devel
On Wed, 13 Mar 2013 08:51:14 +1100 Lex Trotman elextr@gmail.com wrote:
On 13 March 2013 04:47, Dimitar Zhekov dimitar.zhekov@gmail.com wrote:
When you execute a gdb -exec-interrupt command in debugger or Scope, a SIGINT is sent to the inferior, and to gdb, and to Geany. But if you start gdb from a terminal, the signal is sent to inferior only.
Sounds like -exec-interrupt is sending to the process group, (see kill(2) with a negative number) which it would have inherited from Geany and so includes Geany in it.
gdb and the inferior are always in different sessions and process groups, and an -exec-interrupt can SIGINTerrupt your entire X11 (though I've only seen that with Geany started from XSMP, and I plan to drop the X11 sm support anyway). Looks more like kill(-1, SIGINT) to me, but then again, if gdb is started from any kind of terminal, the signal is sent to the inferior only, no exceptions.
I googled for this problem, only to find that that Alexander Petukhov (the author of debugger) questioned for it before me, but got no sensible answer.