bug#20471: Emacs ceased to respond to C-g on a tty; SIGINT became blocked?

bug#20471: Emacs ceased to respond to C-g on a tty; SIGINT became blocked?

[Ivan Shmakov]

Package: emacs

	After some unfortunate interaction with a process (or perhaps a
	network connection), one of my Emacs instances (built from Git;
	1c7f0cdc4c1f, 2015-04-27 16:59:11 UTC) ceased to respond to C-g
	on a tty.

	Attaching GDB to it shows no signals being delivered on C-g,
	which (AIUI) hints at either SIGINT being blocked /or/ C-g
	“unbound” from the signal via terminal settings.  I’ve copied
	the latter from a terminal used by a properly working Emacs
	instance with the stty(1) invocation below, yet I still see no
	signals via GDB, which leaves the signal mask as the only point
	of failure that I can think of.

$ stty -F /dev/pts/non-working "$(stty -gF /dev/pts/working)" 

	Any suggestion on how do I debug this issue any further?

	TIA.

-- 
FSF associate member #7257  np. Dance of Death — Iron Maiden … B6A0 230E 334A

bug#20471: Emacs ceased to respond to C-g on a tty; SIGINT became blocked?

[Andreas Schwab]

Ivan Shmakov <ivan@siamics.net> writes:

> 	Attaching GDB to it shows no signals being delivered on C-g,
> 	which (AIUI) hints at either SIGINT being blocked /or/ C-g
> 	“unbound” from the signal via terminal settings. I’ve copied
> 	the latter from a terminal used by a properly working Emacs
> 	instance with the stty(1) invocation below, yet I still see no
> 	signals via GDB, which leaves the signal mask as the only point
> 	of failure that I can think of.

A blocked signal would still be visible in the debugger (assuming you
haven't changed the handling of SIGINT in gdb).

Andreas.

-- 
Andreas Schwab, schwab@linux-m68k.org
GPG Key fingerprint = 58CA 54C7 6D53 942B 1756  01D3 44D5 214B 8276 4ED5
"And now for something completely different."

bug#20471: Emacs ceased to respond to C-g on a tty; SIGINT became blocked?

[Ivan Shmakov]

[-- Attachment #1: Type: text/plain, Size: 1887 bytes --]

>>>>> Andreas Schwab <schwab@linux-m68k.org> writes:
>>>>> Ivan Shmakov <ivan@siamics.net> writes:

 >> Attaching GDB to it shows no signals being delivered on C-g, which
 >> (AIUI) hints at either SIGINT being blocked /or/ C-g “unbound” from
 >> the signal via terminal settings.  I’ve copied the latter from a
 >> terminal used by a properly working Emacs instance with the stty(1)
 >> invocation below, yet I still see no signals via GDB, which leaves
 >> the signal mask as the only point of failure that I can think of.

 >> Any suggestion on how do I debug this issue any further?

 > A blocked signal would still be visible in the debugger

	It’s not what I observe.  Why, SIGINT seem to be ignored by GDB
	itself when it’s attached to that Emacs instance.

 > (assuming you haven't changed the handling of SIGINT in gdb).

	I didn’t.

(gdb) info signals 
Signal        Stop      Print   Pass to program Description

SIGHUP        Yes       Yes     Yes             Hangup
SIGINT        Yes       Yes     No              Interrupt
SIGQUIT       Yes       Yes     Yes             Quit
…

	Just in case, the ps(1) output for two of my Emacs instances
	goes below.  The GDB ‘bt’ output at SIGCONT time (after a
	properly handled C-z) is MIMEd, too.

	To note is that I’ve tried to set a breakpoint on the next line
	of internal_catch (), but it doesn’t seem to ever be triggered.
	Could it hint at some non-local exit issue, perhaps?

$ ps -o pid,pending,blocked,ignored,caught,stat,bsdtime,command \
      -C emacs24 -C emacs25 
  PID   PENDING   BLOCKED   IGNORED    CAUGHT STAT   TIME COMMAND
19987  00000000  00000000  14001000 <cb816eff S+   843:01 emacs24
25806  00000002  04002006  04001000 <db816eff Sl+   52:00 emacs25
$ 

-- 
FSF associate member #7257  http://am-1.org/~ivan/      … 3013 B6A0 230E 334A

[-- Attachment #2: Type: application/octet-stream, Size: 2674 bytes --]

(gdb) bt 
#0  0x00007f4cb4d13f0a in tcsetattr () from /lib/x86_64-linux-gnu/libc.so.6
#1  0x00000000004a5e71 in emacs_set_tty (fd=5, 
    settings=settings@entry=0x7fffb46cfaf0, flushp=flushp@entry=false)
    at sysdep.c:850
#2  0x00000000004a6c84 in init_sys_modes (tty_out=0x12c20c0) at sysdep.c:1079
#3  0x00000000004a6f18 in init_all_sys_modes () at sysdep.c:907
#4  0x00000000004fcce2 in unbind_to (count=<optimized out>, value=0)
    at eval.c:3217
#5  0x000000000049d8f5 in Fsuspend_emacs (stuffstring=0) at keyboard.c:10266
#6  0x00000000004fdf13 in Ffuncall (nargs=5, args=0x7b0250 <Ssuspend_emacs>)
    at eval.c:2718
#7  0x0000000000530073 in exec_byte_code (bytestr=<optimized out>, 
    vector=9208813, maxdepth=<optimized out>, args_template=<optimized out>, 
    nargs=<optimized out>, args=<optimized out>) at bytecode.c:919
#8  0x00000000004fdd33 in Ffuncall (nargs=5, nargs@entry=1, 
    args=0x8c8390 <pure+1118096>) at eval.c:2779
#9  0x00000000004f9b3a in Ffuncall_interactively (nargs=1, args=0x7fffb46cff88)
    at callint.c:252
#10 0x00000000004fde19 in Ffuncall (nargs=5, nargs@entry=2, 
    args=0xa95dd8 <Sfuncall_interactively>) at eval.c:2698
#11 0x00000000004ff18c in Fapply (nargs=nargs@entry=3, 
    args=args@entry=0x7fffb46cff80) at eval.c:2289
#12 0x00000000004f9e98 in Fcall_interactively (function=3671376, 
    record_flag=0, keys=<optimized out>) at callint.c:394
#13 0x00000000004fdef7 in Ffuncall (nargs=5, 
    args=0xa95da8 <Scall_interactively>) at eval.c:2725
#14 0x0000000000530073 in exec_byte_code (bytestr=<optimized out>, 
    vector=8964949, maxdepth=<optimized out>, args_template=<optimized out>, 
    nargs=<optimized out>, args=<optimized out>) at bytecode.c:919
#15 0x00000000004fdd33 in Ffuncall (nargs=5, nargs@entry=2, 
    args=0x88cb00 <pure+874240>) at eval.c:2779
#16 0x00000000004fdfea in call1 (fn=fn@entry=12096, arg1=<optimized out>)
    at eval.c:2573
#17 0x000000000049c90d in command_loop_1 () at keyboard.c:1521
#18 0x00000000004fc617 in internal_condition_case (
    bfun=bfun@entry=0x49c520 <command_loop_1>, handlers=handlers@entry=15888, 
    hfun=hfun@entry=0x493a50 <cmd_error>) at eval.c:1348
#19 0x000000000048f5ac in command_loop_2 (ignore=ignore@entry=0)
    at keyboard.c:1139
#20 0x00000000004fc4f3 in internal_catch (tag=tag@entry=40992, 
    func=func@entry=0x48f590 <command_loop_2>, arg=arg@entry=0) at eval.c:1108
#21 0x000000000048f569 in command_loop () at keyboard.c:1118
#22 0x0000000000493666 in recursive_edit_1 () at keyboard.c:728
#23 0x0000000000493980 in Frecursive_edit () at keyboard.c:799
#24 0x0000000000407f78 in main (argc=1, argv=0x7fffb46d05e8) at emacs.c:1626
(gdb) 

bug#20471: Emacs ceased to respond to C-g on a tty; SIGINT became blocked?

[Eli Zaretskii]

> From: Ivan Shmakov <ivan@siamics.net>
> Date: Mon, 04 May 2015 15:55:48 +0000
> 
> >>>>> Andreas Schwab <schwab@linux-m68k.org> writes:
> >>>>> Ivan Shmakov <ivan@siamics.net> writes:
> 
>  >> Attaching GDB to it shows no signals being delivered on C-g, which
>  >> (AIUI) hints at either SIGINT being blocked /or/ C-g “unbound” from
>  >> the signal via terminal settings.  I’ve copied the latter from a
>  >> terminal used by a properly working Emacs instance with the stty(1)
>  >> invocation below, yet I still see no signals via GDB, which leaves
>  >> the signal mask as the only point of failure that I can think of.
> 
>  >> Any suggestion on how do I debug this issue any further?
> 
>  > A blocked signal would still be visible in the debugger
> 
> 	It’s not what I observe.  Why, SIGINT seem to be ignored by GDB
> 	itself when it’s attached to that Emacs instance.
> 
>  > (assuming you haven't changed the handling of SIGINT in gdb).

Is this on a TTY frame?  If not, then C-g doesn't trigger a SIGINT in
Emacs.

bug#20471: Emacs ceased to respond to C-g on a tty; SIGINT became blocked?

[Ivan Shmakov]

>>>>> Eli Zaretskii <eliz@gnu.org> writes:
>>>>> From: Ivan Shmakov  Date: Mon, 04 May 2015 15:55:48 +0000
>>>>> Andreas Schwab <schwab@linux-m68k.org> writes:

[…]

 >>> A blocked signal would still be visible in the debugger

 >> It’s not what I observe.  Why, SIGINT seem to be ignored by GDB
 >> itself when it’s attached to that Emacs instance.

 >>> (assuming you haven't changed the handling of SIGINT in gdb).

 > Is this on a TTY frame?

	Yes.  FWIW, I use non-tty Emacs frames only occasionally.

 > If not, then C-g doesn't trigger a SIGINT in Emacs.

	Yes.  (I’ve already read that part in keyboard.c.)

PS.  GNU Screen is just so welcoming an environment I can’t give it up
	easily.

-- 
FSF associate member #7257  http://am-1.org/~ivan/      … 3013 B6A0 230E 334A

bug#20471: Emacs ceased to respond to C-g on a tty; SIGINT became blocked?

[Lars Ingebrigtsen]

Ivan Shmakov <ivan@siamics.net> writes:

> 	After some unfortunate interaction with a process (or perhaps a
> 	network connection), one of my Emacs instances (built from Git;
> 	1c7f0cdc4c1f, 2015-04-27 16:59:11 UTC) ceased to respond to C-g
> 	on a tty.

(I'm going through old bug reports that unfortunately weren't resolved
at the time.)

Are you still seeing this issue in recent Emacs versions?

-- 
(domestic pets only, the antidote for overdose, milk.)
   bloggy blog: http://lars.ingebrigtsen.no

bug#20471: Emacs ceased to respond to C-g on a tty; SIGINT became blocked?

[Lars Ingebrigtsen]

Lars Ingebrigtsen <larsi@gnus.org> writes:

> Are you still seeing this issue in recent Emacs versions?

More information was requested, but no response was given within a
month, so I'm closing this bug report.  If the problem still exists,
please respond to this email and we'll reopen the bug report.

-- 
(domestic pets only, the antidote for overdose, milk.)
   bloggy blog: http://lars.ingebrigtsen.no

bug#20471: Emacs ceased to respond to C-g on a tty; SIGINT became blocked?

[Ivan Shmakov]

>>>>> On 2022-05-02, Lars Ingebrigtsen wrote:
>>>>> IS == Ivan Shmakov wrote:

 > (I’m going through old bug reports that unfortunately weren’t resolved
 > at the time.)

 > Are you still seeing this issue in recent Emacs versions?

	I haven’t put Emacs to much use in a couple of years, so that’d
	be a no.  I cannot readily recall which versions I’ve had this
	bug on, but while very rare (perhaps only happening once in a few
	weeks), I’m pretty certain I’ve encountered it more than once.

 IS> After some unfortunate interaction with a process (or perhaps a
 IS> network connection), one of my Emacs instances (built from Git;
 IS> 1c7f0cdc4c1f, 2015-04-27 16:59:11 UTC) ceased to respond to C-g
 IS> on a tty.

 IS> Attaching GDB to it shows no signals being delivered on C-g,
 IS> which (AIUI) hints at either SIGINT being blocked /or/ C-g
 IS> “unbound” from the signal via terminal settings.

 IS> $ ps -o pid,pending,blocked,ignored,caught,stat,bsdtime,command \
 IS>       -C emacs24 -C emacs25 
 IS>   PID   PENDING   BLOCKED   IGNORED    CAUGHT STAT   TIME COMMAND
 IS> 19987  00000000  00000000  14001000 <cb816eff S+   843:01 emacs24
 IS> 25806  00000002  04002006  04001000 <db816eff Sl+   52:00 emacs25
 IS> $ 

	AIUI, bit 1 set (as in, ‘0 != (mask & 2)’) in the ‘blocked’
	mask above suggests that signal 2 (SIGINT) was indeed blocked.
	Ditto for ‘pending.’

-- 
FSF associate member #7257  np. AUTOEXEC.BAT — Master Boot Record

bug#20471: Emacs ceased to respond to C-g on a tty; SIGINT became blocked?

[Lars Ingebrigtsen]

Ivan Shmakov <ivan@siamics.net> writes:

> 	I haven’t put Emacs to much use in a couple of years, so that’d
> 	be a no.  I cannot readily recall which versions I’ve had this
> 	bug on, but while very rare (perhaps only happening once in a few
> 	weeks), I’m pretty certain I’ve encountered it more than once.

OK; I'm closing this bug report, then.

-- 
(domestic pets only, the antidote for overdose, milk.)
   bloggy blog: http://lars.ingebrigtsen.no