From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.blaine.gmane.org!not-for-mail From: Alan Mackenzie Newsgroups: gmane.emacs.bugs Subject: bug#47207: 28.0.50; decode_next_window_args crash Date: Tue, 13 Apr 2021 17:06:05 +0000 Message-ID: References: <83k0q5dbml.fsf@gnu.org> <64dca5b5-1234-9176-dcfe-b42d6eea2caa@gmx.at> <83h7l9d651.fsf@gnu.org> <83eegdd4uz.fsf@gnu.org> <8335wsdcob.fsf@gnu.org> <11b795a6-1a20-cc58-73d6-b75227dc732a@gmx.at> <83r1kcflv6.fsf@gnu.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="29861"; mail-complaints-to="usenet@ciao.gmane.io" Cc: 47207@debbugs.gnu.org To: martin rudalics Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane-mx.org@gnu.org Tue Apr 13 19:09:12 2021 Return-path: Envelope-to: geb-bug-gnu-emacs@m.gmane-mx.org Original-Received: from lists.gnu.org ([209.51.188.17]) by ciao.gmane.io with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from ) id 1lWMXH-0007eu-RV for geb-bug-gnu-emacs@m.gmane-mx.org; Tue, 13 Apr 2021 19:09:11 +0200 Original-Received: from localhost ([::1]:39954 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1lWMXC-0005q0-Tk for geb-bug-gnu-emacs@m.gmane-mx.org; Tue, 13 Apr 2021 13:09:06 -0400 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]:56632) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1lWMVC-0003w6-2f for bug-gnu-emacs@gnu.org; Tue, 13 Apr 2021 13:07:06 -0400 Original-Received: from debbugs.gnu.org ([209.51.188.43]:49120) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.90_1) (envelope-from ) id 1lWMVB-0000Vg-RH for bug-gnu-emacs@gnu.org; Tue, 13 Apr 2021 13:07:01 -0400 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1lWMVB-0003Yj-Km for bug-gnu-emacs@gnu.org; Tue, 13 Apr 2021 13:07:01 -0400 X-Loop: help-debbugs@gnu.org Resent-From: Alan Mackenzie Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Tue, 13 Apr 2021 17:07:01 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 47207 X-GNU-PR-Package: emacs Original-Received: via spool by 47207-submit@debbugs.gnu.org id=B47207.161833357413603 (code B ref 47207); Tue, 13 Apr 2021 17:07:01 +0000 Original-Received: (at 47207) by debbugs.gnu.org; 13 Apr 2021 17:06:14 +0000 Original-Received: from localhost ([127.0.0.1]:60660 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1lWMUQ-0003XK-4B for submit@debbugs.gnu.org; Tue, 13 Apr 2021 13:06:14 -0400 Original-Received: from colin.muc.de ([193.149.48.1]:63901 helo=mail.muc.de) by debbugs.gnu.org with smtp (Exim 4.84_2) (envelope-from ) id 1lWMUN-0003X6-MC for 47207@debbugs.gnu.org; Tue, 13 Apr 2021 13:06:12 -0400 Original-Received: (qmail 51772 invoked by uid 3782); 13 Apr 2021 17:06:05 -0000 Original-Received: from acm.muc.de (p4fe15996.dip0.t-ipconnect.de [79.225.89.150]) (using STARTTLS) by colin.muc.de (tmda-ofmipd) with ESMTP; Tue, 13 Apr 2021 19:06:05 +0200 Original-Received: (qmail 12303 invoked by uid 1000); 13 Apr 2021 17:06:05 -0000 Content-Disposition: inline In-Reply-To: X-Submission-Agent: TMDA/1.3.x (Ph3nix) X-Primary-Address: acm@muc.de X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list X-BeenThere: bug-gnu-emacs@gnu.org List-Id: "Bug reports for GNU Emacs, the Swiss army knife of text editors" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane-mx.org@gnu.org Original-Sender: "bug-gnu-emacs" Xref: news.gmane.io gmane.emacs.bugs:203975 Archived-At: Hello, Martin. On Tue, Apr 13, 2021 at 17:54:55 +0200, martin rudalics wrote: > and developers don't care.>> Because in my crash scenario (other-window 1 t) selects the tooltip > >> window. > > OK, then solving this issue will solve that as well, I guess. > Having just managed to "solve this issue" here in a more or less elegant > way, Alan beat me to it with a new twist. To reproduce with emacs -Q do > (custom-set-variables > '(tooltip-reuse-hidden-frame t) > '(x-gtk-use-system-tooltips nil)) > show a tooltip (by moving the mouse over the mode line for example) and > then type C-h f followed by C-g. Here this gets me > Thread 1 "emacs" hit Breakpoint 1, terminate_due_to_signal (sig=6, backtrace_limit=2147483647) at ../../src/emacs.c:399 > 399 signal (sig, SIG_DFL); > (gdb) bt > #0 0x00000000005a6c28 in terminate_due_to_signal (sig=6, backtrace_limit=2147483647) at ../../src/emacs.c:399 > #1 0x0000000000653420 in die (msg=0x7d01d6 "WINDOWP (a)", file=0x7d01c3 "../../src/window.h", line=543) at ../../src/alloc.c:7420 > #2 0x00000000006006d2 in XWINDOW (a=XIL(0)) at ../../src/window.h:543 > #3 0x00000000006039ae in read_minibuf_unwind () at ../../src/minibuf.c:1060 > #4 0x000000000068e80e in do_one_unbind (this_binding=0x7fffffffc880, unwinding=true, bindflag=SET_INTERNAL_UNBIND) at ../../src/eval.c:3594 > #5 0x000000000068ebc9 in unbind_to (count=3, value=XIL(0)) at ../../src/eval.c:3717 > #6 0x00000000006877a5 in unwind_to_catch (catch=0xd99a40, type=NONLOCAL_EXIT_SIGNAL, value=XIL(0x2eb09c3)) at ../../src/eval.c:1254 > #7 0x0000000000688dda in signal_or_quit (error_symbol=XIL(0xb5e0), data=XIL(0), keyboard_quit=true) at ../../src/eval.c:1784 > #8 0x00000000006888df in quit () at ../../src/eval.c:1664 > #9 0x00000000005ad8c5 in recursive_edit_1 () at ../../src/keyboard.c:722 > #10 0x0000000000602e27 in read_minibuf (map=XIL(0x7ffff409d9f3), initial=XIL(0), prompt=XIL(0x10b6304), expflag=false, histvar=XIL(0x9ae0), histpos=make_fixnum(0), defalt=XIL(0x7ffff437cb7c), allow_props=false, inherit_input_method=false) at ../../src/minibuf.c:871 > #11 0x00000000006044a0 in Fread_from_minibuffer (prompt=XIL(0x10b6304), initial_contents=XIL(0), keymap=XIL(0x7ffff409d9f3), read=XIL(0), hist=XIL(0), default_value=XIL(0x7ffff437cb7c), inherit_input_method=XIL(0)) at ../../src/minibuf.c:1312 > #12 0x000000000068ca11 in funcall_subr (subr=0xc54d00 , numargs=7, args=0x7fffffffcd70) at ../../src/eval.c:3011 [ .... ] > Lisp Backtrace: > "read-from-minibuffer" (0xffffcd70) > "completing-read-default" (0xffffd2c8) > "completing-read" (0xffffd448) > "byte-code" (0xffffd8a0) > "call-interactively" (0xffffdd40) > "command-execute" (0xffffe2a8) > (gdb) > I can easily sidestep this in read_minibuf_unwind via > FOR_EACH_FRAME (frames, exp_MB_frame) > { > f = XFRAME (exp_MB_frame); > if (!FRAME_TOOLTIP_P (f)) > { > window = f->minibuffer_window; > w = XWINDOW (window); > if (EQ (w->frame, exp_MB_frame) > && EQ (w->contents, nth_minibuffer (minibuf_level))) > goto found; > } > } > but the underlying issue remains: Not every frame has a minibuffer > window. OK. There's a long-standing comment to the contrary in choose_minibuf_frame (src/minibuf.c): /* I don't think that any frames may validly have a null * minibuffer window anymore. */ , so it looks like that comment is no longer valid. It needs changing/removing and the code it annotates seems to want fixing. There might well be other places in the earlier part of minibuf.c that assume a non-null ->minibuffer_window. Either the ->minibuffer_window of tootip frames must be given a sensible non-null value (is this practicable and sensible?), or the code needs fixing to not assume it. > martin -- Alan Mackenzie (Nuremberg, Germany).