Terminal locked when spawning a new tty frame

Terminal locked when spawning a new tty frame

[Alex Bennée]

Hi,

On the current master I seem to be running into a semi-intermittent
problem spawning terminal frames. I'm usually running an emacs --daemon
with a GUI frame but from time to time I shell into my box and issue a:

  emacsclient -a '' -t

The frame gets created and comes up on the *scratch* buffer but it's not
responsive to keyboard input. I end up having to kill the emacsclient or
kill-window'ing my tmux frame it's in. If I SIGUSR2 the main emacs pid I
get the message:

  "Terminal 5 is locked, cannot read from it"

So far SO points out that this is because something is trying to read
the minibuffer on another tty although I'm not sure which tty this might
be as I've both a) left the GUI frame alone and b) ensured I've closed
any GUI frames before working remotely.

This doesn't happen all the time because after killing emacs and
restarting the daemon I have a working session again and can launch GUI
frames when I get back home.

So any ideas on how I can debug this next time it occurs?

--
Alex Bennée

Re: Terminal locked when spawning a new tty frame

[Andreas Schwab]

On Okt 16 2019, Alex Bennée <alex.bennee@linaro.org> wrote:

> So any ideas on how I can debug this next time it occurs?

I'd suggest to attach with a debugger and inspect kboard_stack and
single_kboard.

Andreas.

-- 
Andreas Schwab, SUSE Labs, schwab@suse.de
GPG Key fingerprint = 0196 BAD8 1CE9 1970 F4BE  1748 E4D4 88E3 0EEA B9D7
"And now for something completely different."

Re: Terminal locked when spawning a new tty frame

[Alex Bennée]

It's reproduced for me but so far nothing obvious sticks out:

(gdb) p kboard_stack
$1 = (struct kboard_stack *) 0x0
(gdb) p single_kboard
$2 = true
(gdb) c
Continuing.

On Wed, 16 Oct 2019 at 11:25, Andreas Schwab <schwab@suse.de> wrote:
>
> On Okt 16 2019, Alex Bennée <alex.bennee@linaro.org> wrote:
>
> > So any ideas on how I can debug this next time it occurs?
>
> I'd suggest to attach with a debugger and inspect kboard_stack and
> single_kboard.
>
> Andreas.
>
> --
> Andreas Schwab, SUSE Labs, schwab@suse.de
> GPG Key fingerprint = 0196 BAD8 1CE9 1970 F4BE  1748 E4D4 88E3 0EEA B9D7
> "And now for something completely different."



-- 
Alex Bennée
KVM/QEMU Hacker for Linaro

Re: Terminal locked when spawning a new tty frame

[Andreas Schwab]

On Okt 23 2019, Alex Bennée wrote:

> It's reproduced for me but so far nothing obvious sticks out:
>
> (gdb) p kboard_stack
> $1 = (struct kboard_stack *) 0x0
> (gdb) p single_kboard
> $2 = true

What do you get as backtrace?

Andreas.

-- 
Andreas Schwab, SUSE Labs, schwab@suse.de
GPG Key fingerprint = 0196 BAD8 1CE9 1970 F4BE  1748 E4D4 88E3 0EEA B9D7
"And now for something completely different."

Re: Terminal locked when spawning a new tty frame

[Alex Bennée]

Andreas Schwab <schwab@suse.de> writes:

> On Okt 23 2019, Alex Bennée wrote:
>
>> It's reproduced for me but so far nothing obvious sticks out:
>>
>> (gdb) p kboard_stack
>> $1 = (struct kboard_stack *) 0x0
>> (gdb) p single_kboard
>> $2 = true
>
> What do you get as backtrace?

(gdb) bt
#0  0x00007f26b2234151 in __pselect (nfds=36, readfds=0x7ffd0aca0820, writefds=0x7ffd0aca08a0, exceptfds=0x0, timeout=<optimized out>, sigmask=<optimized out>) at ../sysdeps/unix/sysv/linux/pselect.c:69
#1  0x000055ed55deb2c6 in really_call_select (arg=0x7ffd0aca0750) at thread.c:586
#2  0x000055ed55debda9 in thread_select (func=<optimized out>, max_fds=max_fds@entry=36, rfds=rfds@entry=0x7ffd0aca0820, wfds=wfds@entry=0x7ffd0aca08a0, efds=efds@entry=0x0, timeout=timeout@entry=0x7ffd0aca0e50, sigmask=0x0) at thread.c:616
#3  0x000055ed55e0a46b in xg_select (fds_lim=36, rfds=rfds@entry=0x7ffd0aca0f80, wfds=wfds@entry=0x7ffd0aca1000, efds=efds@entry=0x0, timeout=timeout@entry=0x7ffd0aca0e50, sigmask=sigmask@entry=0x0) at xgselect.c:117
#4  0x000055ed55dcb974 in wait_reading_process_output (time_limit=time_limit@entry=30, nsecs=nsecs@entry=0, read_kbd=read_kbd@entry=-1, do_display=do_display@entry=true, wait_for_cell=wait_for_cell@entry=0x0, wait_proc=wait_proc@entry=0x0, just_wait_proc=0) at process.c:5519
#5  0x000055ed55c522ee in sit_for (timeout=timeout@entry=0x7a, reading=reading@entry=true, display_option=display_option@entry=1) at lisp.h:1032
#6  0x000055ed55d26bf7 in read_char (commandflag=1, map=0x55ed60446f23, prev_event=0x0, used_mouse_menu=0x7ffd0aca185b, end_time=0x0) at lisp.h:1147
#7  0x000055ed55d2723e in read_key_sequence (keybuf=0x7ffd0aca1970, prompt=0x0, dont_downcase_last=<optimized out>, can_return_switch_frame=true, fix_current_buffer=true, prevent_redisplay=<optimized out>) at keyboard.c:9543
#8  0x000055ed55d2886c in command_loop_1 () at lisp.h:1032
#9  0x000055ed55d8d5a2 in internal_condition_case (bfun=bfun@entry=0x55ed55d28690 <command_loop_1>, handlers=handlers@entry=0x90, hfun=hfun@entry=0x55ed55d1f9f0 <cmd_error>) at eval.c:1355
#10 0x000055ed55d1a8a4 in command_loop_2 (ignore=ignore@entry=0x0) at lisp.h:1032
#11 0x000055ed55d8d521 in internal_catch (tag=tag@entry=0x5b50, func=func@entry=0x55ed55d1a880 <command_loop_2>, arg=arg@entry=0x0) at eval.c:1116
#12 0x000055ed55d1a805 in command_loop () at lisp.h:1032
#13 0x000055ed55d1f5f6 in recursive_edit_1 () at keyboard.c:714
#14 0x000055ed55d1f915 in Frecursive_edit () at keyboard.c:786
#15 0x000055ed55d8e2a3 in Ffuncall (nargs=1, args=args@entry=0x7ffd0aca1ca8) at lisp.h:2109
#16 0x000055ed55dc1d51 in exec_byte_code (bytestr=<optimized out>, vector=<optimized out>, maxdepth=<optimized out>, args_template=<optimized out>, nargs=<optimized out>, args=<optimized out>) at bytecode.c:633
#17 0x000055ed55d8e1ff in Ffuncall (nargs=3, args=0x7ffd0aca2060) at eval.c:2808
#18 0x000055ed55d8e532 in Fapply (nargs=nargs@entry=2, args=args@entry=0x7ffd0aca20f0) at eval.c:2424
#19 0x000055ed55d8e66c in apply1 (fn=<optimized out>, arg=arg@entry=0x55ed5d981de3) at lisp.h:1399
#20 0x000055ed55d8e858 in call_debugger (arg=0x55ed5d981de3) at eval.c:339
#21 0x000055ed55d8ef01 in maybe_call_debugger (data=0x55ed5d1a9ec3, sig=0xe520, conditions=0x7f26ae4ed72b) at lisp.h:1032
#22 0x000055ed55d8ef01 in signal_or_quit (error_symbol=0xe520, data=0x55ed5d1a9ec3, keyboard_quit=<optimized out>) at eval.c:1666
#23 0x000055ed55c44214 in Fsignal (error_symbol=<optimized out>, error_symbol@entry=0xe520, data=<optimized out>) at eval.c:1568
#24 0x000055ed55c4423e in xsignal (data=<optimized out>, error_symbol=0xe520) at lisp.h:4138
#25 0x000055ed55c4423e in xsignal1 (error_symbol=error_symbol@entry=0xe520, arg=arg@entry=0x38e2370) at eval.c:1707
#26 0x000055ed55c43b43 in Fsymbol_value (symbol=0x38e2370) at lisp.h:1032
#27 0x000055ed55dc1cad in exec_byte_code (bytestr=<optimized out>, vector=<optimized out>, maxdepth=<optimized out>, args_template=<optimized out>, nargs=<optimized out>, args=<optimized out>) at bytecode.c:498
#28 0x000055ed55d8e1ff in Ffuncall (nargs=1, args=args@entry=0x7ffd0aca2738) at eval.c:2808
#29 0x000055ed55dc1d51 in exec_byte_code (bytestr=<optimized out>, vector=<optimized out>, maxdepth=<optimized out>, args_template=<optimized out>, nargs=<optimized out>, args=<optimized out>) at bytecode.c:633
#30 0x000055ed55d90317 in eval_sub (form=<optimized out>) at lisp.h:2109
#31 0x000055ed55db30f8 in readevalloop (readcharfun=0x7020, infile0=0x7ffd0aca2b50, sourcename=0x55ed5d5b0054, printflag=false, unibyte=<optimized out>, readfun=0x0, start=0x0, end=0x0) at lread.c:2112
#32 0x000055ed55db3a31 in Fload (file=0x55ed5773b044, noerror=<optimized out>, nomessage=0x30, nosuffix=<optimized out>, must_suffix=<optimized out>) at lisp.h:1032
#33 0x000055ed55db3d1a in save_match_data_load (file=0x55ed5773b044, noerror=noerror@entry=0x0, nomessage=nomessage@entry=0x30, nosuffix=nosuffix@entry=0x0, must_suffix=must_suffix@entry=0x30) at lread.c:1529
#34 0x000055ed55d8df90 in Fautoload_do_load (fundef=0x55ed5865d9b3, funname=0x26e0650, macro_only=0x0) at lisp.h:1032
#35 0x000055ed55d8e1b6 in Ffuncall (nargs=1, args=args@entry=0x7ffd0aca2d08) at lisp.h:1032
#36 0x000055ed55dc1d51 in exec_byte_code (bytestr=<optimized out>, vector=<optimized out>, maxdepth=<optimized out>, args_template=args_template@entry=0x0, nargs=nargs@entry=0, args=<optimized out>, args@entry=0x0) at bytecode.c:633
#37 0x000055ed55d9085a in funcall_lambda (fun=0x55ed597ce625, nargs=0, arg_vector=0x7ffd0aca2f30) at lisp.h:1852
#38 0x000055ed55d8e1ff in Ffuncall (nargs=1, args=args@entry=0x7ffd0aca2f28) at eval.c:2808
#39 0x000055ed55dc1d51 in exec_byte_code (bytestr=<optimized out>, vector=<optimized out>, maxdepth=<optimized out>, args_template=args_template@entry=0x0, nargs=nargs@entry=0, args=<optimized out>, args@entry=0x0) at bytecode.c:633
#40 0x000055ed55d9085a in funcall_lambda (fun=0x55ed59866cb5, nargs=2, arg_vector=0x7ffd0aca31c0) at lisp.h:1852
#41 0x000055ed55d8e1ff in Ffuncall (nargs=3, args=args@entry=0x7ffd0aca31b8) at eval.c:2808
#42 0x000055ed55dc1d51 in exec_byte_code (bytestr=<optimized out>, vector=<optimized out>, maxdepth=<optimized out>, args_template=args_template@entry=0x0, nargs=nargs@entry=0, args=<optimized out>, args@entry=0x0) at bytecode.c:633
#43 0x000055ed55d9085a in funcall_lambda (fun=0x55ed597f3495, nargs=2, arg_vector=0x7ffd0aca34d8) at lisp.h:1852
#44 0x000055ed55d8e1ff in Ffuncall (nargs=3, args=0x7ffd0aca34d0) at eval.c:2808
#45 0x000055ed55d8e532 in Fapply (nargs=nargs@entry=2, args=args@entry=0x7ffd0aca3560) at eval.c:2424
#46 0x000055ed55d8e66c in apply1 (fn=<optimized out>, arg=<optimized out>) at lisp.h:1399
#47 0x000055ed55d8d63a in internal_condition_case_1 (bfun=bfun@entry=0x55ed55dc4400 <read_process_output_call>, arg=0x55ed5c8383b3, handlers=handlers@entry=0x0, hfun=hfun@entry=0x55ed55dc4360 <read_process_output_error_handler>) at eval.c:1379
#48 0x000055ed55dc46a9 in read_and_dispose_of_process_output (coding=<optimized out>, nbytes=2233, chars=0x7ffd0aca35f0 "POST /edit HTTP/1.1\r\nHost: 127.0.0.1:9292\r\nUser-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:69.0) Gecko/20100101 Firefox/69.0\r\nAccept: */*\r\nAccept-Language: en-GB,en;q=0.5\r\nAccept-Encoding: gzip, deflat"..., p=0xfffffffffffffffb) at lisp.h:1286
#49 0x000055ed55dc46a9 in read_process_output (proc=proc@entry=0x55ed5c7063d5, channel=channel@entry=10) at process.c:6062
#50 0x000055ed55dcbd28 in wait_reading_process_output (time_limit=time_limit@entry=30, nsecs=nsecs@entry=0, read_kbd=read_kbd@entry=-1, do_display=do_display@entry=true, wait_for_cell=wait_for_cell@entry=0x0, wait_proc=wait_proc@entry=0x0, just_wait_proc=0) at process.c:5755
#51 0x000055ed55c522ee in sit_for (timeout=timeout@entry=0x7a, reading=reading@entry=true, display_option=display_option@entry=1) at lisp.h:1032
#52 0x000055ed55d26bf7 in read_char (commandflag=1, map=0x55ed5bcd8e23, prev_event=0x0, used_mouse_menu=0x7ffd0aca516b, end_time=0x0) at lisp.h:1147
#53 0x000055ed55d2723e in read_key_sequence (keybuf=0x7ffd0aca5280, prompt=0x0, dont_downcase_last=<optimized out>, can_return_switch_frame=true, fix_current_buffer=true, prevent_redisplay=<optimized out>) at keyboard.c:9543
#54 0x000055ed55d2886c in command_loop_1 () at lisp.h:1032
#55 0x000055ed55d8d5a2 in internal_condition_case (bfun=bfun@entry=0x55ed55d28690 <command_loop_1>, handlers=handlers@entry=0x90, hfun=hfun@entry=0x55ed55d1f9f0 <cmd_error>) at eval.c:1355
#56 0x000055ed55d1a8a4 in command_loop_2 (ignore=ignore@entry=0x0) at lisp.h:1032
#57 0x000055ed55d8d521 in internal_catch (tag=tag@entry=0xd4d0, func=func@entry=0x55ed55d1a880 <command_loop_2>, arg=arg@entry=0x0) at eval.c:1116
#58 0x000055ed55d1a84b in command_loop () at lisp.h:1032
#59 0x000055ed55d1f5f6 in recursive_edit_1 () at keyboard.c:714
#60 0x000055ed55d1f915 in Frecursive_edit () at keyboard.c:786
#61 0x000055ed55c483ba in main (argc=2, argv=<optimized out>) at emacs.c:2055
(gdb) p kboard_stack
$1 = (struct kboard_stack *) 0x0
(gdb) p single_kboard
$2 = true
(gdb) c

Hmm is that a nested command_loop?

--
Alex Bennée

Re: Terminal locked when spawning a new tty frame

[Andreas Schwab]

On Okt 23 2019, Alex Bennée wrote:

> #13 0x000055ed55d1f5f6 in recursive_edit_1 () at keyboard.c:714
> #14 0x000055ed55d1f915 in Frecursive_edit () at keyboard.c:786
> #15 0x000055ed55d8e2a3 in Ffuncall (nargs=1, args=args@entry=0x7ffd0aca1ca8) at lisp.h:2109
> #16 0x000055ed55dc1d51 in exec_byte_code (bytestr=<optimized out>, vector=<optimized out>, maxdepth=<optimized out>, args_template=<optimized out>, nargs=<optimized out>, args=<optimized out>) at bytecode.c:633
> #17 0x000055ed55d8e1ff in Ffuncall (nargs=3, args=0x7ffd0aca2060) at eval.c:2808
> #18 0x000055ed55d8e532 in Fapply (nargs=nargs@entry=2, args=args@entry=0x7ffd0aca20f0) at eval.c:2424
> #19 0x000055ed55d8e66c in apply1 (fn=<optimized out>, arg=arg@entry=0x55ed5d981de3) at lisp.h:1399
> #20 0x000055ed55d8e858 in call_debugger (arg=0x55ed5d981de3) at eval.c:339
> #21 0x000055ed55d8ef01 in maybe_call_debugger (data=0x55ed5d1a9ec3, sig=0xe520, conditions=0x7f26ae4ed72b) at lisp.h:1032
> #22 0x000055ed55d8ef01 in signal_or_quit (error_symbol=0xe520, data=0x55ed5d1a9ec3, keyboard_quit=<optimized out>) at eval.c:1666
> #23 0x000055ed55c44214 in Fsignal (error_symbol=<optimized out>, error_symbol@entry=0xe520, data=<optimized out>) at eval.c:1568

So you have a frame inside the debugger, probably because debug-on-error
is non-nil.

Andreas.

-- 
Andreas Schwab, SUSE Labs, schwab@suse.de
GPG Key fingerprint = 0196 BAD8 1CE9 1970 F4BE  1748 E4D4 88E3 0EEA B9D7
"And now for something completely different."

Re: Terminal locked when spawning a new tty frame

[Alex Bennée]

Andreas Schwab <schwab@suse.de> writes:

> On Okt 23 2019, Alex Bennée wrote:
>
>> #13 0x000055ed55d1f5f6 in recursive_edit_1 () at keyboard.c:714
>> #14 0x000055ed55d1f915 in Frecursive_edit () at keyboard.c:786
>> #15 0x000055ed55d8e2a3 in Ffuncall (nargs=1, args=args@entry=0x7ffd0aca1ca8) at lisp.h:2109
>> #16 0x000055ed55dc1d51 in exec_byte_code (bytestr=<optimized out>, vector=<optimized out>, maxdepth=<optimized out>, args_template=<optimized out>, nargs=<optimized out>, args=<optimized out>) at bytecode.c:633
>> #17 0x000055ed55d8e1ff in Ffuncall (nargs=3, args=0x7ffd0aca2060) at eval.c:2808
>> #18 0x000055ed55d8e532 in Fapply (nargs=nargs@entry=2, args=args@entry=0x7ffd0aca20f0) at eval.c:2424
>> #19 0x000055ed55d8e66c in apply1 (fn=<optimized out>, arg=arg@entry=0x55ed5d981de3) at lisp.h:1399
>> #20 0x000055ed55d8e858 in call_debugger (arg=0x55ed5d981de3) at eval.c:339
>> #21 0x000055ed55d8ef01 in maybe_call_debugger (data=0x55ed5d1a9ec3, sig=0xe520, conditions=0x7f26ae4ed72b) at lisp.h:1032
>> #22 0x000055ed55d8ef01 in signal_or_quit (error_symbol=0xe520, data=0x55ed5d1a9ec3, keyboard_quit=<optimized out>) at eval.c:1666
>> #23 0x000055ed55c44214 in Fsignal (error_symbol=<optimized out>, error_symbol@entry=0xe520, data=<optimized out>) at eval.c:1568
>
> So you have a frame inside the debugger, probably because debug-on-error
> is non-nil.

I'll check next time. I might of knocked it on by mistake. The other
Andrés mentioned one workaround was killing an errant *Backtrace* but I
must admit I didn't check if the debugger was active during the failure.

>
> Andreas.


--
Alex Bennée

Re: Terminal locked when spawning a new tty frame

[Alex Bennée]

Alex Bennée <alex.bennee@linaro.org> writes:

> Andreas Schwab <schwab@suse.de> writes:
>
>> On Okt 23 2019, Alex Bennée wrote:
>>
>>> #13 0x000055ed55d1f5f6 in recursive_edit_1 () at keyboard.c:714
>>> #14 0x000055ed55d1f915 in Frecursive_edit () at keyboard.c:786
>>> #15 0x000055ed55d8e2a3 in Ffuncall (nargs=1, args=args@entry=0x7ffd0aca1ca8) at lisp.h:2109
>>> #16 0x000055ed55dc1d51 in exec_byte_code (bytestr=<optimized out>, vector=<optimized out>, maxdepth=<optimized out>, args_template=<optimized out>, nargs=<optimized out>, args=<optimized out>) at bytecode.c:633
>>> #17 0x000055ed55d8e1ff in Ffuncall (nargs=3, args=0x7ffd0aca2060) at eval.c:2808
>>> #18 0x000055ed55d8e532 in Fapply (nargs=nargs@entry=2, args=args@entry=0x7ffd0aca20f0) at eval.c:2424
>>> #19 0x000055ed55d8e66c in apply1 (fn=<optimized out>, arg=arg@entry=0x55ed5d981de3) at lisp.h:1399
>>> #20 0x000055ed55d8e858 in call_debugger (arg=0x55ed5d981de3) at eval.c:339
>>> #21 0x000055ed55d8ef01 in maybe_call_debugger (data=0x55ed5d1a9ec3, sig=0xe520, conditions=0x7f26ae4ed72b) at lisp.h:1032
>>> #22 0x000055ed55d8ef01 in signal_or_quit (error_symbol=0xe520, data=0x55ed5d1a9ec3, keyboard_quit=<optimized out>) at eval.c:1666
>>> #23 0x000055ed55c44214 in Fsignal (error_symbol=<optimized out>, error_symbol@entry=0xe520, data=<optimized out>) at eval.c:1568
>>
>> So you have a frame inside the debugger, probably because debug-on-error
>> is non-nil.
>
> I'll check next time. I might of knocked it on by mistake. The other
> Andrés mentioned one workaround was killing an errant *Backtrace* but I
> must admit I didn't check if the debugger was active during the
> failure.

So I have a reproducer and sure enough the *Backtrace* buffer was at:

Debugger entered--Lisp error: (quit)
  irony-iotask-run(#<process Irony> #s(irony-iotask-packaged-task :task (:start (lambda (process buffer) (if (assq buffer (process-get process :unsaved-buffers)) (irony--server-send-command "reset-unsaved" (irony--get-buffer-path-for-server buffer)) (irony-iotask-set-result t))) :update irony--server-command-update :finish (lambda (process buffer) (process-put process :unsaved-buffers (assq-delete-all buffer (process-get process :unsaved-buffers))))) :args (#<process Irony> #<buffer helper.c>) :result #s(irony-iotask-result :-tag nil :-value nil :-error nil :-error-data nil) :plist nil :continuation #s(irony-iotask-packaged-task :task (:start (lambda (process buffer buf-state) (let ((elem ...) temp-file) (if (eq ... buf-state) (irony-iotask-set-result t) (setq temp-file ...) (irony-iotask-put :temp-file temp-file) (irony-iotask-put :buffer-state buf-state) (process-put process :buffer-state buf-state) (with-current-buffer buffer ... ...)))) :update irony--server-command-update :finish (lambda (&rest _args) (delete-file (irony-iotask-get :temp-file))) :on-success (lambda (process buffer &rest _args) (let* ((unsaved-buffers ...) (elem ...) (buf-state ...)) (if elem (setcdr elem buf-state) (process-put process :unsaved-buffers ...))))) :args (#<process Irony> #<buffer gdbstub.c<arm>> #s(irony--buffer-state :file "/home/alex/lsrc/qemu.git/target/arm/gdbstub.c" :exists t :modified t :tick 3269)) :result #s(irony-iotask-result :-tag nil :-value nil :-error nil :-error-data nil) :plist nil :continuation #s(irony-iotask-packaged-task :task (:start (lambda (file line column compile-options) (apply #'irony--server-send-command "complete" file line column "--" compile-options)) :update irony--server-command-update) :args ("/home/alex/lsrc/qemu.git/target/arm/gdbstub.c" 173 10 ("-x" "c")) :result #s(irony-iotask-result :-tag nil :-value nil :-error nil :-error-data nil) :plist nil :continuation #s(irony-iotask-packaged-task :task (:start (lambda (prefix style) (irony--server-send-command "candidates" prefix ...)) :update irony--server-query-update) :args ("dyn_svereg_xml" exact) :result #s(irony-iotask-result :-tag nil :-value nil :-error nil :-error-data nil) :plist nil :continuation nil)))))
  irony--run-task(#s(irony-iotask-packaged-task :task (:start (lambda (process buffer) (if (assq buffer (process-get process :unsaved-buffers)) (irony--server-send-command "reset-unsaved" (irony--get-buffer-path-for-server buffer)) (irony-iotask-set-result t))) :update irony--server-command-update :finish (lambda (process buffer) (process-put process :unsaved-buffers (assq-delete-all buffer (process-get process :unsaved-buffers))))) :args (#<process Irony> #<buffer helper.c>) :result #s(irony-iotask-result :-tag nil :-value nil :-error nil :-error-data nil) :plist nil :continuation #s(irony-iotask-packaged-task :task (:start (lambda (process buffer buf-state) (let ((elem ...) temp-file) (if (eq ... buf-state) (irony-iotask-set-result t) (setq temp-file ...) (irony-iotask-put :temp-file temp-file) (irony-iotask-put :buffer-state buf-state) (process-put process :buffer-state buf-state) (with-current-buffer buffer ... ...)))) :update irony--server-command-update :finish (lambda (&rest _args) (delete-file (irony-iotask-get :temp-file))) :on-success (lambda (process buffer &rest _args) (let* ((unsaved-buffers ...) (elem ...) (buf-state ...)) (if elem (setcdr elem buf-state) (process-put process :unsaved-buffers ...))))) :args (#<process Irony> #<buffer gdbstub.c<arm>> #s(irony--buffer-state :file "/home/alex/lsrc/qemu.git/target/arm/gdbstub.c" :exists t :modified t :tick 3269)) :result #s(irony-iotask-result :-tag nil :-value nil :-error nil :-error-data nil) :plist nil :continuation #s(irony-iotask-packaged-task :task (:start (lambda (file line column compile-options) (apply #'irony--server-send-command "complete" file line column "--" compile-options)) :update irony--server-command-update) :args ("/home/alex/lsrc/qemu.git/target/arm/gdbstub.c" 173 10 ("-x" "c")) :result #s(irony-iotask-result :-tag nil :-value nil :-error nil :-error-data nil) :plist nil :continuation #s(irony-iotask-packaged-task :task (:start (lambda (prefix style) (irony--server-send-command "candidates" prefix ...)) :update irony--server-query-update) :args ("dyn_svereg_xml" exact) :result #s(irony-iotask-result :-tag nil :-value nil :-error nil :-error-data nil) :plist nil :continuation nil)))))
  irony-completion-at-point()
  completion--capf-wrapper(irony-completion-at-point optimist)
  run-hook-wrapped(completion--capf-wrapper irony-completion-at-point optimist)
  company--capf-data-real()
  company--capf-data()
  company-capf(prefix)
  apply(company-capf prefix)
  company-call-backend-raw(prefix)
  apply(company-call-backend-raw prefix)
  company--force-sync(company-call-backend-raw (prefix) company-capf)
  company-call-backend(prefix)
  company--begin-new()
  company--perform()
  company-auto-begin()
  company-idle-begin(#<buffer gdbstub.c<arm>> #<window 806 on gdbstub.c<arm>> 3269 5417)
  apply(company-idle-begin (#<buffer gdbstub.c<arm>> #<window 806 on gdbstub.c<arm>> 3269 5417))
  timer-event-handler([t 24001 55199 331097 nil company-idle-begin (#<buffer gdbstub.c<arm>> #<window 806 on gdbstub.c<arm>> 3269 5417) nil 869000])
  read-event(nil t 3)
  sit-for(3)
  flyspell-check-word-p()
  flyspell-post-command-hook()

Killing the *Backtrace* buffer restores things to working. It doesn't
seem to be specific to the backtrace as I can C-g while switching
buffers and get:

Debugger entered--Lisp error: (quit)
  read-from-minibuffer("Switch to buffer: " nil (keymap (keymap (11 . ivy-switch-buffer-kill)) keymap (36 . ivy-magic-read-file-env) (3 keymap (19 . ivy-rotate-sort) (1 . ivy-toggle-ignore) (15 . ivy-occur)) (67108903 . ivy-avy) (33554464 . ivy-restrict-to-matches) (15 . hydra-ivy/body) (22 . ivy-scroll-up-command) (prior . ivy-scroll-down-command) (next . ivy-scroll-up-command) (7 . minibuffer-keyboard-quit) (right . ivy-forward-char) (32 . self-insert-command) (18 . ivy-reverse-i-search) (19 . ivy-next-line-or-history) (remap keymap (describe-mode . ivy-help) (kill-ring-save . ivy-kill-ring-save) (kill-whole-line . ivy-kill-whole-line) (kill-line . ivy-kill-line) (scroll-down-command . ivy-scroll-down-command) (scroll-up-command . ivy-scroll-up-command) (end-of-buffer . ivy-end-of-buffer) (beginning-of-buffer . ivy-beginning-of-buffer) (kill-word . ivy-kill-word) (forward-char . ivy-forward-char) (delete-char . ivy-delete-char) (backward-kill-word . ivy-backward-kill-word) (backward-delete-char-untabify . ivy-backward-delete-char) (delete-backward-char . ivy-backward-delete-char) (previous-line . ivy-previous-line) (next-line . ivy-next-line)) (9 . ivy-partial-or-done) (10 . ivy-alt-done) (27 keymap (1 . ivy-read-action) (15 . ivy-dispatching-call) (111 . ivy-dispatching-done) (25 . ivy-insert-current-full) (105 . ivy-insert-current) (106 . ivy-yank-word) (114 . ivy-toggle-regexp-quote) (16 . ivy-previous-line-and-call) (14 . ivy-next-line-and-call) (118 . ivy-scroll-down-command) (112 . ivy-previous-history-element) (110 . ivy-next-history-element) (10 . ivy-immediate-done) (13 . ivy-call)) (mouse-3 . ivy-mouse-dispatching-done) (mouse-1 . ivy-mouse-done) (down-mouse-1 . ignore) (13 . ivy-done)) nil ivy-history)
  ivy-read("Switch to buffer: " internal-complete-buffer :keymap (keymap (11 . ivy-switch-buffer-kill)) :preselect "*Backtrace*" :action ivy--switch-buffer-action :matcher ivy--switch-buffer-matcher :caller ivy-switch-buffer)
  ivy-switch-buffer()
  funcall-interactively(ivy-switch-buffer)
  call-interactively(ivy-switch-buffer nil nil)
  command-execute(ivy-switch-buffer)

And the same hang will be observed - although in the above case if you
complete the buffer selection the hang goes away and the new terminal
window is usable.

>
>>
>> Andreas.


--
Alex Bennée

Re: Terminal locked when spawning a new tty frame

[rrandresf]

Hi Alex.

I have not been able of reproducing this with "emacs
-Q". That's the reason I have not been able of reporting this bug.

Having said that. I have a workaround. But I have two scenaries when this happens.

Scenary One:
When working on another workstation through ssh -Y user@host (X
forwarding). And closing the emacs session on the remote workstation.

In this case I just need to go to the local emacs session and kill the
*Backtrace* buffer. I have created an alias for It.


Scenary Two:
On the same machine I mix tty's, virtual tty's and X windows. This is
your case. My workaround on this case is opening a new emacs graphical
session (emacsclient -c -n). And from that session call
"close-display-connection". Before that (long time ago). Restart was a
terrible option.

Best Regards

Re: Terminal locked when spawning a new tty frame

[Eli Zaretskii]

> From: rrandresf@gmail.com
> Date: Wed, 16 Oct 2019 15:12:07 +0000
> Cc: emacs-devel@gnu.org
> 
> I have not been able of reproducing this with "emacs
> -Q". That's the reason I have not been able of reporting this bug.

I understand where you are coming from, but this is a mistake.  It is
better to report a bug with whatever details you have, even if you
cannot reproduce it at will or in "emacs -Q".  Why? because someone
else could try reproducing it, and if successful, could then add more
details, or even debug it and solve it.

So please do report it.  If you cannot reproduce in "emacs -Q", see if
you can find the minimal .emacs that reproduces it -- if you can
afford the time necessary for dissecting your customizations.

> Scenary One:
> When working on another workstation through ssh -Y user@host (X
> forwarding). And closing the emacs session on the remote workstation.
> 
> In this case I just need to go to the local emacs session and kill the
> *Backtrace* buffer. I have created an alias for It.

It would be better to post the *Backtrace* buffer with the bug report.
It will probably tell us something important about the cause of the
problem.

opening an emacs frame on another display (was: Terminal locked when spawning a new tty frame)

[andrés ramírez]

Hi Eli.

Eli> I understand where you are coming from, but this is a mistake.
Eli> It is better to report a bug with whatever details you have, even
Eli> if you cannot reproduce it at will or in "emacs -Q".  Why?
Eli> because someone else could try reproducing it, and if successful,
Eli> could then add more details, or even debug it and solve it.

Eli> So please do report it.  If you cannot reproduce in "emacs -Q",
Eli> see if you can find the minimal .emacs that reproduces it -- if
Eli> you can afford the time necessary for dissecting your
Eli> customizations.


Eli> It would be better to post the *Backtrace* buffer with the bug
Eli> report.  It will probably tell us something important about the
Eli> cause of the problem.

The *Backtrace* is very short:
--8<---------------cut here---------------start------------->8---
Debugger entered--Lisp error: (error "Connection lost to X server 'localhost:10.0'")
--8<---------------cut here---------------end--------------->8---

Best Regards

Re: opening an emacs frame on another display (was: Terminal locked when spawning a new tty frame)

[Eli Zaretskii]

> From: andrés ramírez <rrandresf@gmail.com>
> Date: Thu, 17 Oct 2019 04:47:15 +0000
> Cc: alex.bennee@linaro.org, emacs-devel@gnu.org
> 
> The *Backtrace* is very short:
> --8<---------------cut here---------------start------------->8---
> Debugger entered--Lisp error: (error "Connection lost to X server 'localhost:10.0'")
> --8<---------------cut here---------------end--------------->8---

Thanks, I think this adds important information.