bug#44502: 28.0.50; Emacs crash using new frame

bug#44502: 28.0.50; Emacs crash using new frame

[Andy Moreton]

Emacs crashed when using a new frame. After a bootstrap of master, I
could repeat the crash witht he following recipe:
   - Run "emacs -Q"
   - Type "C-x 5 2 RET" to create a new frame (which becomes selected)
   - Type "C-x C-f" and emacs crashes

I bisected this using the recipe above, with:
   git checkout master
   git bisect start
   git bisect bad
   git bisect good c3a20804a8

Bisect reports the bad commit as:
   2ecbf4cfae Allow minibuffer to stay in its original frame.
              (2020-11-05 Alan Mackenzie)

Looking in gdb, the backtrace is:

Thread 1 received signal SIGTRAP, Trace/breakpoint trap.
[Switching to Thread 5768.0x1dd0]
0x00007ffb807493e3 in KERNELBASE!DebugBreak () from 
C:\WINDOWS\System32\KernelBase.dll
(gdb) bt
#0  0x00007ffb807493e3 in KERNELBASE!DebugBreak () from 
C:\WINDOWS\System32\KernelBase.dll
#1  0x000000040021673c in emacs_abort () at 
C:/emacs/git/emacs/master/src/w32fns.c:10832
#2  0x00000004000e9a9e in terminate_due_to_signal (sig=11, 
backtrace_limit=12553480) at C:/emacs/git/emacs/master/src/emacs.c:408
#3  0x000000040010a7bc in deliver_fatal_thread_signal () at 
C:/msys64/mingw64/x86_64-w64-mingw32/include/stdio.h:443
#4  0x00000004002a7962 in _gnu_exception_handler 
(exception_data=0xbf8dc0) at 
C:/_/M/mingw-w64-crt-git/src/mingw-w64/mingw-w64-crt/crt/crt_handler.c:223
#5  0x00007ffb80fd7ff8 in msvcrt!__C_specific_handler () from 
C:\WINDOWS\System32\msvcrt.dll
#6  0x00007ffb82cb10ef in ntdll!.chkstk () from 
C:\WINDOWS\SYSTEM32\ntdll.dll
#7  0x00007ffb82c5b474 in ntdll!RtlRaiseException () from 
C:\WINDOWS\SYSTEM32\ntdll.dll
#8  0x00007ffb82cafc1e in ntdll!KiUserExceptionDispatcher () from 
C:\WINDOWS\SYSTEM32\ntdll.dll
#9  0x0000000400245e50 in stat_worker (path=<optimized out>, 
path@entry=0x9358ae0 "c:/home/ajm/.emacs.d/gnus/.newsrc-dribble", 
buf=buf@entry=0xbfa910, follow_symlinks=13303808, 
follow_symlinks@entry=1) at C:/emacs/git/emacs/master/src/w32.c:5441
#10 0x00000004002466df in fstatat (fd=fd@entry=-3041965, 
name=name@entry=0x9358ae0 "c:/home/ajm/.emacs.d/gnus/.newsrc-dribble", 
st=st@entry=0xbfa910, flags=flags@entry=0) at 
C:/emacs/git/emacs/master/src/w32.c:5658
#11 0x000000040010ba6d in emacs_fstatat (dirfd=dirfd@entry=-3041965, 
filename=0x9358ae0 "c:/home/ajm/.emacs.d/gnus/.newsrc-dribble", 
st=st@entry=0xbfa910, flags=flags@entry=0) at 
C:/emacs/git/emacs/master/src/sysdep.c:2300
#12 0x0000000400134f6a in auto_save_1 () at 
C:/emacs/git/emacs/master/src/lisp.h:1508
#13 0x0000000400185f5d in internal_condition_case 
(bfun=bfun@entry=0x400134ec0 <auto_save_1>, handlers=<optimized out>, 
hfun=hfun@entry=0x400129430 <auto_save_error>) at 
C:/emacs/git/emacs/master/src/eval.c:1359
#14 0x0000000400132a40 in Fdo_auto_save 
(no_message=no_message@entry=XIL(0x30), 
current_only=current_only@entry=XIL(0)) at 
C:/emacs/git/emacs/master/src/lisp.h:1007
#15 0x00000004000e9919 in shut_down_emacs (sig=sig@entry=22, 
stuff=XIL(0)) at C:/emacs/git/emacs/master/src/lisp.h:1007
#16 0x00000004000e9ad1 in terminate_due_to_signal (sig=22, 
backtrace_limit=2147483647) at C:/emacs/git/emacs/master/src/lisp.h:1007
#17 0x0000000400156e04 in die (msg=0x4006c2a42 <null_glyph_slice+3762> 
"EQ (window, selected_window)", file=0x4006c24b0 <null_glyph_slice+2336> 
"C:/emacs/git/emacs/master/src/window.c", line=554) at 
C:/emacs/git/emacs/master/src/alloc.c:7341
#18 0x000000040007f2c2 in select_window (window=XIL(0x5127715), 
norecord=norecord@entry=XIL(0x30), 
inhibit_point_swap=inhibit_point_swap@entry=false) at 
C:/emacs/git/emacs/master/src/lisp.h:1373
#19 0x000000040007f2d8 in Fselect_window (window=<optimized out>, 
norecord=norecord@entry=XIL(0x30)) at 
C:/emacs/git/emacs/master/src/window.c:630
#20 0x000000040004c588 in gui_consider_frame_title 
(frame=XIL(0x51274c5)) at C:/emacs/git/emacs/master/src/lisp.h:1007
#21 0x000000040005c41d in prepare_menu_bars () at 
C:/emacs/git/emacs/master/src/xdisp.c:12679
#22 redisplay_internal () at C:/emacs/git/emacs/master/src/xdisp.c:15575
#23 0x000000040005e365 in redisplay () at 
C:/emacs/git/emacs/master/src/xdisp.c:15159
#24 0x00000004000f9af6 in read_char (commandflag=1601537, map=XIL(0), 
map@entry=XIL(0x9c4dc23), prev_event=XIL(0x172a2c), used_mouse_menu=0x1, 
used_mouse_menu@entry=0xbfdb0b, end_time=end_time@entry=0x0) at 
C:/emacs/git/emacs/master/src/keyboard.c:2497
#25 0x00000004000fcc41 in read_key_sequence 
(keybuf=keybuf@entry=0xbfdc80, prompt=prompt@entry=XIL(0), 
dont_downcase_last=dont_downcase_last@entry=false, 
can_return_switch_frame=can_return_switch_frame@entry=true, 
fix_current_buffer=fix_current_buffer@entry=true, 
prevent_redisplay=prevent_redisplay@entry=false) at 
C:/emacs/git/emacs/master/src/keyboard.c:9546
#26 0x00000004000fe44f in command_loop_1 () at 
C:/emacs/git/emacs/master/src/lisp.h:1007
#27 0x0000000400185f5d in internal_condition_case 
(bfun=bfun@entry=0x4000fe230 <command_loop_1>, 
handlers=handlers@entry=XIL(0x90), hfun=hfun@entry=0x4000f36a0 
<cmd_error>) at C:/emacs/git/emacs/master/src/eval.c:1359
#28 0x00000004000eaaf8 in command_loop_2 (ignore=<optimized out>) at 
C:/emacs/git/emacs/master/src/lisp.h:1007
#29 0x0000000400185e9b in internal_catch (tag=tag@entry=XIL(0x5940), 
func=func@entry=0x4000eaad0 <command_loop_2>, arg=arg@entry=XIL(0)) at 
C:/emacs/git/emacs/master/src/eval.c:1120
#30 0x00000004000eb752 in command_loop () at 
C:/emacs/git/emacs/master/src/lisp.h:1007
#31 0x0000000000000000 in ?? ()
Backtrace stopped: previous frame inner to this frame (corrupt stack?)

Lisp Backtrace:

Thread 1 hit Breakpoint 1, terminate_due_to_signal (sig=22, 
backtrace_limit=2147483647) at C:/emacs/git/emacs/master/src/emacs.c:377
377	{
The program being debugged stopped while in a function called from GDB.
Evaluation of the expression containing the function
(backtrace_function) will be abandoned.



In GNU Emacs 28.0.50 (build 11, x86_64-w64-mingw32)
  of 2020-11-07 built on QUIETUS
Repository revision: bc76afd355c0a6608830e2b43c8c67243aa0fa7b
Repository branch: master
Windowing system distributor 'Microsoft Corp.', version 10.0.19041
System Description: Microsoft Windows 10 Pro (v10.0.2004.19041.572)

Configured using:
  'configure --prefix=/c/emacs/emacs-master
 
--cache-file=/c/emacs/git/emacs/master/build/mingw64-x86_64-O2/config.cache
  --without-dbus --with-gif --with-gnutls --without-imagemagick
  --with-jpeg --with-json --with-lcms2 --with-modules --with-png
  --without-pop --with-rsvg --with-tiff --with-xml2 --with-xpm
  --enable-checking
  'ac_cv_search___gmpz_roinit_n=-Wl,--push-state,-static -lgmp
  -Wl,--pop-state' 'CFLAGS= -O2 -g3 -gdwarf-4 -fdiagnostics-color=never'
  PKG_CONFIG_PATH=/mingw64/lib/pkgconfig:/mingw64/share/pkgconfig'

Configured features:
XPM JPEG TIFF GIF PNG RSVG SOUND NOTIFY W32NOTIFY ACL GNUTLS LIBXML2
HARFBUZZ ZLIB TOOLKIT_SCROLL_BARS MODULES THREADS JSON PDUMPER LCMS2

Important settings:
   value of $LANG: ENG
   locale-coding-system: cp1252

Major mode: ELisp/d

Minor modes in effect:
   hexl-follow-ascii: t
   bug-reference-prog-mode: t
   which-function-mode: t
   global-so-long-mode: t
   display-fill-column-indicator-mode: t
   desktop-save-mode: t
   show-paren-mode: t
   minibuffer-electric-default-mode: t
   override-global-mode: t
   tooltip-mode: t
   global-eldoc-mode: t
   eldoc-mode: t
   mouse-wheel-mode: t
   menu-bar-mode: t
   file-name-shadow-mode: t
   global-font-lock-mode: t
   font-lock-mode: t
   blink-cursor-mode: t
   auto-composition-mode: t
   auto-compression-mode: t
   column-number-mode: t
   line-number-mode: t
   transient-mark-mode: t

Load-path shadows:
None found.

Features:
(shadow sort mail-extr emacsbug message rfc822 mml mml-sec epa derived
epg epg-config gnus-util rmail rmail-loaddefs mm-decode mm-bodies
mm-encode mail-parse rfc2231 mailabbrev gmm-utils mailheader sendmail
rfc2047 rfc2045 ietf-drums mm-util mail-prsvr mail-utils add-log time
mule-util jka-compr sh-script executable dired-aux autorevert filenotify
rng-xsd xsd-regexp rng-cmpct image-mode dired-x dired dired-loaddefs
exif vc-git diff-mode macrostep-c cmacexp macrostep xcscope cap-words
superword subword time-date rnc-mode rng-nxml rng-valid rng-loc rng-uri
rng-parse nxml-parse rng-match rng-dt rng-util rng-pttrn nxml-ns
nxml-mode nxml-outln nxml-rap sgml-mode dom nxml-util nxml-enc xmltok
typescript-mode tuareg speedbar ezimage dframe tuareg-opam flymake-proc
flymake caml-help caml-types caml-emacs smalltalk-mode rust-mode
meson-mode smie lua-mode advice kconfig-mode go-mode find-file ffap
etags fileloop generator xref project csharp-mode cc-langs cc-mode
cc-fonts cc-guess cc-menus cc-cmds cc-styles cc-align cc-engine cc-vars
cc-defs cmake-mode thingatpt hexl bug-reference graphviz-dot-mode
compile text-property-search xr which-func imenu so-long
display-fill-column-indicator desktop frameset cygwin-mount ange-ftp
comint ansi-color ring hl-line pcase rx paren edmacro kmacro
use-package-bind-key use-package-delight minibuf-eldef
gnu-elpa-keyring-update warnings delight bind-key easy-mmode finder-inf
cl-extra help-mode use-package-ensure use-package-core cus-edit pp
cus-start cus-load wid-edit nsm rmc gnutls puny info package easymenu
browse-url url url-proxy url-privacy url-expand url-methods url-history
url-cookie url-domsuf url-util mailcap url-handlers url-parse
auth-source cl-seq eieio eieio-core cl-macs eieio-loaddefs
password-cache json subr-x map url-vars seq byte-opt gv bytecomp
byte-compile cconv cl-loaddefs cl-lib tooltip eldoc electric uniquify
ediff-hook vc-hooks lisp-float-type mwheel dos-w32 ls-lisp disp-table
term/w32-win w32-win w32-vars term/common-win tool-bar dnd fontset image
regexp-opt fringe tabulated-list replace newcomment text-mode elisp-mode
lisp-mode prog-mode register page tab-bar menu-bar rfn-eshadow isearch
timer select scroll-bar mouse jit-lock font-lock syntax facemenu
font-core term/tty-colors frame minibuffer cl-generic cham georgian
utf-8-lang misc-lang vietnamese tibetan thai tai-viet lao korean
japanese eucjp-ms cp51932 hebrew greek romanian slovak czech european
ethiopic indian cyrillic chinese composite charscript charprop
case-table epa-hook jka-cmpr-hook help simple abbrev obarray
cl-preloaded nadvice button loaddefs faces cus-face macroexp files
window text-properties overlay sha1 md5 base64 format env code-pages
mule custom widget hashtable-print-readable backquote threads w32notify
w32 lcms2 multi-tty make-network-process emacs)

Memory information:
((conses 16 384317 223359)
  (symbols 48 27577 428)
  (strings 32 117889 33639)
  (string-bytes 1 3236646)
  (vectors 16 40518)
  (vector-slots 8 561206 362902)
  (floats 8 89 815)
  (intervals 56 4641 630)
  (buffers 992 35))

bug#44502: 28.0.50; Emacs crash using new frame

[Andy Moreton]

On Sat 07 Nov 2020, Andy Moreton wrote:

> Emacs crashed when using a new frame. After a bootstrap of master, I
> could repeat the crash witht he following recipe:
>   - Run "emacs -Q"
>   - Type "C-x 5 2 RET" to create a new frame (which becomes selected)
>   - Type "C-x C-f" and emacs crashes
>
> I bisected this using the recipe above, with:
>   git checkout master
>   git bisect start
>   git bisect bad
>   git bisect good c3a20804a8
>
> Bisect reports the bad commit as:
>   2ecbf4cfae Allow minibuffer to stay in its original frame.
>              (2020-11-05 Alan Mackenzie)

This emacs was built with --enable-checking, so the crash is actually an
eassert in select_window (in window.c).

    AndyM

bug#44502: 28.0.50; Emacs crash using new frame

[Eli Zaretskii]

> From: Andy Moreton <andrewjmoreton@gmail.com>
> Date: Sat, 7 Nov 2020 13:27:30 +0000
> 
> Emacs crashed when using a new frame. After a bootstrap of master, I
> could repeat the crash witht he following recipe:
>    - Run "emacs -Q"
>    - Type "C-x 5 2 RET" to create a new frame (which becomes selected)
>    - Type "C-x C-f" and emacs crashes
> 
> I bisected this using the recipe above, with:
>    git checkout master
>    git bisect start
>    git bisect bad
>    git bisect good c3a20804a8
> 
> Bisect reports the bad commit as:
>    2ecbf4cfae Allow minibuffer to stay in its original frame.
>               (2020-11-05 Alan Mackenzie)

Thanks.  Yes, the above recipe causes an assertion violation.  Alan,
can you take a look, please?

Here's a backtrace from an unoptimized build:

  window.c:554: Emacs fatal error: assertion failed: EQ (window, selected_window)

  Thread 1 hit Breakpoint 1, terminate_due_to_signal (sig=22,
      backtrace_limit=2147483647) at emacs.c:378
  378       signal (sig, SIG_DFL);
  (gdb) bt
  #0  terminate_due_to_signal (sig=22, backtrace_limit=2147483647)
      at emacs.c:378
  #1  0x012196a3 in die (
      msg=0x172067b <DEFAULT_REHASH_SIZE+783> "EQ (window, selected_window)",
      file=0x1720425 <DEFAULT_REHASH_SIZE+185> "window.c", line=554)
      at alloc.c:7341
  #2  0x010b9b57 in select_window (window=XIL(0xa000000006bc6220),
      norecord=XIL(0x30), inhibit_point_swap=false) at window.c:554
  #3  0x010b9d97 in Fselect_window (window=XIL(0xa000000006bc6220),
      norecord=XIL(0x30)) at window.c:630
  #4  0x0106036e in gui_consider_frame_title (frame=XIL(0xa000000006bc6020))
      at xdisp.c:12569
  #5  0x01060989 in prepare_menu_bars () at xdisp.c:12679
  #6  0x01068a85 in redisplay_internal () at xdisp.c:15575
  #7  0x01067518 in redisplay () at xdisp.c:15159
  #8  0x011677c4 in read_char (commandflag=1, map=XIL(0xc0000000062a2af0),
      prev_event=XIL(0), used_mouse_menu=0x82bdff, end_time=0x0)
      at keyboard.c:2497
  #9  0x0117f688 in read_key_sequence (keybuf=0x82c100, prompt=XIL(0),
      dont_downcase_last=false, can_return_switch_frame=true,
      fix_current_buffer=true, prevent_redisplay=false) at keyboard.c:9546
  #10 0x0116335a in command_loop_1 () at keyboard.c:1354
  #11 0x01255830 in internal_condition_case (bfun=0x1162c37 <command_loop_1>,
      handlers=XIL(0x90), hfun=0x1161e95 <cmd_error>) at eval.c:1359
  #12 0x011626a4 in command_loop_2 (ignore=XIL(0)) at keyboard.c:1095
  #13 0x01254a3d in internal_catch (tag=XIL(0x5940),
      func=0x1162667 <command_loop_2>, arg=XIL(0)) at eval.c:1120
  #14 0x01162589 in command_loop () at keyboard.c:1066
  #15 0x01161925 in recursive_edit_1 () at keyboard.c:718
  #16 0x011c17be in read_minibuf (map=XIL(0xc0000000062a3ab0),
      initial=XIL(0x8000000007142188), prompt=XIL(0x800000000592036c),
      expflag=false, histvar=XIL(0x6060), histpos=make_fixnum(0),
      defalt=XIL(0x80000000062abed0), allow_props=false,
      inherit_input_method=false) at minibuf.c:730
  #17 0x011c29a3 in Fread_from_minibuffer (prompt=XIL(0x800000000592036c),
      initial_contents=XIL(0x8000000007142188), keymap=XIL(0xc0000000062a3ab0),
      sys_read=XIL(0), hist=XIL(0x6060), default_value=XIL(0x80000000062abed0),
      inherit_input_method=XIL(0)) at minibuf.c:1021
  #18 0x0125bba7 in funcall_subr (subr=0x170ae60 <Sread_from_minibuffer>,
      numargs=7, args=0x82c8a0) at eval.c:2902
  #19 0x0125b2bc in Ffuncall (nargs=8, args=0x82c898) at eval.c:2809
  #20 0x012c5ad4 in exec_byte_code (bytestr=XIL(0x80000000059e4f44),
      vector=XIL(0xa0000000059e2c6c), maxdepth=make_fixnum(18),
      args_template=make_fixnum(2050), nargs=8, args=0x82cf40) at bytecode.c:632
  #21 0x0125bdeb in fetch_and_exec_byte_code (fun=XIL(0xa0000000059e2c3c),
      syms_left=make_fixnum(2050), nargs=8, args=0x82cf00) at eval.c:2931
  #22 0x0125c368 in funcall_lambda (fun=XIL(0xa0000000059e2c3c), nargs=8,
      arg_vector=0x82cf00) at eval.c:3012
  #23 0x0125b316 in Ffuncall (nargs=9, args=0x82cef8) at eval.c:2811
  #24 0x011c556b in Fcompleting_read (prompt=XIL(0x800000000592036c),
      collection=XIL(0x409f4b4), predicate=XIL(0x5e80),
      require_match=XIL(0x406c17c), initial_input=XIL(0x8000000007142188),
      hist=XIL(0x6060), def=XIL(0x80000000062abed0),
      inherit_input_method=XIL(0)) at minibuf.c:1733
  #25 0x0125bcde in funcall_subr (subr=0x170af60 <Scompleting_read>, numargs=7,
      args=0x82d210) at eval.c:2907
  #26 0x0125b2bc in Ffuncall (nargs=8, args=0x82d208) at eval.c:2809
  #27 0x012c5ad4 in exec_byte_code (bytestr=XIL(0x8000000005bdf1dc),
      vector=XIL(0xa0000000058da554), maxdepth=make_fixnum(22),
      args_template=make_fixnum(1537), nargs=6, args=0x82d9f0) at bytecode.c:632
  #28 0x0125bdeb in fetch_and_exec_byte_code (fun=XIL(0xa0000000058da524),
      syms_left=make_fixnum(1537), nargs=6, args=0x82d9c0) at eval.c:2931
  #29 0x0125c368 in funcall_lambda (fun=XIL(0xa0000000058da524), nargs=6,
      arg_vector=0x82d9c0) at eval.c:3012
  #30 0x0125b316 in Ffuncall (nargs=7, args=0x82d9b8) at eval.c:2811
  #31 0x012c5ad4 in exec_byte_code (bytestr=XIL(0x8000000005bdf25c),
      vector=XIL(0xa0000000058da4dc), maxdepth=make_fixnum(13),
      args_template=make_fixnum(1537), nargs=4, args=0x82dfc0) at bytecode.c:632
  #32 0x0125bdeb in fetch_and_exec_byte_code (fun=XIL(0xa0000000058da4ac),
      syms_left=make_fixnum(1537), nargs=4, args=0x82dfa0) at eval.c:2931
  #33 0x0125c368 in funcall_lambda (fun=XIL(0xa0000000058da4ac), nargs=4,
      arg_vector=0x82dfa0) at eval.c:3012
  #34 0x0125b316 in Ffuncall (nargs=5, args=0x82df98) at eval.c:2811
  #35 0x012c5ad4 in exec_byte_code (bytestr=XIL(0x8000000005920404),
      vector=XIL(0xa0000000059203dc), maxdepth=make_fixnum(7),
      args_template=make_fixnum(514), nargs=2, args=0x82e570) at bytecode.c:632
  #36 0x0125bdeb in fetch_and_exec_byte_code (fun=XIL(0xa0000000059203ac),
      syms_left=make_fixnum(514), nargs=2, args=0x82e560) at eval.c:2931
  #37 0x0125c368 in funcall_lambda (fun=XIL(0xa0000000059203ac), nargs=2,
      arg_vector=0x82e560) at eval.c:3012
  #38 0x0125b316 in Ffuncall (nargs=3, args=0x82e558) at eval.c:2811
  #39 0x012c5ad4 in exec_byte_code (bytestr=XIL(0x8000000005920434),
      vector=XIL(0xa00000000592034c), maxdepth=make_fixnum(3),
      args_template=XIL(0), nargs=0, args=0x0) at bytecode.c:632
  #40 0x012c4ba9 in Fbyte_code (bytestr=XIL(0x8000000005920434),
      vector=XIL(0xa00000000592034c), maxdepth=make_fixnum(3)) at bytecode.c:334
  #41 0x01258e92 in eval_sub (form=XIL(0xc00000000592031c)) at eval.c:2292
  #42 0x0125827c in Feval (form=XIL(0xc00000000592031c), lexical=XIL(0))
      at eval.c:2115
  #43 0x0124c06a in Fcall_interactively (function=XIL(0x40e4e14),
      record_flag=XIL(0), keys=XIL(0xa000000005eb8e9c)) at callint.c:322
  #44 0x0125b8a9 in funcall_subr (subr=0x170d7a0 <Scall_interactively>,
      numargs=3, args=0x82ef80) at eval.c:2887
  #45 0x0125b2bc in Ffuncall (nargs=4, args=0x82ef78) at eval.c:2809
  #46 0x012c5ad4 in exec_byte_code (bytestr=XIL(0x80000000059f24ac),
      vector=XIL(0xa0000000059f2254), maxdepth=make_fixnum(13),
      args_template=make_fixnum(1025), nargs=1, args=0x82f5d0) at bytecode.c:632
  #47 0x0125bdeb in fetch_and_exec_byte_code (fun=XIL(0xa0000000059f2224),
      syms_left=make_fixnum(1025), nargs=1, args=0x82f5c8) at eval.c:2931
  #48 0x0125c368 in funcall_lambda (fun=XIL(0xa0000000059f2224), nargs=1,
      arg_vector=0x82f5c8) at eval.c:3012
  #49 0x0125b316 in Ffuncall (nargs=2, args=0x82f5c0) at eval.c:2811
  #50 0x0125a5e8 in call1 (fn=XIL(0x3f30), arg1=XIL(0x40e4e14)) at eval.c:2669
  #51 0x01163878 in command_loop_1 () at keyboard.c:1467
  #52 0x01255830 in internal_condition_case (bfun=0x1162c37 <command_loop_1>,
      handlers=XIL(0x90), hfun=0x1161e95 <cmd_error>) at eval.c:1359
  #53 0x011626a4 in command_loop_2 (ignore=XIL(0)) at keyboard.c:1095
  #54 0x01254a3d in internal_catch (tag=XIL(0xe130),
      func=0x1162667 <command_loop_2>, arg=XIL(0)) at eval.c:1120
  #55 0x01162621 in command_loop () at keyboard.c:1074
  #56 0x01161925 in recursive_edit_1 () at keyboard.c:718
  #57 0x01161b93 in Frecursive_edit () at keyboard.c:790
  #58 0x0115d3a8 in main (argc=2, argv=0xa428e0) at emacs.c:2047

  Lisp Backtrace:
  "redisplay_internal (C function)" (0x0)
  "read-from-minibuffer" (0x82c8a0)
  "completing-read-default" (0x82cf00)
  "completing-read" (0x82d210)
  "read-file-name-default" (0x82d9c0)
  "read-file-name" (0x82dfa0)
  "find-file-read-args" (0x82e560)
  "byte-code" (0x82ea18)
  "call-interactively" (0x82ef80)
  "command-execute" (0x82f5c8)

bug#44502: 28.0.50; Emacs crash using new frame

[Alan Mackenzie]

Hello, Eli and Andy.

On Sat, Nov 07, 2020 at 16:05:51 +0200, Eli Zaretskii wrote:
> > From: Andy Moreton <andrewjmoreton@gmail.com>
> > Date: Sat, 7 Nov 2020 13:27:30 +0000

> > Emacs crashed when using a new frame. After a bootstrap of master, I
> > could repeat the crash witht he following recipe:
> >    - Run "emacs -Q"
> >    - Type "C-x 5 2 RET" to create a new frame (which becomes selected)
> >    - Type "C-x C-f" and emacs crashes

> > I bisected this using the recipe above, with:
> >    git checkout master
> >    git bisect start
> >    git bisect bad
> >    git bisect good c3a20804a8

> > Bisect reports the bad commit as:
> >    2ecbf4cfae Allow minibuffer to stay in its original frame.
> >               (2020-11-05 Alan Mackenzie)

> Thanks.  Yes, the above recipe causes an assertion violation.  Alan,
> can you take a look, please?

Thanks for the backtrace, which was helpful.  I've committed the
following patch, which appears to fix the bug:

commit cfe8a73cab5e7a9c6a6fcc212bd9df980f233895 (HEAD -> master,
origin/master, origin/HEAD)
Author: Alan Mackenzie <acm@muc.de>
Date:   Sun Nov 8 13:28:55 2020 +0000

    Don't set the selected window to the miniwindow on a frame change.

    Intended to fix bug #44502.

    * src/minibuf.c (move_minibuffer_onto_frame): Remove the lines of code which
    set the selected window to the minibuffer.

diff --git a/src/minibuf.c b/src/minibuf.c
index 068086ead8..8c19559b08 100644
--- a/src/minibuf.c
+++ b/src/minibuf.c
@@ -142,10 +142,6 @@ void move_minibuffer_onto_frame (void)

       set_window_buffer (sf->minibuffer_window, buffer, 0, 0);
       minibuf_window = sf->minibuffer_window;
-      if (EQ (XWINDOW (minibuf_window)->frame, selected_frame))
-        /* The minibuffer might be on another frame. */
-        Fset_frame_selected_window (selected_frame, sf->minibuffer_window,
-                                    Qnil);
       set_window_buffer (of->minibuffer_window, get_minibuffer (0), 0, 0);
     }
 }


> Here's a backtrace from an unoptimized build:

>   window.c:554: Emacs fatal error: assertion failed: EQ (window, selected_window)

>   Thread 1 hit Breakpoint 1, terminate_due_to_signal (sig=22,
>       backtrace_limit=2147483647) at emacs.c:378
>   378       signal (sig, SIG_DFL);

[ .... ]

>   Lisp Backtrace:
>   "redisplay_internal (C function)" (0x0)
>   "read-from-minibuffer" (0x82c8a0)
>   "completing-read-default" (0x82cf00)
>   "completing-read" (0x82d210)
>   "read-file-name-default" (0x82d9c0)
>   "read-file-name" (0x82dfa0)
>   "find-file-read-args" (0x82e560)
>   "byte-code" (0x82ea18)
>   "call-interactively" (0x82ef80)
>   "command-execute" (0x82f5c8)

-- 
Alan Mackenzie (Nuremberg, Germany).

bug#44502: 28.0.50; Emacs crash using new frame

[Eli Zaretskii]

> Date: Sun, 8 Nov 2020 13:37:21 +0000
> Cc: Andy Moreton <andrewjmoreton@gmail.com>, 44502@debbugs.gnu.org, acm@muc.de
> Thanks for the backtrace, which was helpful.  I've committed the
> following patch, which appears to fix the bug:

Thanks, it no longer crashes here.

bug#44502: 28.0.50; Emacs crash using new frame

[Andy Moreton]

On Sun 08 Nov 2020, Eli Zaretskii wrote:

>> Date: Sun, 8 Nov 2020 13:37:21 +0000
>> Cc: Andy Moreton <andrewjmoreton@gmail.com>, 44502@debbugs.gnu.org, acm@muc.de
>> Thanks for the backtrace, which was helpful.  I've committed the
>> following patch, which appears to fix the bug:
>
> Thanks, it no longer crashes here.

Thanks Alan, that fixes the bug here too.

    AndyM

bug#44502: 28.0.50; Emacs crash using new frame

[Lars Ingebrigtsen]

Andy Moreton <andrewjmoreton@gmail.com> writes:

> On Sun 08 Nov 2020, Eli Zaretskii wrote:
>
>>> Date: Sun, 8 Nov 2020 13:37:21 +0000
>>> Cc: Andy Moreton <andrewjmoreton@gmail.com>, 44502@debbugs.gnu.org,
>>> acm@muc.de
>>> Thanks for the backtrace, which was helpful.  I've committed the
>>> following patch, which appears to fix the bug:
>>
>> Thanks, it no longer crashes here.
>
> Thanks Alan, that fixes the bug here too.

The patch was pushed at the time, but the bug report was left open, so
I'm closing it now.

commit cfe8a73cab5e7a9c6a6fcc212bd9df980f233895
Author:     Alan Mackenzie <acm@muc.de>
AuthorDate: Sun Nov 8 13:28:55 2020 +0000


    Don't set the selected window to the miniwindow on a frame change.
    
    Intended to fix bug #44502.


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

bug#44502:

[andrei.elkin--- via Bug reports for GNU Emacs, the Swiss army knife of text editors]

Hello dear Colleagues!

For couple of times I hit a stack whose top part perfectly fits to the
reported in this bug.
Mine:
gdb) bt
#0  0x00007ffff256c817 in raise (sig=<optimized out>) at raise.c:51
#1  0x0000555555732728 in terminate_due_to_signal (sig=6, backtrace_limit=2147483647) at emacs.c:437
#2  0x00005555557e5e2e in die (msg=0x55555593c747 "EQ (window, selected_window)", file=0x55555593c4dc "window.c", line=557) at alloc.c:7486
#3  0x000055555564f2cb in select_window (window=..., norecord=..., inhibit_point_swap=false) at window.c:557
#4  0x000055555564f45b in Fselect_window (window=..., norecord=...) at window.c:634
#5  0x00005555555f0389 in gui_consider_frame_title (frame=...) at xdisp.c:12801
#6  0x00005555555f09be in prepare_menu_bars () at xdisp.c:12914
#7  0x00005555555f8d68 in redisplay_internal () at xdisp.c:15785
#8  0x00005555555f7a14 in redisplay () at xdisp.c:15369
#9  0x000055555573ec1c in read_char (commandflag=1, map=..., prev_event=..., used_mouse_menu=0x7fffffffd8ed, end_time=0x0) at keyboard.c:2555
#10 0x000055555575272b in read_key_sequence (keybuf=0x7fffffffdad0, prompt=..., dont_downcase_last=false, can_return_switch_frame=true, fix_current_buffer=true, prevent_redisplay=false) at keyboard.c:9635
#11 0x000055555573aea2 in command_loop_1 () at keyboard.c:1392
#12 0x000055555581cc49 in internal_condition_case (bfun=0x55555573aa08 <command_loop_1>, handlers=..., hfun=0x555555739e35 <cmd_error>) at eval.c:1450
#13 0x000055555573a5ef in command_loop_2 (handlers=...) at keyboard.c:1133
#14 0x000055555581be5f in internal_catch (tag=..., func=0x55555573a5c8 <command_loop_2>, arg=...) at eval.c:1181
#15 0x000055555573a593 in command_loop () at keyboard.c:1111
#16 0x0000555555739900 in recursive_edit_1 () at keyboard.c:720
#17 0x0000555555739b14 in Frecursive_edit () at keyboard.c:803
#18 0x000055555573578d in main (argc=3, argv=0x7fffffffdf38) at emacs.c:2358

My emacs version:

$ git log -1 --oneline 
7ffcba4213 


I am used to run emacs in gdb so keeping the stack alive in case
some of you would be interested to dig in.

Thank you in advace!

Emacs' faithful
Andrei Elkin @ mariadb

bug#44502:

[Eli Zaretskii]

> Date: Wed, 10 Aug 2022 16:26:38 +0300
> From: andrei.elkin--- via "Bug reports for GNU Emacs,
>  the Swiss army knife of text editors" <bug-gnu-emacs@gnu.org>
> 
> Hello dear Colleagues!
> 
> For couple of times I hit a stack whose top part perfectly fits to the
> reported in this bug.
> Mine:
> gdb) bt
> #0  0x00007ffff256c817 in raise (sig=<optimized out>) at raise.c:51
> #1  0x0000555555732728 in terminate_due_to_signal (sig=6, backtrace_limit=2147483647) at emacs.c:437
> #2  0x00005555557e5e2e in die (msg=0x55555593c747 "EQ (window, selected_window)", file=0x55555593c4dc "window.c", line=557) at alloc.c:7486
> #3  0x000055555564f2cb in select_window (window=..., norecord=..., inhibit_point_swap=false) at window.c:557
> #4  0x000055555564f45b in Fselect_window (window=..., norecord=...) at window.c:634
> #5  0x00005555555f0389 in gui_consider_frame_title (frame=...) at xdisp.c:12801
> #6  0x00005555555f09be in prepare_menu_bars () at xdisp.c:12914

Please do:

 (gdb) frame 3
 (gdb) print window
 (gdb) xwindow
 (gdb) print XWINDOW(window)->contents
 (gdb) xbuffer
 (gdb) print selected_window
 (gdb) xwindow
 (gdb) print XWINDOW(selected_window)->contents
 (gdb) xbuffer

and post here everything GDB prints as result.

If GDB says it doesn't know about commands xwindow and xbuffer, you
need to do this:

 (gdb) source /path/to/emacs/src/.gdbinit

> My emacs version:
> 
> $ git log -1 --oneline 
> 7ffcba4213 

On which branch of the Git repository?

Thanks.

bug#44502:

[andrei.elkin--- via Bug reports for GNU Emacs, the Swiss army knife of text editors]

Howdy Eli!

>> Date: Wed, 10 Aug 2022 16:26:38 +0300
>> From: andrei.elkin--- via "Bug reports for GNU Emacs,
>>  the Swiss army knife of text editors" <bug-gnu-emacs@gnu.org>
>> 
>> Hello dear Colleagues!
>> 
>> For couple of times I hit a stack whose top part perfectly fits to the
>> reported in this bug.
>> Mine:
>> gdb) bt
>> #0  0x00007ffff256c817 in raise (sig=<optimized out>) at raise.c:51
>> #1  0x0000555555732728 in terminate_due_to_signal (sig=6, backtrace_limit=2147483647) at emacs.c:437
>> #2 0x00005555557e5e2e in die (msg=0x55555593c747 "EQ (window,
>> selected_window)", file=0x55555593c4dc "window.c", line=557) at
>> alloc.c:7486
>> #3 0x000055555564f2cb in select_window (window=..., norecord=...,
>> inhibit_point_swap=false) at window.c:557
>> #4  0x000055555564f45b in Fselect_window (window=..., norecord=...) at window.c:634
>> #5  0x00005555555f0389 in gui_consider_frame_title (frame=...) at xdisp.c:12801
>> #6  0x00005555555f09be in prepare_menu_bars () at xdisp.c:12914
>
> Please do:
>
>  (gdb) frame 3
>  (gdb) print window
>  (gdb) xwindow
>  (gdb) print XWINDOW(window)->contents
>  (gdb) xbuffer
>  (gdb) print selected_window
>  (gdb) xwindow
>  (gdb) print XWINDOW(selected_window)->contents
>  (gdb) xbuffer
>
> and post here everything GDB prints as result.


(gdb) f 3
#3  0x000055555564f2cb in select_window (window=XIL(0x55555b038855), norecord=XIL(0x30), inhibit_point_swap=false) at window.c:557
557	      eassert (EQ (window, selected_window));
(gdb) p window
$4 = XIL(0x55555b038855)
(gdb) xwindow
$5 = (struct window *) 0x55555b038850
124x1+0+80
(gdb) print XWINDOW(window)->contents
$6 = XIL(0x7fffea1bd07d)
(gdb) xbuffer
$7 = (struct buffer *) 0x7fffea1bd078
0x7fffea4aedc1 " *Minibuf-0*"
(gdb) print selected_window
$8 = XIL(0x55555b038645)
(gdb) xwindow
$9 = (struct window *) 0x55555b038640
124x80+0+0
(gdb) print XWINDOW(selected_window)->contents
$10 = XIL(0x5555577f9475)
(gdb) xbuffer
$11 = (struct buffer *) 0x5555577f9470
0x555559788ff0 "magit: A<10.6>"


>
> If GDB says it doesn't know about commands xwindow and xbuffer, you
> need to do this:
>
>  (gdb) source /path/to/emacs/src/.gdbinit
>
>> My emacs version:
>> 
>> $ git log -1 --oneline 
>> 7ffcba4213 
>
> On which branch of the Git repository?

emacs-28

>
> Thanks.

I promise to be more diligent with replies tomorrow (has been a busy
today, sorry).


Cheers,

Andrei

bug#44502:

[Eli Zaretskii]

> From: andrei.elkin@pp.inet.fi
> Cc: 44502@debbugs.gnu.org
> Date: Thu, 11 Aug 2022 21:19:06 +0300
> 
> (gdb) p window
> $4 = XIL(0x55555b038855)
> (gdb) xwindow
> $5 = (struct window *) 0x55555b038850
> 124x1+0+80
> (gdb) print XWINDOW(window)->contents
> $6 = XIL(0x7fffea1bd07d)
> (gdb) xbuffer
> $7 = (struct buffer *) 0x7fffea1bd078
> 0x7fffea4aedc1 " *Minibuf-0*"
> (gdb) print selected_window
> $8 = XIL(0x55555b038645)
> (gdb) xwindow
> $9 = (struct window *) 0x55555b038640
> 124x80+0+0
> (gdb) print XWINDOW(selected_window)->contents
> $10 = XIL(0x5555577f9475)
> (gdb) xbuffer
> $11 = (struct buffer *) 0x5555577f9470
> 0x555559788ff0 "magit: A<10.6>"

Do you remember what were you doing when this assertion violation
happened?


Also, are you using a separate minibuffer frame?

bug#44502:

[andrei.elkin--- via Bug reports for GNU Emacs, the Swiss army knife of text editors]

Eli Zaretskii <eliz@gnu.org> writes:

>> From: andrei.elkin@pp.inet.fi
>> Cc: 44502@debbugs.gnu.org
>> Date: Thu, 11 Aug 2022 21:19:06 +0300
>> 
>> (gdb) p window
>> $4 = XIL(0x55555b038855)
>> (gdb) xwindow
>> $5 = (struct window *) 0x55555b038850
>> 124x1+0+80
>> (gdb) print XWINDOW(window)->contents
>> $6 = XIL(0x7fffea1bd07d)
>> (gdb) xbuffer
>> $7 = (struct buffer *) 0x7fffea1bd078
>> 0x7fffea4aedc1 " *Minibuf-0*"
>> (gdb) print selected_window
>> $8 = XIL(0x55555b038645)
>> (gdb) xwindow
>> $9 = (struct window *) 0x55555b038640
>> 124x80+0+0
>> (gdb) print XWINDOW(selected_window)->contents
>> $10 = XIL(0x5555577f9475)
>> (gdb) xbuffer
>> $11 = (struct buffer *) 0x5555577f9470
>> 0x555559788ff0 "magit: A<10.6>"
>
> Do you remember what were you doing when this assertion violation
> happened?

Something like

  C-u M-x shell

>
>
> Also, are you using a separate minibuffer frame?

No

bug#44502:

[Eli Zaretskii]

> From: andrei.elkin@pp.inet.fi
> Cc: 44502@debbugs.gnu.org
> Date: Thu, 11 Aug 2022 22:10:12 +0300
> 
> Eli Zaretskii <eliz@gnu.org> writes:
> 
> >> From: andrei.elkin@pp.inet.fi
> >> Cc: 44502@debbugs.gnu.org
> >> Date: Thu, 11 Aug 2022 21:19:06 +0300
> >> 
> >> (gdb) p window
> >> $4 = XIL(0x55555b038855)
> >> (gdb) xwindow
> >> $5 = (struct window *) 0x55555b038850
> >> 124x1+0+80
> >> (gdb) print XWINDOW(window)->contents
> >> $6 = XIL(0x7fffea1bd07d)
> >> (gdb) xbuffer
> >> $7 = (struct buffer *) 0x7fffea1bd078
> >> 0x7fffea4aedc1 " *Minibuf-0*"
> >> (gdb) print selected_window
> >> $8 = XIL(0x55555b038645)
> >> (gdb) xwindow
> >> $9 = (struct window *) 0x55555b038640
> >> 124x80+0+0
> >> (gdb) print XWINDOW(selected_window)->contents
> >> $10 = XIL(0x5555577f9475)
> >> (gdb) xbuffer
> >> $11 = (struct buffer *) 0x5555577f9470
> >> 0x555559788ff0 "magit: A<10.6>"
> >
> > Do you remember what were you doing when this assertion violation
> > happened?
> 
> Something like
> 
>   C-u M-x shell
> 
> >
> >
> > Also, are you using a separate minibuffer frame?
> 
> No

Then I tend to think that the assertion there is simply wrong.

Adding Alan to CC, since this seems to be related to the
minibuffer-follows-selected-frame feature.  Alan, this happens in
Emacs 28, so trying to fix it on the release branch in a safe way is
important.  TIA.

bug#44502:

[Alan Mackenzie]

Hello, Eli.

On Fri, Aug 12, 2022 at 09:27:21 +0300, Eli Zaretskii wrote:
> > From: andrei.elkin@pp.inet.fi
> > Cc: 44502@debbugs.gnu.org
> > Date: Thu, 11 Aug 2022 22:10:12 +0300

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

> > >> From: andrei.elkin@pp.inet.fi
> > >> Cc: 44502@debbugs.gnu.org
> > >> Date: Thu, 11 Aug 2022 21:19:06 +0300

> > >> (gdb) p window
> > >> $4 = XIL(0x55555b038855)
> > >> (gdb) xwindow
> > >> $5 = (struct window *) 0x55555b038850
> > >> 124x1+0+80
> > >> (gdb) print XWINDOW(window)->contents
> > >> $6 = XIL(0x7fffea1bd07d)
> > >> (gdb) xbuffer
> > >> $7 = (struct buffer *) 0x7fffea1bd078
> > >> 0x7fffea4aedc1 " *Minibuf-0*"
> > >> (gdb) print selected_window
> > >> $8 = XIL(0x55555b038645)
> > >> (gdb) xwindow
> > >> $9 = (struct window *) 0x55555b038640
> > >> 124x80+0+0
> > >> (gdb) print XWINDOW(selected_window)->contents
> > >> $10 = XIL(0x5555577f9475)
> > >> (gdb) xbuffer
> > >> $11 = (struct buffer *) 0x5555577f9470
> > >> 0x555559788ff0 "magit: A<10.6>"

> > > Do you remember what were you doing when this assertion violation
> > > happened?

> > Something like

> >   C-u M-x shell



> > > Also, are you using a separate minibuffer frame?

> > No

> Then I tend to think that the assertion there is simply wrong.

> Adding Alan to CC, since this seems to be related to the
> minibuffer-follows-selected-frame feature.  Alan, this happens in
> Emacs 28, so trying to fix it on the release branch in a safe way is
> important.  TIA.

OK, I'll have a look at it over the weekend.

-- 
Alan Mackenzie (Nuremberg, Germany).

bug#44502:

[andrei.elkin--- via Bug reports for GNU Emacs, the Swiss army knife of text editors]

Salve Eli!

>> From: andrei.elkin@pp.inet.fi
>> Cc: 44502@debbugs.gnu.org
>> Date: Thu, 11 Aug 2022 22:10:12 +0300
>> 
>> Eli Zaretskii <eliz@gnu.org> writes:
>> 
>> >> From: andrei.elkin@pp.inet.fi
>> >> Cc: 44502@debbugs.gnu.org
>> >> Date: Thu, 11 Aug 2022 21:19:06 +0300
>> >> 
>> >> (gdb) p window
>> >> $4 = XIL(0x55555b038855)
>> >> (gdb) xwindow
>> >> $5 = (struct window *) 0x55555b038850
>> >> 124x1+0+80
>> >> (gdb) print XWINDOW(window)->contents
>> >> $6 = XIL(0x7fffea1bd07d)
>> >> (gdb) xbuffer
>> >> $7 = (struct buffer *) 0x7fffea1bd078
>> >> 0x7fffea4aedc1 " *Minibuf-0*"
>> >> (gdb) print selected_window
>> >> $8 = XIL(0x55555b038645)
>> >> (gdb) xwindow
>> >> $9 = (struct window *) 0x55555b038640
>> >> 124x80+0+0
>> >> (gdb) print XWINDOW(selected_window)->contents
>> >> $10 = XIL(0x5555577f9475)
>> >> (gdb) xbuffer
>> >> $11 = (struct buffer *) 0x5555577f9470
>> >> 0x555559788ff0 "magit: A<10.6>"
>> >
>> > Do you remember what were you doing when this assertion violation
>> > happened?
>> 
>> Something like
>> 
>>   C-u M-x shell
>> 
>> >
>> >
>> > Also, are you using a separate minibuffer frame?

There are still *two* asserted emacs' frames around with "Minibuffer-1"
(not 0!) around.

>> 
>> No
>
> Then I tend to think that the assertion there is simply wrong.
>
> Adding Alan to CC, since this seems to be related to the

I am holing on the gdb session for your colleague just in case.

> minibuffer-follows-selected-frame feature.  Alan, this happens in
> Emacs 28, so trying to fix it on the release branch in a safe way is
> important.  TIA.

Thanks over for so far! If the assert comes back to me, I'd just comment it
out :-).

Have a good day!

Andrei

bug#44502:

[Alan Mackenzie]

Hello, Andrei.

On Fri, Aug 12, 2022 at 13:24:27 +0300, andrei.elkin@pp.inet.fi wrote:
> Salve Eli!

> >> From: andrei.elkin@pp.inet.fi
> >> Cc: 44502@debbugs.gnu.org
> >> Date: Thu, 11 Aug 2022 22:10:12 +0300

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

> >> >> From: andrei.elkin@pp.inet.fi
> >> >> Cc: 44502@debbugs.gnu.org
> >> >> Date: Thu, 11 Aug 2022 21:19:06 +0300

> >> >> (gdb) p window
> >> >> $4 = XIL(0x55555b038855)
> >> >> (gdb) xwindow
> >> >> $5 = (struct window *) 0x55555b038850
> >> >> 124x1+0+80
> >> >> (gdb) print XWINDOW(window)->contents
> >> >> $6 = XIL(0x7fffea1bd07d)
> >> >> (gdb) xbuffer
> >> >> $7 = (struct buffer *) 0x7fffea1bd078
> >> >> 0x7fffea4aedc1 " *Minibuf-0*"
> >> >> (gdb) print selected_window
> >> >> $8 = XIL(0x55555b038645)
> >> >> (gdb) xwindow
> >> >> $9 = (struct window *) 0x55555b038640
> >> >> 124x80+0+0
> >> >> (gdb) print XWINDOW(selected_window)->contents
> >> >> $10 = XIL(0x5555577f9475)
> >> >> (gdb) xbuffer
> >> >> $11 = (struct buffer *) 0x5555577f9470
> >> >> 0x555559788ff0 "magit: A<10.6>"

> >> > Do you remember what were you doing when this assertion violation
> >> > happened?

> >> Something like

> >>   C-u M-x shell

I've tried quite a bit to reproduce the error, but haven't managed.

> >> > Also, are you using a separate minibuffer frame?

> There are still *two* asserted emacs' frames around with "Minibuffer-1"
> (not 0!) around.

I think I understand what has caused the breakage of this assertion, and
as Eli suggested, it is something fairly harmless.

> >> No

> > Then I tend to think that the assertion there is simply wrong.

> > Adding Alan to CC, since this seems to be related to the

> I am holing on the gdb session for your colleague just in case.

Thanks!  I'm sorry it's taken me so long to get back to you, it's been a
chaotic weekend.

> > minibuffer-follows-selected-frame feature.  Alan, this happens in
> > Emacs 28, so trying to fix it on the release branch in a safe way is
> > important.  TIA.

> Thanks over for so far! If the assert comes back to me, I'd just comment it
> out :-).

I think the following fix to the assert should indeed be a "safe" fix,
suitable for Emacs-28.  Could you possibly apply it, please, and try to
recreate the error.  If you don't manage to recreate the error, the bug
is probably "fixed".



diff --git a/src/window.c b/src/window.c
index 2576b66a18..35ec2a1f90 100644
--- a/src/window.c
+++ b/src/window.c
@@ -554,7 +554,9 @@ select_window (Lisp_Object window, Lisp_Object norecord,
 	 frame is active.  */
       Fselect_frame (frame, norecord);
       /* Fselect_frame called us back so we've done all the work already.  */
-      eassert (EQ (window, selected_window));
+      eassert (EQ (window, selected_window)
+	       || (EQ (window, f->minibuffer_window)
+		   && NILP (Fminibufferp (XWINDOW (window)->contents, Qt))));
       return window;
     }
   else


> Have a good day!

And yourself, too!

> Andrei

-- 
Alan Mackenzie (Nuremberg, Germany).

bug#44502:

[Eli Zaretskii]

Ping!  Any progress with this bug?

> Date: Sun, 14 Aug 2022 14:30:04 +0000
> Cc: Eli Zaretskii <eliz@gnu.org>, 44502@debbugs.gnu.org, acm@muc.de
> From: Alan Mackenzie <acm@muc.de>
> 
> Hello, Andrei.
> 
> On Fri, Aug 12, 2022 at 13:24:27 +0300, andrei.elkin@pp.inet.fi wrote:
> > Salve Eli!
> 
> > >> From: andrei.elkin@pp.inet.fi
> > >> Cc: 44502@debbugs.gnu.org
> > >> Date: Thu, 11 Aug 2022 22:10:12 +0300
> 
> > >> Eli Zaretskii <eliz@gnu.org> writes:
> 
> > >> >> From: andrei.elkin@pp.inet.fi
> > >> >> Cc: 44502@debbugs.gnu.org
> > >> >> Date: Thu, 11 Aug 2022 21:19:06 +0300
> 
> > >> >> (gdb) p window
> > >> >> $4 = XIL(0x55555b038855)
> > >> >> (gdb) xwindow
> > >> >> $5 = (struct window *) 0x55555b038850
> > >> >> 124x1+0+80
> > >> >> (gdb) print XWINDOW(window)->contents
> > >> >> $6 = XIL(0x7fffea1bd07d)
> > >> >> (gdb) xbuffer
> > >> >> $7 = (struct buffer *) 0x7fffea1bd078
> > >> >> 0x7fffea4aedc1 " *Minibuf-0*"
> > >> >> (gdb) print selected_window
> > >> >> $8 = XIL(0x55555b038645)
> > >> >> (gdb) xwindow
> > >> >> $9 = (struct window *) 0x55555b038640
> > >> >> 124x80+0+0
> > >> >> (gdb) print XWINDOW(selected_window)->contents
> > >> >> $10 = XIL(0x5555577f9475)
> > >> >> (gdb) xbuffer
> > >> >> $11 = (struct buffer *) 0x5555577f9470
> > >> >> 0x555559788ff0 "magit: A<10.6>"
> 
> > >> > Do you remember what were you doing when this assertion violation
> > >> > happened?
> 
> > >> Something like
> 
> > >>   C-u M-x shell
> 
> I've tried quite a bit to reproduce the error, but haven't managed.
> 
> > >> > Also, are you using a separate minibuffer frame?
> 
> > There are still *two* asserted emacs' frames around with "Minibuffer-1"
> > (not 0!) around.
> 
> I think I understand what has caused the breakage of this assertion, and
> as Eli suggested, it is something fairly harmless.
> 
> > >> No
> 
> > > Then I tend to think that the assertion there is simply wrong.
> 
> > > Adding Alan to CC, since this seems to be related to the
> 
> > I am holing on the gdb session for your colleague just in case.
> 
> Thanks!  I'm sorry it's taken me so long to get back to you, it's been a
> chaotic weekend.
> 
> > > minibuffer-follows-selected-frame feature.  Alan, this happens in
> > > Emacs 28, so trying to fix it on the release branch in a safe way is
> > > important.  TIA.
> 
> > Thanks over for so far! If the assert comes back to me, I'd just comment it
> > out :-).
> 
> I think the following fix to the assert should indeed be a "safe" fix,
> suitable for Emacs-28.  Could you possibly apply it, please, and try to
> recreate the error.  If you don't manage to recreate the error, the bug
> is probably "fixed".
> 
> 
> 
> diff --git a/src/window.c b/src/window.c
> index 2576b66a18..35ec2a1f90 100644
> --- a/src/window.c
> +++ b/src/window.c
> @@ -554,7 +554,9 @@ select_window (Lisp_Object window, Lisp_Object norecord,
>  	 frame is active.  */
>        Fselect_frame (frame, norecord);
>        /* Fselect_frame called us back so we've done all the work already.  */
> -      eassert (EQ (window, selected_window));
> +      eassert (EQ (window, selected_window)
> +	       || (EQ (window, f->minibuffer_window)
> +		   && NILP (Fminibufferp (XWINDOW (window)->contents, Qt))));
>        return window;
>      }
>    else
> 
> 
> > Have a good day!
> 
> And yourself, too!
> 
> > Andrei
> 
> -- 
> Alan Mackenzie (Nuremberg, Germany).
> 

bug#44502:

[Alan Mackenzie]

Hello, Eli.

On Fri, Aug 19, 2022 at 13:45:57 +0300, Eli Zaretskii wrote:
> Ping!  Any progress with this bug?

I haven't been able to reproduce the bug, but understand fairly well what
must have caused it.

I also haven't heard back from the OP since sending him a proposed patch
last Sunday.

Since the patch is fairly simple and obvious, also non-dangerous, how
about just installing it on the release branch?

> > I think the following fix to the assert should indeed be a "safe" fix,
> > suitable for Emacs-28.  Could you possibly apply it, please, and try to
> > recreate the error.  If you don't manage to recreate the error, the bug
> > is probably "fixed".

> > diff --git a/src/window.c b/src/window.c
> > index 2576b66a18..35ec2a1f90 100644
> > --- a/src/window.c
> > +++ b/src/window.c
> > @@ -554,7 +554,9 @@ select_window (Lisp_Object window, Lisp_Object norecord,
> >  	 frame is active.  */
> >        Fselect_frame (frame, norecord);
> >        /* Fselect_frame called us back so we've done all the work already.  */
> > -      eassert (EQ (window, selected_window));
> > +      eassert (EQ (window, selected_window)
> > +	       || (EQ (window, f->minibuffer_window)
> > +		   && NILP (Fminibufferp (XWINDOW (window)->contents, Qt))));
> >        return window;
> >      }
> >    else

-- 
Alan Mackenzie (Nuremberg, Germany).

bug#44502:

[Eli Zaretskii]

> Date: Fri, 19 Aug 2022 13:05:24 +0000
> Cc: andrei.elkin@pp.inet.fi, 44502@debbugs.gnu.org
> From: Alan Mackenzie <acm@muc.de>
> 
> I haven't been able to reproduce the bug, but understand fairly well what
> must have caused it.
> 
> I also haven't heard back from the OP since sending him a proposed patch
> last Sunday.
> 
> Since the patch is fairly simple and obvious, also non-dangerous, how
> about just installing it on the release branch?

Please go ahead and install.

Thanks.

bug#44502:

[Alan Mackenzie]

Hello, Eli and Andrei.

On Fri, Aug 19, 2022 at 16:20:58 +0300, Eli Zaretskii wrote:
> > Date: Fri, 19 Aug 2022 13:05:24 +0000
> > Cc: andrei.elkin@pp.inet.fi, 44502@debbugs.gnu.org
> > From: Alan Mackenzie <acm@muc.de>

> > I haven't been able to reproduce the bug, but understand fairly well what
> > must have caused it.

> > I also haven't heard back from the OP since sending him a proposed patch
> > last Sunday.

> > Since the patch is fairly simple and obvious, also non-dangerous, how
> > about just installing it on the release branch?

> Please go ahead and install.

DONE.  I'm closing the bug (again) with this post.

> Thanks.

-- 
Alan Mackenzie (Nuremberg, Germany).

bug#44502:

[andrei.elkin--- via Bug reports for GNU Emacs, the Swiss army knife of text editors]

Salute, Alan, Eli.

> Hello, Eli.
>
> On Fri, Aug 19, 2022 at 13:45:57 +0300, Eli Zaretskii wrote:
>> Ping!  Any progress with this bug?
>
> I haven't been able to reproduce the bug, but understand fairly well what
> must have caused it.
>
> I also haven't heard back from the OP since sending him a proposed patch
> last Sunday.

If OP is myself :-), then I have not patched my emacs waiting first for
the assert. Has not come back yet.


Cheers,

Andrei

>
> Since the patch is fairly simple and obvious, also non-dangerous, how
> about just installing it on the release branch?
>
>> > I think the following fix to the assert should indeed be a "safe" fix,
>> > suitable for Emacs-28.  Could you possibly apply it, please, and try to
>> > recreate the error.  If you don't manage to recreate the error, the bug
>> > is probably "fixed".
>
>> > diff --git a/src/window.c b/src/window.c
>> > index 2576b66a18..35ec2a1f90 100644
>> > --- a/src/window.c
>> > +++ b/src/window.c
>> > @@ -554,7 +554,9 @@ select_window (Lisp_Object window, Lisp_Object norecord,
>> >  	 frame is active.  */
>> >        Fselect_frame (frame, norecord);
>> >        /* Fselect_frame called us back so we've done all the work already.  */
>> > -      eassert (EQ (window, selected_window));
>> > +      eassert (EQ (window, selected_window)
>> > +	       || (EQ (window, f->minibuffer_window)
>> > +		   && NILP (Fminibufferp (XWINDOW (window)->contents, Qt))));
>> >        return window;
>> >      }
>> >    else