GNU bug report logs - #17170
24.3.50; debug: Terminal 3 is locked, cannot read from it

Previous Next

To add a comment to this bug, you must first unarchive it, by sending
a message to control AT debbugs.gnu.org, with unarchive 17170 in the body.
You can then email your comments to 17170 AT debbugs.gnu.org in the normal way.

Toggle the display of automated, internal messages from the tracker.

Message #5 received at submit <at> debbugs.gnu.org (full text, mbox):

From: Nicolas Richard <theonewiththeevillook <at> yahoo.fr>
To: bug-gnu-emacs <at> gnu.org
Subject: 24.3.50; debug: Terminal 3 is locked, cannot read from it
Date: Wed, 02 Apr 2014 13:03:29 +0200

I got the following error message
debug: Terminal 3 is locked, cannot read from it

It has already happened to me but I cannot reproduce. This however only
happeend to me in a situation where emacs is run (with -nw option) from
gdb which is run from tmux and I connect to that through ssh and
emacsclient.

In this specific occurrence of the problem, that initial frame was
active (on the host computer) but I was connecting to the emacs session
from ssh via emacsclient. There was a third frame also, a graphical one,
on the host computer.

If I hit ESC ESC ESC, I get the error message again and enter a new
level of recursive edit (i.e. another layer of brackets in the
modeline). I can't escape those : C-] just makes also the error again +
another level of recursive edit.

Any idea on how to debug this further ?

Thanks.

In GNU Emacs 24.3.50.7 (i686-pc-linux-gnu, X toolkit, Xaw3d scroll bars)
 of 2014-03-27 on geodiff-mac3
Windowing system distributor `The X.Org Foundation', version 11.0.11304000
System Description:	Gentoo Base System release 2.2

Configured using:
 `configure --with-x-toolkit=lucid 'CFLAGS= -O0 -g3''

Important settings:
  value of $LANG: fr_FR.UTF-8
  locale-coding-system: utf-8-unix

Major mode: Edit Macro

Minor modes in effect:
  TeX-PDF-mode: t
  rcirc-track-minor-mode: t
  global-semanticdb-minor-mode: t
  global-semantic-idle-scheduler-mode: t
  semantic-mode: t
  yas/global-mode: t
  projectile-global-mode: t
  projectile-mode: t
  dynamic-completion-mode: t
  shell-dirtrack-mode: t
  diff-auto-refine-mode: t
  server-mode: t
  minibuffer-depth-indicate-mode: t
  show-paren-mode: t
  recentf-mode: t
  winner-mode: t
  global-discover-mode: t
  discover-mode: t
  display-time-mode: t
  override-global-mode: t
  tooltip-mode: t
  electric-indent-mode: t
  mouse-wheel-mode: t
  file-name-shadow-mode: t
  global-font-lock-mode: t
  font-lock-mode: t
  auto-composition-mode: t
  auto-encryption-mode: t
  auto-compression-mode: t
  column-number-mode: t
  line-number-mode: t
  transient-mark-mode: t

Recent input:
<down> <down> C-x C-s c M-x g n u s <return> C-x b 
<return> <C-home> C-x C-s C-c C-c y g <up> <down> q 
y C-c C-SPC C-z C-x b B B <return> C-x b b <backspace> 
B B Q C-g ESC [ > 1 ; 3 4 0 6 ; 0 c C-c C-c C-@ C-c 
C-@ C-u C-c C-@ ESC x C-g ESC x r c i r c RET ESC x 
g n u s RET C-n C-p RET RET , , C-p RET C-c C-@ C-c 
C-@ C-c C-@ C-c C-@ C-c C-@ C-c C-s C-x 1 C-l C-l ESC 
x g n u s RET RET q RET RET k q RET q C-n q y ESC < 
ESC > C-x b # e m RET ESC < ESC > C-c C-@ C-c C-@ C-c 
C-@ ESC < C-x K C-c C-@ ESC > C-x K ESC x ESC l o c 
a t e RET d e n i s RET C-s p d f C-n C-n C-n ESC x 
ESC O A RET d b o n h e RET C-x 1 C-n C-n C-n C-n C-n 
C-n C-n C-n C-n C-n C-n C-n C-n C-p C-p C-p C-p C-p 
C-x K C-x C-c C-g C-x C-c C-g C-x ESC O C C-p C-p C-p 
C-p C-n C-n C-p C-o C-n C-c C-e d o c u TAB RET RET 
C-h l C-x C-k e C-h l ESC > C-@ C-p C-p C-p C-p C-p 
C-p C-p C-p C-p C-p C-p C-p C-p C-p C-p C-p C-p C-p 
C-p C-p C-p C-p C-p C-p C-p C-p C-p C-p C-p C-p C-p 
C-p C-g ESC x r e p o r t SPC e m TAB SPC b u DEL DEL 
DEL TAB RET

Recent messages:
Mark set [6 times]
Mark saved where search started
Quit [2 times]
Beginning of buffer [3 times]
Sorting environment...
Removing duplicates... done
Entering debugger...
debug: Terminal 3 is locked, cannot read from it
Type C-x 1 to delete the help window.
Formatting keyboard macro...done

Load-path shadows:
/home/youngfrog/.emacs.d/elpa/magit-20140213.1249/magit-blame hides ~/sources/magit/magit-blame
/home/youngfrog/.emacs.d/elpa/magit-20140213.1249/magit-key-mode hides ~/sources/magit/magit-key-mode
/home/youngfrog/.emacs.d/elpa/magit-20140213.1249/magit-pkg hides ~/sources/magit/magit-pkg
/home/youngfrog/.emacs.d/elpa/magit-20140213.1249/magit-wip hides ~/sources/magit/magit-wip
/home/youngfrog/.emacs.d/elpa/git-commit-mode-20140125.1553/git-commit-mode hides ~/sources/magit/git-commit-mode
/home/youngfrog/.emacs.d/elpa/magit-20140213.1249/magit-autoloads hides ~/sources/magit/magit-autoloads
/home/youngfrog/.emacs.d/elpa/magit-20140213.1249/magit hides ~/sources/magit/magit
/home/youngfrog/.emacs.d/elpa/git-rebase-mode-20140125.1553/git-rebase-mode hides ~/sources/magit/git-rebase-mode
~/.emacs.d/lisp/asy-mode hides /usr/local/texlive/2012/texmf/asymptote/asy-mode
~/sources/org-mode/lisp/org-footnote hides /home/youngfrog/sources/running-emacs/lisp/org/org-footnote
~/sources/org-mode/lisp/ob-asymptote hides /home/youngfrog/sources/running-emacs/lisp/org/ob-asymptote
~/sources/org-mode/lisp/ob-sqlite hides /home/youngfrog/sources/running-emacs/lisp/org/ob-sqlite
~/sources/org-mode/lisp/ob-ditaa hides /home/youngfrog/sources/running-emacs/lisp/org/ob-ditaa
~/sources/org-mode/lisp/org-protocol hides /home/youngfrog/sources/running-emacs/lisp/org/org-protocol
~/sources/org-mode/lisp/ox-beamer hides /home/youngfrog/sources/running-emacs/lisp/org/ox-beamer
~/sources/org-mode/lisp/org-irc hides /home/youngfrog/sources/running-emacs/lisp/org/org-irc
~/sources/org-mode/lisp/ob-scheme hides /home/youngfrog/sources/running-emacs/lisp/org/ob-scheme
~/sources/org-mode/lisp/org-capture hides /home/youngfrog/sources/running-emacs/lisp/org/org-capture
~/sources/org-mode/lisp/ob-plantuml hides /home/youngfrog/sources/running-emacs/lisp/org/ob-plantuml
~/sources/org-mode/lisp/ox-html hides /home/youngfrog/sources/running-emacs/lisp/org/ox-html
~/sources/org-mode/lisp/org-table hides /home/youngfrog/sources/running-emacs/lisp/org/org-table
~/sources/org-mode/lisp/ob-eval hides /home/youngfrog/sources/running-emacs/lisp/org/ob-eval
~/sources/org-mode/lisp/ob-exp hides /home/youngfrog/sources/running-emacs/lisp/org/ob-exp
~/sources/org-mode/lisp/org-eshell hides /home/youngfrog/sources/running-emacs/lisp/org/org-eshell
~/sources/org-mode/lisp/ob-sql hides /home/youngfrog/sources/running-emacs/lisp/org/ob-sql
~/sources/org-mode/lisp/org-colview hides /home/youngfrog/sources/running-emacs/lisp/org/org-colview
~/sources/org-mode/lisp/ox-publish hides /home/youngfrog/sources/running-emacs/lisp/org/ox-publish
~/sources/org-mode/lisp/ob-comint hides /home/youngfrog/sources/running-emacs/lisp/org/ob-comint
~/sources/org-mode/lisp/org-element hides /home/youngfrog/sources/running-emacs/lisp/org/org-element
~/sources/org-mode/lisp/org-indent hides /home/youngfrog/sources/running-emacs/lisp/org/org-indent
~/sources/org-mode/lisp/ob-sass hides /home/youngfrog/sources/running-emacs/lisp/org/ob-sass
~/sources/org-mode/lisp/org-compat hides /home/youngfrog/sources/running-emacs/lisp/org/org-compat
~/sources/org-mode/lisp/org-list hides /home/youngfrog/sources/running-emacs/lisp/org/org-list
~/sources/org-mode/lisp/ox hides /home/youngfrog/sources/running-emacs/lisp/org/ox
~/sources/org-mode/lisp/ob-mscgen hides /home/youngfrog/sources/running-emacs/lisp/org/ob-mscgen
~/sources/org-mode/lisp/ob-keys hides /home/youngfrog/sources/running-emacs/lisp/org/ob-keys
~/sources/org-mode/lisp/org-info hides /home/youngfrog/sources/running-emacs/lisp/org/org-info
~/sources/org-mode/lisp/org-ctags hides /home/youngfrog/sources/running-emacs/lisp/org/org-ctags
~/sources/org-mode/lisp/org-habit hides /home/youngfrog/sources/running-emacs/lisp/org/org-habit
~/sources/org-mode/lisp/org-datetree hides /home/youngfrog/sources/running-emacs/lisp/org/org-datetree
~/sources/org-mode/lisp/ox-texinfo hides /home/youngfrog/sources/running-emacs/lisp/org/ox-texinfo
~/sources/org-mode/lisp/org-clock hides /home/youngfrog/sources/running-emacs/lisp/org/org-clock
~/sources/org-mode/lisp/org-bbdb hides /home/youngfrog/sources/running-emacs/lisp/org/org-bbdb
~/sources/org-mode/lisp/ob-maxima hides /home/youngfrog/sources/running-emacs/lisp/org/ob-maxima
~/sources/org-mode/lisp/ob-fortran hides /home/youngfrog/sources/running-emacs/lisp/org/ob-fortran
~/sources/org-mode/lisp/ob-picolisp hides /home/youngfrog/sources/running-emacs/lisp/org/ob-picolisp
~/sources/org-mode/lisp/ob-java hides /home/youngfrog/sources/running-emacs/lisp/org/ob-java
~/sources/org-mode/lisp/ox-icalendar hides /home/youngfrog/sources/running-emacs/lisp/org/ox-icalendar
~/sources/org-mode/lisp/org-gnus hides /home/youngfrog/sources/running-emacs/lisp/org/org-gnus
~/sources/org-mode/lisp/ob-table hides /home/youngfrog/sources/running-emacs/lisp/org/ob-table
~/sources/org-mode/lisp/ob-ocaml hides /home/youngfrog/sources/running-emacs/lisp/org/ob-ocaml
~/sources/org-mode/lisp/ob-tangle hides /home/youngfrog/sources/running-emacs/lisp/org/ob-tangle
~/sources/org-mode/lisp/ox-md hides /home/youngfrog/sources/running-emacs/lisp/org/ox-md
~/sources/org-mode/lisp/org-install hides /home/youngfrog/sources/running-emacs/lisp/org/org-install
~/sources/org-mode/lisp/ob-org hides /home/youngfrog/sources/running-emacs/lisp/org/ob-org
~/sources/org-mode/lisp/org-docview hides /home/youngfrog/sources/running-emacs/lisp/org/org-docview
~/sources/org-mode/lisp/org-timer hides /home/youngfrog/sources/running-emacs/lisp/org/org-timer
~/sources/org-mode/lisp/ob-makefile hides /home/youngfrog/sources/running-emacs/lisp/org/ob-makefile
~/sources/org-mode/lisp/ob-calc hides /home/youngfrog/sources/running-emacs/lisp/org/ob-calc
~/sources/org-mode/lisp/org-rmail hides /home/youngfrog/sources/running-emacs/lisp/org/org-rmail
~/sources/org-mode/lisp/org-plot hides /home/youngfrog/sources/running-emacs/lisp/org/org-plot
~/sources/org-mode/lisp/ob-haskell hides /home/youngfrog/sources/running-emacs/lisp/org/ob-haskell
~/sources/org-mode/lisp/ob-shen hides /home/youngfrog/sources/running-emacs/lisp/org/ob-shen
~/sources/org-mode/lisp/ox-latex hides /home/youngfrog/sources/running-emacs/lisp/org/ox-latex
~/sources/org-mode/lisp/org-mhe hides /home/youngfrog/sources/running-emacs/lisp/org/org-mhe
~/sources/org-mode/lisp/org-pcomplete hides /home/youngfrog/sources/running-emacs/lisp/org/org-pcomplete
~/sources/org-mode/lisp/org-mouse hides /home/youngfrog/sources/running-emacs/lisp/org/org-mouse
~/sources/org-mode/lisp/ox-man hides /home/youngfrog/sources/running-emacs/lisp/org/ox-man
~/sources/org-mode/lisp/org-archive hides /home/youngfrog/sources/running-emacs/lisp/org/org-archive
~/sources/org-mode/lisp/ox-ascii hides /home/youngfrog/sources/running-emacs/lisp/org/ox-ascii
~/sources/org-mode/lisp/ob-python hides /home/youngfrog/sources/running-emacs/lisp/org/ob-python
~/sources/org-mode/lisp/ox-org hides /home/youngfrog/sources/running-emacs/lisp/org/ox-org
~/sources/org-mode/lisp/ob-gnuplot hides /home/youngfrog/sources/running-emacs/lisp/org/ob-gnuplot
~/sources/org-mode/lisp/org-agenda hides /home/youngfrog/sources/running-emacs/lisp/org/org-agenda
~/sources/org-mode/lisp/ob-core hides /home/youngfrog/sources/running-emacs/lisp/org/ob-core
~/sources/org-mode/lisp/ob-perl hides /home/youngfrog/sources/running-emacs/lisp/org/ob-perl
~/sources/org-mode/lisp/ob-octave hides /home/youngfrog/sources/running-emacs/lisp/org/ob-octave
~/sources/org-mode/lisp/org-crypt hides /home/youngfrog/sources/running-emacs/lisp/org/org-crypt
~/sources/org-mode/lisp/org-macs hides /home/youngfrog/sources/running-emacs/lisp/org/org-macs
~/sources/org-mode/lisp/org-w3m hides /home/youngfrog/sources/running-emacs/lisp/org/org-w3m
~/sources/org-mode/lisp/org-feed hides /home/youngfrog/sources/running-emacs/lisp/org/org-feed
~/sources/org-mode/lisp/org-mobile hides /home/youngfrog/sources/running-emacs/lisp/org/org-mobile
~/sources/org-mode/lisp/org-version hides /home/youngfrog/sources/running-emacs/lisp/org/org-version
~/sources/org-mode/lisp/ob-ledger hides /home/youngfrog/sources/running-emacs/lisp/org/ob-ledger
~/sources/org-mode/lisp/org-inlinetask hides /home/youngfrog/sources/running-emacs/lisp/org/org-inlinetask
~/sources/org-mode/lisp/ob-latex hides /home/youngfrog/sources/running-emacs/lisp/org/ob-latex
~/sources/org-mode/lisp/ob-dot hides /home/youngfrog/sources/running-emacs/lisp/org/ob-dot
~/sources/org-mode/lisp/ob-screen hides /home/youngfrog/sources/running-emacs/lisp/org/ob-screen
~/sources/org-mode/lisp/org-src hides /home/youngfrog/sources/running-emacs/lisp/org/org-src
~/sources/org-mode/lisp/ob-ruby hides /home/youngfrog/sources/running-emacs/lisp/org/ob-ruby
~/sources/org-mode/lisp/org-macro hides /home/youngfrog/sources/running-emacs/lisp/org/org-macro
~/sources/org-mode/lisp/ob hides /home/youngfrog/sources/running-emacs/lisp/org/ob
~/sources/org-mode/lisp/ob-io hides /home/youngfrog/sources/running-emacs/lisp/org/ob-io
~/sources/org-mode/lisp/ob-matlab hides /home/youngfrog/sources/running-emacs/lisp/org/ob-matlab
~/sources/org-mode/lisp/ob-ref hides /home/youngfrog/sources/running-emacs/lisp/org/ob-ref
~/sources/org-mode/lisp/org-bibtex hides /home/youngfrog/sources/running-emacs/lisp/org/org-bibtex
~/sources/org-mode/lisp/org-entities hides /home/youngfrog/sources/running-emacs/lisp/org/org-entities
~/sources/org-mode/lisp/org hides /home/youngfrog/sources/running-emacs/lisp/org/org
~/sources/org-mode/lisp/ob-R hides /home/youngfrog/sources/running-emacs/lisp/org/ob-R
~/sources/org-mode/lisp/ob-C hides /home/youngfrog/sources/running-emacs/lisp/org/ob-C
~/sources/org-mode/lisp/ob-lob hides /home/youngfrog/sources/running-emacs/lisp/org/ob-lob
~/sources/org-mode/lisp/ob-awk hides /home/youngfrog/sources/running-emacs/lisp/org/ob-awk
~/sources/org-mode/lisp/ob-clojure hides /home/youngfrog/sources/running-emacs/lisp/org/ob-clojure
~/sources/org-mode/lisp/org-faces hides /home/youngfrog/sources/running-emacs/lisp/org/org-faces
~/sources/org-mode/lisp/ox-odt hides /home/youngfrog/sources/running-emacs/lisp/org/ox-odt
~/sources/org-mode/lisp/ob-css hides /home/youngfrog/sources/running-emacs/lisp/org/ob-css
~/sources/org-mode/lisp/ob-lisp hides /home/youngfrog/sources/running-emacs/lisp/org/ob-lisp
~/sources/org-mode/lisp/ob-lilypond hides /home/youngfrog/sources/running-emacs/lisp/org/ob-lilypond
~/sources/org-mode/lisp/org-attach hides /home/youngfrog/sources/running-emacs/lisp/org/org-attach
~/sources/org-mode/lisp/ob-emacs-lisp hides /home/youngfrog/sources/running-emacs/lisp/org/ob-emacs-lisp
~/sources/org-mode/lisp/ob-scala hides /home/youngfrog/sources/running-emacs/lisp/org/ob-scala
~/sources/org-mode/lisp/ob-js hides /home/youngfrog/sources/running-emacs/lisp/org/ob-js
~/sources/org-mode/lisp/org-id hides /home/youngfrog/sources/running-emacs/lisp/org/org-id
~/sources/org-mode/lisp/org-loaddefs hides /home/youngfrog/sources/running-emacs/lisp/org/org-loaddefs
/home/youngfrog/.emacs.d/elpa/tabulated-list-0/tabulated-list hides /home/youngfrog/sources/running-emacs/lisp/emacs-lisp/tabulated-list

Features:
(locate mailalias smtpmail url-queue shr-color color org-indent
org-rmail org-mhe org-irc org-info org-gnus org-docview doc-view
image-mode org-bibtex bibtex org-bbdb org-w3m url-cache debbugs-org
debbugs-gnu debbugs soap-client shadow bbdb-message emacsbug sendmail
vc-git gud reftex-dcr reftex-auc reftex reftex-vars preview prv-emacs
tex-buf font-latex latex tex-style tex dbus misearch multi-isearch
tramp-cache tramp-sh tramp tramp-compat tramp-loaddefs trampver
rcirc-color rcirc time-stamp gnus-draft flow-fill pp shr browse-url
mm-archive semantic/db-mode semantic/db semantic/idle semantic/format
ezimage semantic/tag-ls semantic/find semantic/ctxt semantic/util-modes
semantic/util semantic semantic/tag semantic/lex semantic/fw mode-local
cedet yasnippet assoc projectile pkg-info epl s completion ob-dot ob-R
ob-shell shell magit-key-mode magit view help-mode grep compile
diff-mode autorevert filenotify git-rebase-mode git-commit-mode log-edit
pcvs-util add-log sort gnus-cite mail-extr gnus-async gnus-bcklg qp
gnus-ml disp-table ffap thingatpt server nndraft nnmh nnmaildir gnutls
nnfolder parse-time bbdb-gnus bbdb-mua bbdb-com crm netrc network-stream
starttls gnus-agent gnus-srvr gnus-score score-mode nnvirtual gnus-msg
gnus-art mm-uu mml2015 mm-view mml-smime smime dig nntp gnus-cache
gnus-sum nnoo gnus-group gnus-undo nnmail mail-source gnus-start
gnus-spec gnus-int gnus-range message rfc822 mml mml-sec mm-decode
mm-bodies mm-encode mailabbrev gmm-utils mailheader gnus-win gnus
gnus-ems nnheader mail-utils xterm hideshow org-caldav icalendar
diary-lib diary-loaddefs org-id latexenc ox-latex ox-icalendar ox-html
ox-ascii ox-publish ox org-element avl-tree url-dav url-http url-auth
mail-parse rfc2231 rfc2047 rfc2045 ietf-drums url-gw url-handlers etable
etable-selection-model etable-cell-renderer etable-table-column-model
etable-table-column etable-table-model eieio-base interval-list dash
helm-config helm-aliases bbdb bbdb-site timezone yf-asy preview-latex
mb-depth icomplete autoinsert hippie-exp warnings ert ewoc debug
jka-compr paredit windmove paren dired recentf tree-widget wid-edit
org-inlinetask winner ampc-autoloads nlinum-autoloads info
sicp-autoloads finder-inf w3-autoloads workspaces-autoloads
wtf-autoloads pcase discover makey-key-mode twittering-mode edmacro
kmacro epa derived epg epg-config tls cl-macs gv url url-proxy
url-privacy url-expand url-methods url-history url-cookie url-domsuf
url-util url-parse auth-source eieio eieio-core gnus-util mm-util
mail-prsvr password-cache url-vars mailcap xml cl cl-loaddefs cl-lib
time cus-start cus-load two-mode-mode tex-site auto-loads ido-hacks ido
org byte-opt advice help-fns org-macro org-footnote org-pcomplete
pcomplete org-list org-faces org-entities time-date noutline outline
org-version ob-emacs-lisp ob ob-tangle org-src ob-ref ob-lob ob-table
ob-keys ob-exp ob-comint comint ansi-color ring ob-core ob-eval
org-compat org-macs org-loaddefs format-spec find-func cal-menu easymenu
calendar cal-loaddefs package use-package bytecomp byte-compile cconv
bind-key easy-mmode tooltip electric uniquify ediff-hook vc-hooks
lisp-float-type mwheel x-win x-dnd tool-bar dnd fontset image regexp-opt
fringe tabulated-list newcomment lisp-mode prog-mode register page
menu-bar rfn-eshadow timer select scroll-bar mouse jit-lock font-lock
syntax facemenu font-core frame cham georgian utf-8-lang misc-lang
vietnamese tibetan thai tai-viet lao korean japanese hebrew greek
romanian slovak czech european ethiopic indian cyrillic chinese
case-table epa-hook jka-cmpr-hook help simple abbrev minibuffer nadvice
loaddefs button faces cus-face macroexp files text-properties overlay
sha1 md5 base64 format env code-pages mule custom widget
hashtable-print-readable backquote make-network-process dbusbind
gfilenotify dynamic-setting system-font-setting font-render-setting
x-toolkit x multi-tty emacs)

Memory information:
((conses 8 656834 83083)
 (symbols 24 62271 512)
 (miscs 20 1962 2817)
 (strings 16 152979 30540)
 (string-bytes 1 4975562)
 (vectors 8 55728)
 (vector-slots 4 979444 32758)
 (floats 8 895 956)
 (intervals 28 12031 1103)
 (buffers 512 136)
 (heap 1024 26255 7094))

-- 
Nico.

Message #8 received at 17170 <at> debbugs.gnu.org (full text, mbox):

From: Eli Zaretskii <eliz <at> gnu.org>
To: Nicolas Richard <theonewiththeevillook <at> yahoo.fr>
Cc: 17170 <at> debbugs.gnu.org
Subject: Re: bug#17170: 24.3.50;
 debug: Terminal 3 is locked, cannot read from it
Date: Wed, 02 Apr 2014 19:26:20 +0300

> From: Nicolas Richard <theonewiththeevillook <at> yahoo.fr>
> Date: Wed, 02 Apr 2014 13:03:29 +0200
> 
> I got the following error message
> debug: Terminal 3 is locked, cannot read from it

This comes from keyboard.c, see the commentary there for details.

> It has already happened to me but I cannot reproduce.

Please try "C-h l" next time, and report the commands that cause this.

> This however only happeend to me in a situation where emacs is run
> (with -nw option) from gdb which is run from tmux and I connect to
> that through ssh and emacsclient.

Perhaps tmux tricks Emacs into some strange situation.

> In this specific occurrence of the problem, that initial frame was
> active (on the host computer) but I was connecting to the emacs session
> from ssh via emacsclient. There was a third frame also, a graphical one,
> on the host computer.
> 
> If I hit ESC ESC ESC, I get the error message again and enter a new
> level of recursive edit (i.e. another layer of brackets in the
> modeline). I can't escape those : C-] just makes also the error again +
> another level of recursive edit.

Do you have debug-on-error set non-nil or something?

Message #11 received at 17170 <at> debbugs.gnu.org (full text, mbox):

From: Nicolas Richard <theonewiththeevillook <at> yahoo.fr>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: Nicolas Richard <theonewiththeevillook <at> yahoo.fr>, 17170 <at> debbugs.gnu.org
Subject: Re: bug#17170: 24.3.50;
 debug: Terminal 3 is locked, cannot read from it
Date: Wed, 02 Apr 2014 19:57:24 +0200

Eli Zaretskii <eliz <at> gnu.org> writes:
> This comes from keyboard.c, see the commentary there for details.

Ok, will do.

> Please try "C-h l" next time, and report the commands that cause this.

The lossage in the bug report is pretty close to the problem. It happend
while doing C-c C-e ; which calls LaTeX-environment.

I must say however that that command often triggers an error on my
system due to my setup described in bug#17132, and so my guess is that
it is the error which causes emacs to try to enter the debugger, and
only then the "Terminal locked" error appears.

> Do you have debug-on-error set non-nil or something?

It is set to t.

--
Nico.

Message #14 received at 17170 <at> debbugs.gnu.org (full text, mbox):

From: Eli Zaretskii <eliz <at> gnu.org>
To: Nicolas Richard <theonewiththeevillook <at> yahoo.fr>
Cc: theonewiththeevillook <at> yahoo.fr, 17170 <at> debbugs.gnu.org
Subject: Re: bug#17170: 24.3.50;
 debug: Terminal 3 is locked, cannot read from it
Date: Wed, 02 Apr 2014 23:22:08 +0300

> From: Nicolas Richard <theonewiththeevillook <at> yahoo.fr>
> Cc: Nicolas Richard <theonewiththeevillook <at> yahoo.fr>,  17170 <at> debbugs.gnu.org
> Date: Wed, 02 Apr 2014 19:57:24 +0200
> 
> > Do you have debug-on-error set non-nil or something?
> 
> It is set to t.

I'm guessing that keeping it at nil will allow you to continue from
that error, instead of being stuck in an endless loop of recursive
editing.

Message #17 received at 17170 <at> debbugs.gnu.org (full text, mbox):

From: Nicolas Richard <theonewiththeevillook <at> yahoo.fr>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: 17170 <at> debbugs.gnu.org
Subject: Re: bug#17170: 24.3.50; debug: Terminal 3 is locked, cannot read
 from it
Date: Thu, 03 Apr 2014 09:16:31 +0200

Le 02/04/2014 22:22, Eli Zaretskii a écrit :
> I'm guessing that keeping it at nil will allow you to continue from
> that error, instead of being stuck in an endless loop of recursive
> editing.

Indeed. Now if I do C-], I  get "No catch for tag: exit"

-- 
Nico.

Message #20 received at 17170 <at> debbugs.gnu.org (full text, mbox):

From: Nicolas Richard <theonewiththeevillook <at> yahoo.fr>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: Nicolas Richard <theonewiththeevillook <at> yahoo.fr>, 17170 <at> debbugs.gnu.org
Subject: Re: bug#17170: 24.3.50;
 debug: Terminal 3 is locked, cannot read from it
Date: Sun, 06 Apr 2014 12:08:31 +0200

Eli Zaretskii <eliz <at> gnu.org> writes:
> Please try "C-h l" next time, and report the commands that cause this.

It just happened again. Again, I'm in emacs -nw through gdb through tmux
through ssh. Again, I apparently have left one GUI frame open on my
remote box.

When I saw the error, I did:
C-x C-k e		;; edit-kbd-macro
C-h l			;; view-lossage

The output isn't very interesting because most command names are wrong
(everytime I hit an arrow key, it reports "ESC O" then one of A B C D
separately), but here's the last bits :

C-c NUL			;; rcirc-next-active-buffer
C-x K
C-u C-u C-c NUL		;; rcirc-next-active-buffer
C-z			;; suspend-frame
C-x C-k e		;; edit-kbd-macro
C-h l			;; view-lossage

The error appeared when I did C-z for suspend-frame. "C-x K" kills
current buffer.

Note that suspend-frame makes an error:
x-win-suspend-error: Cannot suspend Emacs while running under X

If I do M-: (debug) RET, I get the "Terminal locked" message, and enter
another level of recursive edit and can't exit it (because of "No catch
for tag: exit").

At this moment I have three pairs of brackets in the modeline.

Now, I deleted the distant graphical frame (with (delete-frame (car
(frame-list))))

At this point M-: (debug) doesn't throw the terminal locked error
anymore and enter the debugger correctly (entering a 4th pair of
brackets ), and I can exit the debugger correctly too, but I'm stuck
within those 3 pairs of brackets. So it seems that the remote graphical
frame really was a problem and entered me into a weird state.

-- 
Nico.

Message #23 received at 17170 <at> debbugs.gnu.org (full text, mbox):

From: Eli Zaretskii <eliz <at> gnu.org>
To: Nicolas Richard <theonewiththeevillook <at> yahoo.fr>
Cc: 17170 <at> debbugs.gnu.org
Subject: Re: bug#17170: 24.3.50;
 debug: Terminal 3 is locked, cannot read from it
Date: Sun, 06 Apr 2014 19:25:35 +0300

> From: Nicolas Richard <theonewiththeevillook <at> yahoo.fr>
> Cc: Nicolas Richard <theonewiththeevillook <at> yahoo.fr>,  17170 <at> debbugs.gnu.org
> Date: Sun, 06 Apr 2014 12:08:31 +0200
> 
> Eli Zaretskii <eliz <at> gnu.org> writes:
> > Please try "C-h l" next time, and report the commands that cause this.
> 
> It just happened again. Again, I'm in emacs -nw through gdb through tmux
> through ssh. Again, I apparently have left one GUI frame open on my
> remote box.

I'm confused: you in "emacs -nw", but you have a GUI frame open?  How
can both of these happen in the same session?

> C-c NUL			;; rcirc-next-active-buffer
> C-x K
> C-u C-u C-c NUL		;; rcirc-next-active-buffer
> C-z			;; suspend-frame
> C-x C-k e		;; edit-kbd-macro
> C-h l			;; view-lossage
> 
> The error appeared when I did C-z for suspend-frame. "C-x K" kills
> current buffer.
> 
> Note that suspend-frame makes an error:
> x-win-suspend-error: Cannot suspend Emacs while running under X

Looks like Emacs doesn't know it has a TTY frame, and thinks you are
in a GUI frame?

> If I do M-: (debug) RET, I get the "Terminal locked" message, and enter
> another level of recursive edit and can't exit it (because of "No catch
> for tag: exit").
> 
> At this moment I have three pairs of brackets in the modeline.
> 
> Now, I deleted the distant graphical frame (with (delete-frame (car
> (frame-list))))
> 
> At this point M-: (debug) doesn't throw the terminal locked error
> anymore and enter the debugger correctly (entering a 4th pair of
> brackets ), and I can exit the debugger correctly too, but I'm stuck
> within those 3 pairs of brackets. So it seems that the remote graphical
> frame really was a problem and entered me into a weird state.

Please describe how you started the remote session, and how you got
into "emacs -nw" in the same session.  There's something I must be
missing here.

Message #26 received at 17170 <at> debbugs.gnu.org (full text, mbox):

From: Nicolas Richard <theonewiththeevillook <at> yahoo.fr>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: Nicolas Richard <theonewiththeevillook <at> yahoo.fr>, 17170 <at> debbugs.gnu.org
Subject: Re: bug#17170: 24.3.50;
 debug: Terminal 3 is locked, cannot read from it
Date: Sun, 06 Apr 2014 18:41:54 +0200

Eli Zaretskii <eliz <at> gnu.org> writes:
> Please describe how you started the remote session, and how you got
> into "emacs -nw" in the same session.  There's something I must be
> missing here.

the remote session was started by opening gnome-terminal, then doing:
$ tmux # this starts a new tmux session.
$ cd ~/path/to/emacs/src
$ gdb emacs # drops me in gdb.
(gdb) r -nw

now emacs is started. I can detach from tmux and open graphical frames
using "emacsclient -c".

When working remotely, I can either run emacsclient from ssh, or run
"tmux a" for reattaching the initial frame. The reason I do this is to
be able to reattach to the gdb session in case it takes control and I'm
working over ssh.

I hope the picture is now complete.

-- 
Nico.

Message #29 received at 17170 <at> debbugs.gnu.org (full text, mbox):

From: Eli Zaretskii <eliz <at> gnu.org>
To: Nicolas Richard <theonewiththeevillook <at> yahoo.fr>
Cc: theonewiththeevillook <at> yahoo.fr, 17170 <at> debbugs.gnu.org
Subject: Re: bug#17170: 24.3.50;
 debug: Terminal 3 is locked, cannot read from it
Date: Sun, 06 Apr 2014 20:00:43 +0300

> X-Spam-Status: No, score=0.8 required=5.0 tests=BAYES_50,FREEMAIL_FROM,
> 	RCVD_IN_DNSWL_NONE autolearn=disabled version=3.3.2
> From: Nicolas Richard <theonewiththeevillook <at> yahoo.fr>
> Cc: Nicolas Richard <theonewiththeevillook <at> yahoo.fr>,  17170 <at> debbugs.gnu.org
> Date: Sun, 06 Apr 2014 18:41:54 +0200
> 
> Eli Zaretskii <eliz <at> gnu.org> writes:
> > Please describe how you started the remote session, and how you got
> > into "emacs -nw" in the same session.  There's something I must be
> > missing here.
> 
> the remote session was started by opening gnome-terminal, then doing:
> $ tmux # this starts a new tmux session.
> $ cd ~/path/to/emacs/src
> $ gdb emacs # drops me in gdb.
> (gdb) r -nw
> 
> now emacs is started. I can detach from tmux and open graphical frames
> using "emacsclient -c".
> 
> When working remotely, I can either run emacsclient from ssh, or run
> "tmux a" for reattaching the initial frame. The reason I do this is to
> be able to reattach to the gdb session in case it takes control and I'm
> working over ssh.
> 
> I hope the picture is now complete.
> 
> -- 
> Nico.
> 

Message #32 received at 17170 <at> debbugs.gnu.org (full text, mbox):

From: Eli Zaretskii <eliz <at> gnu.org>
To: Nicolas Richard <theonewiththeevillook <at> yahoo.fr>
Cc: theonewiththeevillook <at> yahoo.fr, 17170 <at> debbugs.gnu.org
Subject: Re: bug#17170: 24.3.50;
 debug: Terminal 3 is locked, cannot read from it
Date: Sun, 06 Apr 2014 20:01:45 +0300

> From: Nicolas Richard <theonewiththeevillook <at> yahoo.fr>
> Cc: Nicolas Richard <theonewiththeevillook <at> yahoo.fr>,  17170 <at> debbugs.gnu.org
> Date: Sun, 06 Apr 2014 18:41:54 +0200
> 
> the remote session was started by opening gnome-terminal, then doing:
> $ tmux # this starts a new tmux session.
> $ cd ~/path/to/emacs/src
> $ gdb emacs # drops me in gdb.
> (gdb) r -nw
> 
> now emacs is started. I can detach from tmux and open graphical frames
> using "emacsclient -c".
> 
> When working remotely, I can either run emacsclient from ssh, or run
> "tmux a" for reattaching the initial frame. The reason I do this is to
> be able to reattach to the gdb session in case it takes control and I'm
> working over ssh.
> 
> I hope the picture is now complete.

Yes, thanks.  However, I have no idea what does this tmux use do to
Emacs.  I guess someone who does should chime in.

Message #35 received at 17170 <at> debbugs.gnu.org (full text, mbox):

From: Nicolas Richard <theonewiththeevillook <at> yahoo.fr>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: Nicolas Richard <theonewiththeevillook <at> yahoo.fr>, 17170 <at> debbugs.gnu.org
Subject: Re: bug#17170: 24.3.50;
 debug: Terminal 3 is locked, cannot read from it
Date: Wed, 07 May 2014 13:07:18 +0200

Eli Zaretskii <eliz <at> gnu.org> writes:

>> From: Nicolas Richard <theonewiththeevillook <at> yahoo.fr>
>> Cc: Nicolas Richard <theonewiththeevillook <at> yahoo.fr>,  17170 <at> debbugs.gnu.org
>> Date: Sun, 06 Apr 2014 18:41:54 +0200
>> 
>> the remote session was started by opening gnome-terminal, then doing:
>> $ tmux # this starts a new tmux session.
>> $ cd ~/path/to/emacs/src
>> $ gdb emacs # drops me in gdb.
>> (gdb) r -nw
>> 
>> now emacs is started. I can detach from tmux and open graphical frames
>> using "emacsclient -c".
>> 
>> When working remotely, I can either run emacsclient from ssh, or run
>> "tmux a" for reattaching the initial frame. The reason I do this is to
>> be able to reattach to the gdb session in case it takes control and I'm
>> working over ssh.
>> 
>> I hope the picture is now complete.
>
> Yes, thanks.  However, I have no idea what does this tmux use do to
> Emacs.  I guess someone who does should chime in.

Could it be that the patch in bug#17413 will fix this problem ?

-- 
Nico.

Message #38 received at 17170 <at> debbugs.gnu.org (full text, mbox):

From: Eli Zaretskii <eliz <at> gnu.org>
To: Nicolas Richard <theonewiththeevillook <at> yahoo.fr>
Cc: 17170 <at> debbugs.gnu.org
Subject: Re: bug#17170: 24.3.50;
 debug: Terminal 3 is locked, cannot read from it
Date: Wed, 07 May 2014 18:17:38 +0300

> From: Nicolas Richard <theonewiththeevillook <at> yahoo.fr>
> Cc: Nicolas Richard <theonewiththeevillook <at> yahoo.fr>,  17170 <at> debbugs.gnu.org
> Date: Wed, 07 May 2014 13:07:18 +0200
> 
> Could it be that the patch in bug#17413 will fix this problem ?

Why not try that?

Message #41 received at 17170 <at> debbugs.gnu.org (full text, mbox):

From: Nicolas Richard <theonewiththeevillook <at> yahoo.fr>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: 17170 <at> debbugs.gnu.org
Subject: Re: bug#17170: 24.3.50; debug: Terminal 3 is locked, cannot read
 from it
Date: Wed, 07 May 2014 17:26:24 +0200

Le 07/05/2014 17:17, Eli Zaretskii a écrit :
>> From: Nicolas Richard <theonewiththeevillook <at> yahoo.fr>
>> Cc: Nicolas Richard <theonewiththeevillook <at> yahoo.fr>,  17170 <at> debbugs.gnu.org
>> Date: Wed, 07 May 2014 13:07:18 +0200
>> 
>> Could it be that the patch in bug#17413 will fix this problem ?
> 
> Why not try that?

Because I can't reproduce my bug.

In fact I'll admit that my previous message was sent a bit hastily : I
was trying to cancel it and instead it got sent. Sorry for that noise.

-- 
Nico.

Message #44 received at 17170 <at> debbugs.gnu.org (full text, mbox):

From: Nicolas Richard <theonewiththeevillook <at> yahoo.fr>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: 17170 <at> debbugs.gnu.org
Subject: Re: bug#17170: 24.3.50; debug: Terminal 3 is locked, cannot read
 from it
Date: Fri, 20 Mar 2015 16:47:50 +0100

Le 07/05/2014 17:17, Eli Zaretskii a écrit :
>> From: Nicolas Richard <theonewiththeevillook <at> yahoo.fr>
>> Cc: Nicolas Richard <theonewiththeevillook <at> yahoo.fr>,  17170 <at> debbugs.gnu.org
>> Date: Wed, 07 May 2014 13:07:18 +0200
>> 
>> Could it be that the patch in bug#17413 will fix this problem ?
> 
> Why not try that?

I think it helped but I'm not sure.

Anyway, I still have similar problems sometimes.

In my current session I have the following configuration of frames :

(mapconcat (lambda (f)
             (format "Frame: %s\nTree: %s" f (window-tree f)))
           (frame-list)
           "\n\n")
;; =>
;; "Frame: #<frame *TABUF*<6> -- emacs <at> localhost (server) 0xfdaa5d8>
;; Tree: (#<window 552 on *TABUF*<6>> #<window 471 on  *Minibuf-0*>)

;; Frame: #<frame F1 0x87b1a30>
;; Tree: ((t (0 0 10 9) #<window 1 on *scratch*> #<window 4 on *scratch*>) #<window 2 on  *Minibuf-0*>)"


And I was facing this problem:

(debug)
;; => debug: Terminal 0 is locked, cannot read from it

;; (but at this point I'm not left in a recursive edit -- which is a change from the initial bugreport I made)

;; I did:
(setq debugger-previous-window (selected-window))

;; and it went away:
(debug)
;; works fine

So emacs sometimes tries to use the initial frame F1. That's not good because that frame doesn't really exist (it's the frame created by "emacs --daemon").

I'll appreciate any help. I guess I should somehow detect when/why emacs tries to access that initial frame, F1, but where would I hook ?

Nico.

Message #47 received at 17170 <at> debbugs.gnu.org (full text, mbox):

From: Eli Zaretskii <eliz <at> gnu.org>
To: Nicolas Richard <theonewiththeevillook <at> yahoo.fr>
Cc: 17170 <at> debbugs.gnu.org
Subject: Re: bug#17170: 24.3.50;
 debug: Terminal 3 is locked, cannot read from it
Date: Fri, 20 Mar 2015 18:42:36 +0200

> Date: Fri, 20 Mar 2015 16:47:50 +0100
> From: Nicolas Richard <theonewiththeevillook <at> yahoo.fr>
> CC: 17170 <at> debbugs.gnu.org
> 
> I'll appreciate any help. I guess I should somehow detect when/why emacs tries to access that initial frame, F1, but where would I hook ?

Hard to tell.  Can you be more specific about "access that frame"?
What kind of access are we talking about?

What happens if you delete that frame?

Message #50 received at 17170 <at> debbugs.gnu.org (full text, mbox):

From: Nicolas Richard <theonewiththeevillook <at> yahoo.fr>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: 17170 <at> debbugs.gnu.org
Subject: Re: bug#17170: 24.3.50; debug: Terminal 3 is locked, cannot read
 from it
Date: Fri, 20 Mar 2015 17:55:20 +0100

Le 20/03/2015 17:42, Eli Zaretskii a écrit :
>> Date: Fri, 20 Mar 2015 16:47:50 +0100
>> From: Nicolas Richard <theonewiththeevillook <at> yahoo.fr>
>> CC: 17170 <at> debbugs.gnu.org
>> 
>> I'll appreciate any help. I guess I should somehow detect when/why emacs tries to access that initial frame, F1, but where would I hook ?
> 
> Hard to tell.  Can you be more specific about "access that frame"?
> What kind of access are we talking about?

IMO that frame should not ever be used for displaying a buffer, so if emacs ever tries to do that, I want to know why it does it.

> What happens if you delete that frame?

I did (delete-frame (cadr (frame-list))), and now I can't delete my GUI frame anymore : if I do "C-x C-c", emacs asks me if I want to exit emacs. If I do C-x 5 0, I get:
Debugger entered--Lisp error: (error "Attempt to delete the sole visible or iconified frame")

Nicolas.

Message #53 received at 17170 <at> debbugs.gnu.org (full text, mbox):

From: Eli Zaretskii <eliz <at> gnu.org>
To: Nicolas Richard <theonewiththeevillook <at> yahoo.fr>
Cc: 17170 <at> debbugs.gnu.org
Subject: Re: bug#17170: 24.3.50;
 debug: Terminal 3 is locked, cannot read from it
Date: Fri, 20 Mar 2015 19:47:21 +0200

> Date: Fri, 20 Mar 2015 17:55:20 +0100
> From: Nicolas Richard <theonewiththeevillook <at> yahoo.fr>
> CC: 17170 <at> debbugs.gnu.org
> 
> Le 20/03/2015 17:42, Eli Zaretskii a écrit :
> >> Date: Fri, 20 Mar 2015 16:47:50 +0100
> >> From: Nicolas Richard <theonewiththeevillook <at> yahoo.fr>
> >> CC: 17170 <at> debbugs.gnu.org
> >> 
> >> I'll appreciate any help. I guess I should somehow detect when/why emacs tries to access that initial frame, F1, but where would I hook ?
> > 
> > Hard to tell.  Can you be more specific about "access that frame"?
> > What kind of access are we talking about?
> 
> IMO that frame should not ever be used for displaying a buffer

Why not?  Isn't it just a regular frame?

> > What happens if you delete that frame?
> 
> I did (delete-frame (cadr (frame-list))), and now I can't delete my GUI frame anymore : if I do "C-x C-c", emacs asks me if I want to exit emacs. If I do C-x 5 0, I get:
> Debugger entered--Lisp error: (error "Attempt to delete the sole visible or iconified frame")

That's expected, but the question is does the problem go away?

Message #56 received at 17170 <at> debbugs.gnu.org (full text, mbox):

From: Nicolas Richard <theonewiththeevillook <at> yahoo.fr>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: Nicolas Richard <theonewiththeevillook <at> yahoo.fr>, 17170 <at> debbugs.gnu.org
Subject: Re: bug#17170: 24.3.50;
 debug: Terminal 3 is locked, cannot read from it
Date: Fri, 20 Mar 2015 19:37:54 +0100

Eli Zaretskii <eliz <at> gnu.org> writes:
>> From: Nicolas Richard <theonewiththeevillook <at> yahoo.fr>
>> IMO that frame should not ever be used for displaying a buffer
>
> Why not?  Isn't it just a regular frame?

No : I never see it. IIUC running "emacs --daemon" creates that frame
but it is never shown to me.

>> > What happens if you delete that frame?
>> 
>> I did (delete-frame (cadr (frame-list))), and now I can't delete my
>> GUI frame anymore : if I do "C-x C-c", emacs asks me if I want to
>> exit emacs. If I do C-x 5 0, I get:
>> Debugger entered--Lisp error: (error "Attempt to delete the sole visible or iconified frame")
>
> That's expected, but the question is does the problem go away?

The problem was already gone after changing debugger-previous-window.

-- 
Nicolas

Message #59 received at 17170 <at> debbugs.gnu.org (full text, mbox):

From: martin rudalics <rudalics <at> gmx.at>
To: Nicolas Richard <theonewiththeevillook <at> yahoo.fr>, 
 Eli Zaretskii <eliz <at> gnu.org>
Cc: 17170 <at> debbugs.gnu.org
Subject: Re: bug#17170: 24.3.50; debug: Terminal 3 is locked, cannot read
 from it
Date: Fri, 20 Mar 2015 20:54:11 +0100

> ;; I did:
> (setq debugger-previous-window (selected-window))
>
> ;; and it went away:
> (debug)
> ;; works fine
>
> So emacs sometimes tries to use the initial frame F1. That's not good because that frame doesn't really exist (it's the frame created by "emacs --daemon").

When it happens again please tell me the value of
`debugger-previous-window'.  AFAICT this can only happen when that
window was shown on the "initial frame F1" before.

martin

Message #62 received at 17170 <at> debbugs.gnu.org (full text, mbox):

From: Nicolas Richard <theonewiththeevillook <at> yahoo.fr>
To: martin rudalics <rudalics <at> gmx.at>
Cc: Nicolas Richard <theonewiththeevillook <at> yahoo.fr>,
 Eli Zaretskii <eliz <at> gnu.org>, 17170 <at> debbugs.gnu.org
Subject: Re: bug#17170: 24.3.50;
 debug: Terminal 3 is locked, cannot read from it
Date: Sat, 21 Mar 2015 18:46:20 +0100

Hi martin,

martin rudalics <rudalics <at> gmx.at> writes:
>> ;; I did:
>> (setq debugger-previous-window (selected-window))
>>
>> ;; and it went away:
>> (debug)
>> ;; works fine
>>
>> So emacs sometimes tries to use the initial frame F1. That's not
>> good because that frame doesn't really exist (it's the frame created
>> by "emacs --daemon").
>
> When it happens again please tell me the value of
> `debugger-previous-window'.  AFAICT this can only happen when that
> window was shown on the "initial frame F1" before.

Yes it was a window on that frame (window 4 IIRC). I remember that
because this is the reason I did
    (setq debugger-previous-window (selected-window))
to bring the debugger back to my frame.

-- 
Nicolas.

Message #65 received at 17170 <at> debbugs.gnu.org (full text, mbox):

From: martin rudalics <rudalics <at> gmx.at>
To: Nicolas Richard <theonewiththeevillook <at> yahoo.fr>
Cc: Eli Zaretskii <eliz <at> gnu.org>, 17170 <at> debbugs.gnu.org
Subject: Re: bug#17170: 24.3.50; debug: Terminal 3 is locked, cannot read
 from it
Date: Sun, 22 Mar 2015 13:05:17 +0100

>> When it happens again please tell me the value of
>> `debugger-previous-window'.  AFAICT this can only happen when that
>> window was shown on the "initial frame F1" before.
>
> Yes it was a window on that frame (window 4 IIRC). I remember that
> because this is the reason I did
>      (setq debugger-previous-window (selected-window))
> to bring the debugger back to my frame.

I can't understand what happened here because the only way to set
`debugger-previous-window' is via invoking `debug' and then doing
unconditionally

(setq debugger-window (selected-window))

followed by

(setq debugger-previous-window debugger-window))

so the window must have been the selected window when `debug' was called
the last time and Emacs should have complained then already.

Anyway.  I checked in a fix for Emacs 24.5 which should avoid this
problem now.  If you want to try it immediately please apply:

--- a/lisp/emacs-lisp/debug.el
+++ b/lisp/emacs-lisp/debug.el
@@ -192,7 +192,9 @@ first will be printed into the backtrace buffer."
 	       debugger-buffer
 	       `((display-buffer-reuse-window
 		  display-buffer-in-previous-window)
-		  . (,(when debugger-previous-window
+		 . (,(when (and (window-live-p debugger-previous-window)
+				(frame-visible-p
+				 (window-frame debugger-previous-window)))
 			`(previous-window . ,debugger-previous-window)))))
 	      (setq debugger-window (selected-window))
 	      (if (eq debugger-previous-window debugger-window)

martin

Message #68 received at 17170 <at> debbugs.gnu.org (full text, mbox):

From: Nicolas Richard <theonewiththeevillook <at> yahoo.fr>
To: martin rudalics <rudalics <at> gmx.at>
Cc: Nicolas Richard <theonewiththeevillook <at> yahoo.fr>,
 Eli Zaretskii <eliz <at> gnu.org>, 17170 <at> debbugs.gnu.org
Subject: Re: bug#17170: 24.3.50;
 debug: Terminal 3 is locked, cannot read from it
Date: Sun, 22 Mar 2015 18:56:07 +0100

martin rudalics <rudalics <at> gmx.at> writes:
> so the window must have been the selected window when `debug' was called
> the last time and Emacs should have complained then already.

I didn't check the value of debugger-previous-window right after the
first complaint. I can try to do that, if it happens again, but since it
only happens in case of an error, my first reaction usually is to try
the command again (because I assume I made an error myself) and then
it's too late.

> Anyway.  I checked in a fix for Emacs 24.5 which should avoid this
> problem now.  If you want to try it immediately please apply:

Thanks.

-- 
Nicolas

Message #71 received at 17170 <at> debbugs.gnu.org (full text, mbox):

From: Lars Ingebrigtsen <larsi <at> gnus.org>
To: Nicolas Richard <theonewiththeevillook <at> yahoo.fr>
Cc: martin rudalics <rudalics <at> gmx.at>, Eli Zaretskii <eliz <at> gnu.org>,
 17170 <at> debbugs.gnu.org
Subject: Re: bug#17170: 24.3.50;
 debug: Terminal 3 is locked, cannot read from it
Date: Sat, 26 Dec 2015 15:08:29 +0100

Nicolas Richard <theonewiththeevillook <at> yahoo.fr> writes:

> martin rudalics <rudalics <at> gmx.at> writes:
>> so the window must have been the selected window when `debug' was called
>> the last time and Emacs should have complained then already.
>
> I didn't check the value of debugger-previous-window right after the
> first complaint. I can try to do that, if it happens again, but since it
> only happens in case of an error, my first reaction usually is to try
> the command again (because I assume I made an error myself) and then
> it's too late.

Are you still seeing this problem?

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

Message #76 received at 17170-done <at> debbugs.gnu.org (full text, mbox):

From: Nicolas Richard <youngfrog <at> members.fsf.org>
To: Lars Ingebrigtsen <larsi <at> gnus.org>
Cc: martin rudalics <rudalics <at> gmx.at>, Eli Zaretskii <eliz <at> gnu.org>,
 17170-done <at> debbugs.gnu.org
Subject: Re: bug#17170: 24.3.50;
 debug: Terminal 3 is locked, cannot read from it
Date: Sat, 26 Dec 2015 20:15:34 +0100

Hi,

Lars Ingebrigtsen writes:

> Nicolas Richard <theonewiththeevillook <at> yahoo.fr> writes:
>
>> martin rudalics <rudalics <at> gmx.at> writes:
>>> so the window must have been the selected window when `debug' was called
>>> the last time and Emacs should have complained then already.
>>
>> I didn't check the value of debugger-previous-window right after the
>> first complaint. I can try to do that, if it happens again, but since it
>> only happens in case of an error, my first reaction usually is to try
>> the command again (because I assume I made an error myself) and then
>> it's too late.
>
> Are you still seeing this problem?

Probably not, or I got used to it (unlikely). I close the bug for now,
thanks for your mail.

Nicolas.

Previous Next

GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.