From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.blaine.gmane.org!not-for-mail From: Alex =?UTF-8?Q?Benn=C3=A9e?= Newsgroups: gmane.emacs.bugs Subject: bug#48337: Fwd: 28.0.50; Emacs crashing randomly (possibly minibuffer activity related) Date: Tue, 11 May 2021 07:51:20 +0100 Message-ID: References: <87tunasd2u.fsf@linaro.org> <83fsyu57oj.fsf@gnu.org> Mime-Version: 1.0 Content-Type: multipart/alternative; boundary="0000000000000f2b4305c20853ea" Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="18618"; mail-complaints-to="usenet@ciao.gmane.io" Cc: Alan Mackenzie , 48337@debbugs.gnu.org To: Eli Zaretskii Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane-mx.org@gnu.org Tue May 11 08:52:22 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 1lgMFi-0004hN-6t for geb-bug-gnu-emacs@m.gmane-mx.org; Tue, 11 May 2021 08:52:22 +0200 Original-Received: from localhost ([::1]:36406 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1lgMFh-0005U1-26 for geb-bug-gnu-emacs@m.gmane-mx.org; Tue, 11 May 2021 02:52:21 -0400 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]:45128) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1lgMFO-0005Rb-KG for bug-gnu-emacs@gnu.org; Tue, 11 May 2021 02:52:03 -0400 Original-Received: from debbugs.gnu.org ([209.51.188.43]:51516) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.90_1) (envelope-from ) id 1lgMFO-0000kn-Cq for bug-gnu-emacs@gnu.org; Tue, 11 May 2021 02:52:02 -0400 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1lgMFO-0007Wu-Aj for bug-gnu-emacs@gnu.org; Tue, 11 May 2021 02:52:02 -0400 X-Loop: help-debbugs@gnu.org Resent-From: Alex =?UTF-8?Q?Benn=C3=A9e?= Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Tue, 11 May 2021 06:52:02 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 48337 X-GNU-PR-Package: emacs Original-Received: via spool by 48337-submit@debbugs.gnu.org id=B48337.162071590228911 (code B ref 48337); Tue, 11 May 2021 06:52:02 +0000 Original-Received: (at 48337) by debbugs.gnu.org; 11 May 2021 06:51:42 +0000 Original-Received: from localhost ([127.0.0.1]:34829 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1lgMF3-0007WF-KP for submit@debbugs.gnu.org; Tue, 11 May 2021 02:51:42 -0400 Original-Received: from mail-lf1-f47.google.com ([209.85.167.47]:40608) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1lgMF0-0007Vz-Rd for 48337@debbugs.gnu.org; Tue, 11 May 2021 02:51:39 -0400 Original-Received: by mail-lf1-f47.google.com with SMTP id c3so27062299lfs.7 for <48337@debbugs.gnu.org>; Mon, 10 May 2021 23:51:38 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=linaro.org; s=google; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=fCHU5QnZa2Jm/YpRrGtV83EibbZnwefAg3z9Q+NXoK0=; b=stVXBc8RwoxWRgqwR+sl+1g5Ky+SxEaRCooGJqtNidSABQ1YG35D8c6rNPkUj0IdbB IpDOVBhBZNKimEHDtgP7GYMPxop/ydim6zLSjo2XxT9WmbAjxkAY4iYCYtuTJe7K7s8/ Grui0OTCnfVJ8eV7vRFFuXbk7ME9qq3GVWnz05rUCE7XGWfx8t3zICn15LQCUNu/M241 ZqF46s5Q71PNVdzrIxuwoKGUr95yelj1IcOyY++D86h8RbxJkpmkvYNswo3XO8PAnhcY cMz+26FKqJ0SHif33Kn7F4WpG1Cg/cooG8+SPoD7Z0GwAA+miyONeZhg+XJC2tPakiBR r5Vg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=fCHU5QnZa2Jm/YpRrGtV83EibbZnwefAg3z9Q+NXoK0=; b=TyR/poDEerGsvrryyDZtPzEZ+h5ws0Gv4tEpaUheCge+D6J5hpopnMom1gGVQsSF43 5aEDvnCd2eFLlixw+1tXbNVw/aYbNmuIIsDofgELGWS/m1A+E6OtAwMcMK2As363ekId eSurNvUvec1ws4vPz4psT2Ai7Yd0k3DgI6cMavB8YANL8+OiVF7dtkvAw9o4u2vbjgk3 nUKFmI/SMOEvYQ2DEuMr88GRbTcngJ4Q/fK3jp4pDf/2nvK/eLe49wK2Ik9DicyvWoIL kvD5kFR3RZ9MPUbtoseKvOVcMwXvdgIPLCMXUk9OfqntuiUgGzwEbo7nIeqwfdj/KRM1 4yUg== X-Gm-Message-State: AOAM531xw1zx6K8AgvQGmxwumO99XzmOOdDXLyfJ18QISVbunJ+RCWBj WGJ5pYtjURGsZptkbdHRtmZh0u2bkz1Mri4S1dM7vQ== X-Google-Smtp-Source: ABdhPJw+Qj3SrpuTTeIuxZeJb/WM0Da4XuqI2cXT1kPca936mhYzSLy7aG8t6RT2DZ9YltbylOnHBYgNvoHirIn7zAE= X-Received: by 2002:ac2:522b:: with SMTP id i11mr17863446lfl.93.1620715892576; Mon, 10 May 2021 23:51:32 -0700 (PDT) In-Reply-To: <83fsyu57oj.fsf@gnu.org> 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:206202 Archived-At: --0000000000000f2b4305c20853ea Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable I can now recreate at will with a magit sequence (l o hackbox/ TAB) which triggers a minibuffer re-size to accommodate the list of git branches: (gdb) info frame 0 Stack frame at 0x7fffffffb2e0: rip =3D 0x5555556a80ef in Factive_minibuffer_window (minibuf.c:230); saved rip =3D 0x5555556f52ab called by frame at 0x7fffffffb340 source language c. Arglist at 0x7fffffffb2c8, args: Locals at 0x7fffffffb2c8, Previous frame's sp is 0x7fffffffb2e0 Saved registers: rip at 0x7fffffffb2d8 (gdb) x/5i $pc =3D> 0x5555556a80ef : mov -0x3(%rax),%r10 0x5555556a80f3 : lea -0x3(%rdx),%eax 0x5555556a80f6 : test $0x7,%al 0x5555556a80f8 : jne 0x5555556a8153 0x5555556a80fa : nopw 0x0(%rax,%rax,1) (gdb) p/x $rax $4 =3D 0x0 (gdb) p/x $r10 $5 =3D 0x7fffeece9c6d (gdb) l 225 Lisp_Object innermost_MB; 226 227 if (!minibuf_level) 228 return Qnil; 229 230 innermost_MB =3D nth_minibuffer (minibuf_level); 231 FOR_EACH_FRAME (frames, frame) 232 { 233 f =3D XFRAME (frame); 234 if (FRAME_LIVE_P (f) (gdb) p minibuf_level $6 =3D 2 (gdb) p Vminibuffer_list $7 =3D (Lisp_Object) 0x555555c9aca3 (gdb) p $* A syntax error in expression, near `'. (gdb) p *$ $8 =3D (gdb) Let me know if you want something else. On Tue, 11 May 2021 at 03:24, Eli Zaretskii wrote: > > From: Alex Benn=C3=A9e > > Date: Mon, 10 May 2021 20:30:58 +0100 > > Cc: Alan Mackenzie > > > > It seems my mail client left this in the sent folder but never actually > sent it: > > > > I haven't been able to find a reproduction as the bug hits fairly > > randomly hence I'm running in my normal init.el heavy environment. > > That said there shouldn't be anything in lisp that could cause a > > segfault in the core C code. > > > > This only started happening this week after a recent update from > > master (I update every Monday). The only change I could see that migh= t > > be related was f608b4b93 (Prevent the selected window being a dead > > mini-window when switching frames). > > > > Unfortunately no symbols. However both core dumps so far have seen th= e > > same null XCAR being called from nth_minibuffer: > > > > #0 0x00007f4384f585cb in raise (sig=3Dsig@entry=3D11) at > ../sysdeps/unix/sysv/linux/raise.c:50 > > set =3D {__val =3D {18446744067266837247, 0 }} > > pid =3D > > tid =3D > > #1 0x000055b6738bf530 in terminate_due_to_signal (sig=3Dsig@entry=3D= 11, > > backtrace_limit=3Dbacktrace_limit@entry=3D40) at emacs.c:437 > > #2 0x000055b6738bf97d in handle_fatal_signal (sig=3Dsig@entry=3D11) = at > sysdep.c:1762 > > #3 0x000055b6739b8ca8 in deliver_thread_signal (sig=3Dsig@entry=3D11= , > handler=3D0x55b6738bf972 > > ) at sysdep.c:1754 > > #4 0x000055b6739b8d29 in deliver_fatal_thread_signal (sig=3D11) at > sysdep.c:1867 > > fatal =3D > > #5 0x000055b6739b8d29 in handle_sigsegv (sig=3D11, siginfo=3D out>, arg=3D) at > > sysdep.c:1867 > > fatal =3D > > #6 0x00007f4384f58730 in () at > /lib/x86_64-linux-gnu/libpthread.so.0 > > #7 0x000055b6739ce0ef in XCAR (c=3D0x0) at lisp.h:1420 > > tail =3D 0x0 > > frames =3D > > frame =3D > > f =3D > > innermost_MB =3D > > #8 0x000055b6739ce0ef in nth_minibuffer (depth=3D) at > minibuf.c:972 > > tail =3D 0x0 > > frames =3D > > frame =3D > > f =3D > > innermost_MB =3D > > Please show the Lisp value of Vminibuffer_list. > --=20 Alex Benn=C3=A9e KVM/QEMU Hacker for Linaro --0000000000000f2b4305c20853ea Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
I can now recreate at will with a magit sequence (l o= hackbox/ TAB) which triggers a minibuffer re-size to accommodate the list = of git branches:

(gdb) info frame 0
Stack frame= at 0x7fffffffb2e0:
=C2=A0rip =3D 0x5555556a80ef in Factive_minibuffer_w= indow (minibuf.c:230); saved rip =3D 0x5555556f52ab
=C2=A0called by fram= e at 0x7fffffffb340
=C2=A0source language c.
=C2=A0Arglist at 0x7ffff= fffb2c8, args:
=C2=A0Locals at 0x7fffffffb2c8, Previous frame's sp i= s 0x7fffffffb2e0
=C2=A0Saved registers:
=C2=A0 rip at 0x7fffffffb2d8<= br>(gdb) x/5i $pc
=3D> 0x5555556a80ef <Factive_minibuffer_window+7= 9>: =C2=A0 =C2=A0 =C2=A0 mov =C2=A0 =C2=A0-0x3(%rax),%r10
=C2=A0 =C2= =A00x5555556a80f3 <Factive_minibuffer_window+83>: =C2=A0 =C2=A0 =C2= =A0 lea =C2=A0 =C2=A0-0x3(%rdx),%eax
=C2=A0 =C2=A00x5555556a80f6 <Fac= tive_minibuffer_window+86>: =C2=A0 =C2=A0 =C2=A0 test =C2=A0 $0x7,%al=C2=A0 =C2=A00x5555556a80f8 <Factive_minibuffer_window+88>: =C2=A0 = =C2=A0 =C2=A0 jne =C2=A0 =C2=A00x5555556a8153 <Factive_minibuffer_window= +179>
=C2=A0 =C2=A00x5555556a80fa <Factive_minibuffer_window+90>= ;: =C2=A0 =C2=A0 =C2=A0 nopw =C2=A0 0x0(%rax,%rax,1)
(gdb) p/x $rax
$= 4 =3D 0x0
(gdb) p/x $r10
$5 =3D 0x7fffeece9c6d
(gdb) l
225 =C2= =A0 =C2=A0 =C2=A0 Lisp_Object innermost_MB;
226
227 =C2=A0 =C2=A0 =C2= =A0 if (!minibuf_level)
228 =C2=A0 =C2=A0 =C2=A0 =C2=A0 return Qnil;
= 229
230 =C2=A0 =C2=A0 =C2=A0 innermost_MB =3D nth_minibuffer (minibuf_le= vel);
231 =C2=A0 =C2=A0 =C2=A0 FOR_EACH_FRAME (frames, frame)
232 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 {
233 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 f =3D = XFRAME (frame);
234 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 if (FRAME_LIVE_P = (f)
(gdb) p minibuf_level
$6 =3D 2
(gdb) p Vminibuffer_list
$7 = =3D (Lisp_Object) 0x555555c9aca3
(gdb) p $*
A syntax error in express= ion, near `'.
(gdb) p *$
$8 =3D <incomplete type>
(gdb)<= /div>

Let me know if you want something else.
<= /div>
O= n Tue, 11 May 2021 at 03:24, Eli Zaretskii <eliz@gnu.org> wrote:
> From: Alex Benn=C3=A9e <alex.bennee@linaro.org>
> Date: Mon, 10 May 2021 20:30:58 +0100
> Cc: Alan Mackenzie <acm@muc.de>
>
> It seems my mail client left this in the sent folder but never actuall= y sent it:
>
>=C2=A0 =C2=A0I haven't been able to find a reproduction as the bug = hits fairly
>=C2=A0 =C2=A0randomly hence I'm running in my normal init.el heavy = environment.
>=C2=A0 =C2=A0That said there shouldn't be anything in lisp that cou= ld cause a
>=C2=A0 =C2=A0segfault in the core C code.
>
>=C2=A0 =C2=A0This only started happening this week after a recent updat= e from
>=C2=A0 =C2=A0master (I update every Monday). The only change I could se= e that might
>=C2=A0 =C2=A0be related was f608b4b93 (Prevent the selected window bein= g a dead
>=C2=A0 =C2=A0mini-window when switching frames).
>
>=C2=A0 =C2=A0Unfortunately no symbols. However both core dumps so far h= ave seen the
>=C2=A0 =C2=A0same null XCAR being called from nth_minibuffer:
>
>=C2=A0 =C2=A0#0=C2=A0 0x00007f4384f585cb in raise (sig=3Dsig@entry=3D11= ) at ../sysdeps/unix/sysv/linux/raise.c:50
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0set =3D {__val =3D {1844674406= 7266837247, 0 <repeats 15 times>}}
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0pid =3D <optimized out><= br> >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0tid =3D <optimized out><= br> >=C2=A0 =C2=A0#1=C2=A0 0x000055b6738bf530 in terminate_due_to_signal (si= g=3Dsig@entry=3D11,
> backtrace_limit=3Dbacktrace_limit@entry=3D40) at emacs.c:437
>=C2=A0 =C2=A0#2=C2=A0 0x000055b6738bf97d in handle_fatal_signal (sig=3D= sig@entry=3D11) at sysdep.c:1762
>=C2=A0 =C2=A0#3=C2=A0 0x000055b6739b8ca8 in deliver_thread_signal (sig= =3Dsig@entry=3D11, handler=3D0x55b6738bf972
> <handle_fatal_signal>) at sysdep.c:1754
>=C2=A0 =C2=A0#4=C2=A0 0x000055b6739b8d29 in deliver_fatal_thread_signal= (sig=3D11) at sysdep.c:1867
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0fatal =3D <optimized out>= ;
>=C2=A0 =C2=A0#5=C2=A0 0x000055b6739b8d29 in handle_sigsegv (sig=3D11, s= iginfo=3D<optimized out>, arg=3D<optimized out>) at
> sysdep.c:1867
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0fatal =3D <optimized out>= ;
>=C2=A0 =C2=A0#6=C2=A0 0x00007f4384f58730 in <signal handler called&g= t; () at /lib/x86_64-linux-gnu/libpthread.so.0
>=C2=A0 =C2=A0#7=C2=A0 0x000055b6739ce0ef in XCAR (c=3D0x0) at lisp.h:14= 20
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0tail =3D 0x0
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0frames =3D <optimized out&g= t;
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0frame =3D <optimized out>= ;
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0f =3D <optimized out> >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0innermost_MB =3D <optimized= out>
>=C2=A0 =C2=A0#8=C2=A0 0x000055b6739ce0ef in nth_minibuffer (depth=3D<= ;optimized out>) at minibuf.c:972
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0tail =3D 0x0
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0frames =3D <optimized out&g= t;
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0frame =3D <optimized out>= ;
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0f =3D <optimized out> >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0innermost_MB =3D <optimized= out>

Please show the Lisp value of Vminibuffer_list.


--
Alex Benn=C3=A9e
KVM/QEMU Hacker for Linaro
--0000000000000f2b4305c20853ea--