Weird behavior and crash with X and TTY frame

Weird behavior and crash with X and TTY frame

[Dmitry Antipov]

On r112235 configured with --with-x-toolkit=gtk3 --enable-checking:

1. ./src/emacs -Q -nw
2. M-x make-frame-on-display :0.0
3. On X frame, eval: (x-popup-dialog t '("Test" ("yes" . 1)))
4. Do not touch popup, but go back to TTY frame and press C-g C-g.
5. Shell responds with:

[1]+  Stopped                 ./src/emacs -Q -nw

6. At shell prompt, resume Emacs with %1. Response is:

./src/emacs -Q -nw
Auto-save? (y or n) [answer y]
Auto-save done
Abort (and dump core)? (y or n) [answer y]

==> crash:

#0  0x0000003daf40eedb in raise (sig=sig@entry=6) at ../nptl/sysdeps/unix/sysv/linux/pt-raise.c:41
#1  0x000000000051da46 in terminate_due_to_signal (sig=sig@entry=6, backtrace_limit=backtrace_limit@entry=40)
     at src/emacs.c:343
#2  0x000000000053d583 in emacs_abort () at src/sysdep.c:2148
#3  0x00000000005206f9 in handle_interrupt (in_signal_handler=<optimized out>)
     at src/keyboard.c:10389
#4  0x000000000053d215 in deliver_process_signal (sig=2, handler=0x520700 <handle_interrupt_signal>)
     at src/sysdep.c:1591
#5  <signal handler called>
#6  0x0000003dae8eb889 in __pselect (nfds=nfds@entry=8, readfds=readfds@entry=0x7fffcf24d6f0, writefds=writefds@entry=0x0,
     exceptfds=exceptfds@entry=0x0, timeout=<optimized out>, timeout@entry=0x0, sigmask=sigmask@entry=0x0)
     at ../sysdeps/unix/sysv/linux/pselect.c:78
#7  0x000000000050bc5b in xg_select (fds_lim=8, rfds=0x7fffcf24d6f0, wfds=0x0, efds=0x0, timeout=0x0, sigmask=0x0)
     at src/xgselect.c:48
#8  0x0000000000479d88 in x_menu_wait_for_event (data=<optimized out>) at src/xmenu.c:407
#9  popup_widget_loop (widget=<optimized out>, do_timers=<optimized out>) at src/xmenu.c:606
#10 0x000000000047a2f3 in create_and_show_dialog (first_wv=<optimized out>, f=0x12cf948)
     at src/xmenu.c:1934
#11 xdialog_show (keymaps=false, error_name=<synthetic pointer>, header=..., f=0x12cf948, title=...)
     at src/xmenu.c:2142
#12 Fx_popup_dialog (position=..., contents=..., header=...) at src/xmenu.c:329
#13 0x00000000005a87fe in eval_sub (form=..., form@entry=...) at src/eval.c:2045
#14 0x00000000005ac3b2 in Feval (form=..., lexical=...) at src/eval.c:1901
#15 0x00000000005a95e6 in Ffuncall (nargs=<optimized out>, args=<optimized out>) at src/eval.c:2677
#16 0x00000000005ef203 in exec_byte_code (bytestr=..., vector=..., maxdepth=..., args_template=..., nargs=140736668686848, args=
     0x7fffcf24d110, args@entry=0x7fffcf24db98) at src/bytecode.c:900
#17 0x00000000005a8e79 in funcall_lambda (fun=..., nargs=nargs@entry=2, arg_vector=arg_vector@entry=0x7fffcf24db98)
     at src/eval.c:2840
#18 0x00000000005a941b in Ffuncall (nargs=nargs@entry=3, args=0x7fffcf24db90) at src/eval.c:2735
#19 0x00000000005aac3b in Fapply (nargs=nargs@entry=2, args=args@entry=0x7fffcf24dc40)
     at src/eval.c:2208
#20 0x00000000005aadae in apply1 (fn=..., arg=..., arg@entry=...) at src/eval.c:2442
#21 0x00000000005a4fe2 in Fcall_interactively (function=..., record_flag=..., keys=...)
     at src/callint.c:377
#22 0x00000000005a95d5 in Ffuncall (nargs=<optimized out>, args=<optimized out>) at src/eval.c:2681
#23 0x00000000005ef203 in exec_byte_code (bytestr=..., vector=..., maxdepth=..., args_template=..., nargs=140736668687872, args=
     0x7fffcf24d110, args@entry=0x7fffcf24dfb8) at src/bytecode.c:900
#24 0x00000000005a8e79 in funcall_lambda (fun=..., nargs=nargs@entry=1, arg_vector=arg_vector@entry=0x7fffcf24dfb8)
     at src/eval.c:2840
#25 0x00000000005a941b in Ffuncall (nargs=nargs@entry=2, args=args@entry=0x7fffcf24dfb0)
     at src/eval.c:2735
#26 0x00000000005a974a in call1 (fn=..., arg1=...) at src/eval.c:2468
#27 0x0000000000530a1c in command_loop_1 () at src/keyboard.c:1578
#28 0x00000000005a7603 in internal_condition_case (bfun=bfun@entry=0x530580 <command_loop_1>, handlers=..., hfun=hfun@entry=
     0x523e60 <cmd_error>) at src/eval.c:1193
#29 0x000000000051dd0e in command_loop_2 (ignore=..., ignore@entry=...) at src/keyboard.c:1167
#30 0x00000000005a74de in internal_catch (tag=..., func=func@entry=0x51dcf0 <command_loop_2>, arg=...)
     at src/eval.c:964
#31 0x000000000052380e in command_loop () at src/keyboard.c:1146
#32 recursive_edit_1 () at src/keyboard.c:779
#33 0x0000000000523b8e in Frecursive_edit () at src/keyboard.c:843
#34 0x000000000041a2a5 in main (argc=<optimized out>, argv=0x7fffcf24e5d8) at src/emacs.c:1531

Dmitry

Re: Weird behavior and crash with X and TTY frame

[Jan Djärv]

Hello.

This is something Emacs can't handle.  It is because how the lisp and event loop interracts.

When you do (x-popup-dialog t '("Test" ("yes" . 1))), a Lisp return value is expected back to the Lisp code.  So Emacs does not execute any more Lisp, until the dialog is popped down.
The popup is shown by a loop that just processes X events (x_menu_wait_for_event).
When you switch frame and do C-g C-g, the "normal" stuff does not happen, because Lisp is not executed.

This would be solvable if we had an independent Lisp loop per terminal, but it is not so.
There is only one Lisp loop, shared by all frames/terminals, and if one frame/terminal suspends the loop, it is suspended for all frames/terminals.

	Jan D.

6 apr 2013 kl. 15:03 skrev Dmitry Antipov <dmantipov@yandex.ru>:

> On r112235 configured with --with-x-toolkit=gtk3 --enable-checking:
> 
> 1. ./src/emacs -Q -nw
> 2. M-x make-frame-on-display :0.0
> 3. On X frame, eval: (x-popup-dialog t '("Test" ("yes" . 1)))
> 4. Do not touch popup, but go back to TTY frame and press C-g C-g.
> 5. Shell responds with:
> 
> [1]+  Stopped                 ./src/emacs -Q -nw
> 
> 6. At shell prompt, resume Emacs with %1. Response is:
> 
> ./src/emacs -Q -nw
> Auto-save? (y or n) [answer y]
> Auto-save done
> Abort (and dump core)? (y or n) [answer y]
> 
> ==> crash:
> 
> #0  0x0000003daf40eedb in raise (sig=sig@entry=6) at ../nptl/sysdeps/unix/sysv/linux/pt-raise.c:41
> #1  0x000000000051da46 in terminate_due_to_signal (sig=sig@entry=6, backtrace_limit=backtrace_limit@entry=40)
>    at src/emacs.c:343
> #2  0x000000000053d583 in emacs_abort () at src/sysdep.c:2148
> #3  0x00000000005206f9 in handle_interrupt (in_signal_handler=<optimized out>)
>    at src/keyboard.c:10389
> #4  0x000000000053d215 in deliver_process_signal (sig=2, handler=0x520700 <handle_interrupt_signal>)
>    at src/sysdep.c:1591
> #5  <signal handler called>
> #6  0x0000003dae8eb889 in __pselect (nfds=nfds@entry=8, readfds=readfds@entry=0x7fffcf24d6f0, writefds=writefds@entry=0x0,
>    exceptfds=exceptfds@entry=0x0, timeout=<optimized out>, timeout@entry=0x0, sigmask=sigmask@entry=0x0)
>    at ../sysdeps/unix/sysv/linux/pselect.c:78
> #7  0x000000000050bc5b in xg_select (fds_lim=8, rfds=0x7fffcf24d6f0, wfds=0x0, efds=0x0, timeout=0x0, sigmask=0x0)
>    at src/xgselect.c:48
> #8  0x0000000000479d88 in x_menu_wait_for_event (data=<optimized out>) at src/xmenu.c:407
> #9  popup_widget_loop (widget=<optimized out>, do_timers=<optimized out>) at src/xmenu.c:606
> #10 0x000000000047a2f3 in create_and_show_dialog (first_wv=<optimized out>, f=0x12cf948)
>    at src/xmenu.c:1934
> #11 xdialog_show (keymaps=false, error_name=<synthetic pointer>, header=..., f=0x12cf948, title=...)
>    at src/xmenu.c:2142
> #12 Fx_popup_dialog (position=..., contents=..., header=...) at src/xmenu.c:329
> #13 0x00000000005a87fe in eval_sub (form=..., form@entry=...) at src/eval.c:2045
> #14 0x00000000005ac3b2 in Feval (form=..., lexical=...) at src/eval.c:1901
> #15 0x00000000005a95e6 in Ffuncall (nargs=<optimized out>, args=<optimized out>) at src/eval.c:2677
> #16 0x00000000005ef203 in exec_byte_code (bytestr=..., vector=..., maxdepth=..., args_template=..., nargs=140736668686848, args=
>    0x7fffcf24d110, args@entry=0x7fffcf24db98) at src/bytecode.c:900
> #17 0x00000000005a8e79 in funcall_lambda (fun=..., nargs=nargs@entry=2, arg_vector=arg_vector@entry=0x7fffcf24db98)
>    at src/eval.c:2840
> #18 0x00000000005a941b in Ffuncall (nargs=nargs@entry=3, args=0x7fffcf24db90) at src/eval.c:2735
> #19 0x00000000005aac3b in Fapply (nargs=nargs@entry=2, args=args@entry=0x7fffcf24dc40)
>    at src/eval.c:2208
> #20 0x00000000005aadae in apply1 (fn=..., arg=..., arg@entry=...) at src/eval.c:2442
> #21 0x00000000005a4fe2 in Fcall_interactively (function=..., record_flag=..., keys=...)
>    at src/callint.c:377
> #22 0x00000000005a95d5 in Ffuncall (nargs=<optimized out>, args=<optimized out>) at src/eval.c:2681
> #23 0x00000000005ef203 in exec_byte_code (bytestr=..., vector=..., maxdepth=..., args_template=..., nargs=140736668687872, args=
>    0x7fffcf24d110, args@entry=0x7fffcf24dfb8) at src/bytecode.c:900
> #24 0x00000000005a8e79 in funcall_lambda (fun=..., nargs=nargs@entry=1, arg_vector=arg_vector@entry=0x7fffcf24dfb8)
>    at src/eval.c:2840
> #25 0x00000000005a941b in Ffuncall (nargs=nargs@entry=2, args=args@entry=0x7fffcf24dfb0)
>    at src/eval.c:2735
> #26 0x00000000005a974a in call1 (fn=..., arg1=...) at src/eval.c:2468
> #27 0x0000000000530a1c in command_loop_1 () at src/keyboard.c:1578
> #28 0x00000000005a7603 in internal_condition_case (bfun=bfun@entry=0x530580 <command_loop_1>, handlers=..., hfun=hfun@entry=
>    0x523e60 <cmd_error>) at src/eval.c:1193
> #29 0x000000000051dd0e in command_loop_2 (ignore=..., ignore@entry=...) at src/keyboard.c:1167
> #30 0x00000000005a74de in internal_catch (tag=..., func=func@entry=0x51dcf0 <command_loop_2>, arg=...)
>    at src/eval.c:964
> #31 0x000000000052380e in command_loop () at src/keyboard.c:1146
> #32 recursive_edit_1 () at src/keyboard.c:779
> #33 0x0000000000523b8e in Frecursive_edit () at src/keyboard.c:843
> #34 0x000000000041a2a5 in main (argc=<optimized out>, argv=0x7fffcf24e5d8) at src/emacs.c:1531
> 
> Dmitry

Re: Weird behavior and crash with X and TTY frame

[Dmitry Antipov]

On 04/07/2013 04:06 PM, Jan Djärv wrote:

> This is something Emacs can't handle.  It is because how the lisp and event loop interracts.
>
> When you do (x-popup-dialog t '("Test" ("yes" . 1))), a Lisp return value is expected back to the Lisp code.
> So Emacs does not execute any more Lisp, until the dialog is popped down.
> The popup is shown by a loop that just processes X events (x_menu_wait_for_event).
> When you switch frame and do C-g C-g, the "normal" stuff does not happen, because Lisp is not executed.
>
> This would be solvable if we had an independent Lisp loop per terminal, but it is not so.
> There is only one Lisp loop, shared by all frames/terminals, and if one frame/terminal suspends the loop,
> it is suspended for all frames/terminals.

Yes, but the same trick with two X frames doesn't crash at least; first C-g on
X frame 2 cancels popup raised on frame 1 and resumes normal event processing loop.

Dmitry

Re: Weird behavior and crash with X and TTY frame

[Eli Zaretskii]

> Date: Sun, 07 Apr 2013 19:18:44 +0400
> From: Dmitry Antipov <dmantipov@yandex.ru>
> Cc: Emacs development discussions <emacs-devel@gnu.org>
> 
> Yes, but the same trick with two X frames doesn't crash at least

It's not a crash, it's a deliberate abort.

> first C-g on X frame 2 cancels popup raised on frame 1 and resumes
> normal event processing loop.

Because C-g input to a GUI frame is delivered to Emacs as SIGIO, while
to a TTY frame it is delivered as SIGINT.  The processing is very
different, and AFAIU cannot be the same, because these two signals
have very different attributes on Posix systems.

See my other message, which described what happens here in more
detail.

Re: Weird behavior and crash with X and TTY frame

[Eli Zaretskii]

> From: Jan Djärv <jan.h.d@swipnet.se>
> Date: Sun, 7 Apr 2013 14:06:46 +0200
> Cc: Emacs development discussions <emacs-devel@gnu.org>
> 
> This is something Emacs can't handle.  It is because how the lisp and event loop interracts.
> 
> When you do (x-popup-dialog t '("Test" ("yes" . 1))), a Lisp return value is expected back to the Lisp code.  So Emacs does not execute any more Lisp, until the dialog is popped down.
> The popup is shown by a loop that just processes X events (x_menu_wait_for_event).
> When you switch frame and do C-g C-g, the "normal" stuff does not happen, because Lisp is not executed.
> 
> This would be solvable if we had an independent Lisp loop per terminal, but it is not so.
> There is only one Lisp loop, shared by all frames/terminals, and if one frame/terminal suspends the loop, it is suspended for all frames/terminals.

Actually, this isn't a problem at all.  It's a (very old) feature,
called "emergency escape": when Emacs is stuck in some prolonged
computation or loop, typing C-g twice on a TTY invokes this behavior,
whereby the TTY is first suspended, to get the user a chance to
investigate what's wrong (in case there are no other windows to do
that, but just a single console), and then, after Emacs is resumed, it
offers to dump core, so that the problem could be looked into with a
debugger.  See the node "Emergency Escape" in the user manual.

The only misfeature in this scenario is that the "loop" in this case
is processing X events for a dialog we popped up ourselves.

FWIW, I don't see any particular problem here.  To make things more
explicit, perhaps x-popup-dialog should set some variable that
handle_interrupt could test and display some descriptive message in
the echo area, so the user would know that the X frame is in a modal
state.

Re: Weird behavior and crash with X and TTY frame

[grischka]

> This would be solvable if we had an independent Lisp loop per terminal, but it 
> is not so.
> There is only one Lisp loop, shared by all frames/terminals, and if one 
> frame/terminal suspends the loop, it is suspended for all frames/terminals.

Maybe you say "Lisp loop" because you think there can't be lisp
without a loop.  Thus you want to solve the problem with even
more loops while the problem is actually caused by the loop that
you already have.

--- gr