From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!.POSTED!not-for-mail From: Levi Newsgroups: gmane.emacs.bugs Subject: bug#28862: Emacs 25.3.1 segmentation fault on killing *Colors* buffer Date: Sun, 15 Oct 2017 19:49:22 -0700 Message-ID: NNTP-Posting-Host: blaine.gmane.org Mime-Version: 1.0 Content-Type: multipart/alternative; boundary="001a113d362ecbbea7055ba10de2" X-Trace: blaine.gmane.org 1508138125 12736 195.159.176.226 (16 Oct 2017 07:15:25 GMT) X-Complaints-To: usenet@blaine.gmane.org NNTP-Posting-Date: Mon, 16 Oct 2017 07:15:25 +0000 (UTC) To: 28862@debbugs.gnu.org Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane.org@gnu.org Mon Oct 16 09:15:20 2017 Return-path: Envelope-to: geb-bug-gnu-emacs@m.gmane.org Original-Received: from lists.gnu.org ([208.118.235.17]) by blaine.gmane.org with esmtp (Exim 4.84_2) (envelope-from ) id 1e3zcG-0001ft-En for geb-bug-gnu-emacs@m.gmane.org; Mon, 16 Oct 2017 09:15:12 +0200 Original-Received: from localhost ([::1]:59709 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1e3zcM-0003Dk-2m for geb-bug-gnu-emacs@m.gmane.org; Mon, 16 Oct 2017 03:15:18 -0400 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:49914) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1e3zcB-0003Aw-45 for bug-gnu-emacs@gnu.org; Mon, 16 Oct 2017 03:15:09 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1e3zc7-00023Y-MM for bug-gnu-emacs@gnu.org; Mon, 16 Oct 2017 03:15:07 -0400 Original-Received: from debbugs.gnu.org ([208.118.235.43]:33682) by eggs.gnu.org with esmtps (TLS1.0:RSA_AES_128_CBC_SHA1:16) (Exim 4.71) (envelope-from ) id 1e3zc7-00023N-Hi for bug-gnu-emacs@gnu.org; Mon, 16 Oct 2017 03:15:03 -0400 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1e3zc7-0007CN-CK for bug-gnu-emacs@gnu.org; Mon, 16 Oct 2017 03:15:03 -0400 X-Loop: help-debbugs@gnu.org Resent-From: Levi Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Mon, 16 Oct 2017 07:15:03 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: report 28862 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: X-Debbugs-Original-To: submit@debbugs.gnu.org Original-Received: via spool by submit@debbugs.gnu.org id=B.150813809627622 (code B ref -1); Mon, 16 Oct 2017 07:15:03 +0000 Original-Received: (at submit) by debbugs.gnu.org; 16 Oct 2017 07:14:56 +0000 Original-Received: from localhost ([127.0.0.1]:42361 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1e3zbz-0007BS-B0 for submit@debbugs.gnu.org; Mon, 16 Oct 2017 03:14:55 -0400 Original-Received: from mail-oi0-f47.google.com ([209.85.218.47]:48743) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1e3vT6-0000YT-QP for submit@debbugs.gnu.org; Sun, 15 Oct 2017 22:49:29 -0400 Original-Received: by mail-oi0-f47.google.com with SMTP id m198so23076864oig.5 for ; Sun, 15 Oct 2017 19:49:28 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:from:date:message-id:subject:to; bh=88MQEba9Hov/wT1sbNui+DGvDfn2P260LiteyaGiS3o=; b=fcCaJS3Hq2EET5ucxWaVZSr7JO3cisNEUjBaUQyySTY1Z/iC+txwVM++rfeLwVTBRO wxzCk2RLcc7GPdEqCMqXR9l5AiE2otow+pYrXXqgd3tVVRxWwip38hzyuzCk4XgM27z2 /cZ6hxmhzxzcA5TxKAKOqANphnxX8KLwCWl1vGxsDxdnZAa+8KZSH4INHgxLvcjApQzr 9TbBCTgi13VkQ0/MkBLUtF6NczAqbB0jFQ5Ch9oVIntLF8/dYn5qISfuLx6H+Pj1Mlh5 OM+PcSJ97ILdcO6V3bMsFobmbuGgfn4mS9W8vmm+mxGTW6cHy4XuHdPJnm6mtQB0aJdh 9Qgw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:from:date:message-id:subject:to; bh=88MQEba9Hov/wT1sbNui+DGvDfn2P260LiteyaGiS3o=; b=M/u/tehAspYJCg+DjOmHVE8RBOXhMm5KoZfanI69lZZyZAN5/z891aY3rSD+d3MLVy hZTp3UNYleCtcV5OCuJdY8pdbtbnQAOpX0/kXRH69neJnbXk1MHmUqxPYOWmMKkdBh+Q cKyo2oNaElTwOXspFYXgsJKWno81+PamxcpBIJrIZFMYyCt+tX9jNqwidbP1R3tb9G3C 0uHFi5W40+VJu7gZxbLHKQ/pVp4JrSO73Zcvap4Xnm2lTxouJsTIcRNvGHU/yak4dbmx k+2jKqmPLRdNAVEASH6ZOvu6xA20QDSQY+tp2RMt4dQKk4Aru/kYvX3L093yRf1f13ck +cBQ== X-Gm-Message-State: AMCzsaVfX6n6nPtO2nkYEWmtcPQHDPegmvOq80I762Z6JkDMsMt802x9 5FgumPdCMmSypMQ456ewjho0uGdcbThjSWUKI/PfDg== X-Google-Smtp-Source: ABhQp+QyWmnssi1UKViRVjKLEi4DeBorMIpdgowZ7+b547vsHexfdW7YO7IIf4AaG4pHtsN8HFl4L1ewYJw28yDEx18= X-Received: by 10.202.216.69 with SMTP id p66mr4202895oig.126.1508122162870; Sun, 15 Oct 2017 19:49:22 -0700 (PDT) Original-Received: by 10.157.49.99 with HTTP; Sun, 15 Oct 2017 19:49:22 -0700 (PDT) X-Mailman-Approved-At: Mon, 16 Oct 2017 03:14:53 -0400 X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.2.x-3.x [generic] X-Received-From: 208.118.235.43 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.org@gnu.org Original-Sender: "bug-gnu-emacs" Xref: news.gmane.org gmane.emacs.bugs:138500 Archived-At: --001a113d362ecbbea7055ba10de2 Content-Type: text/plain; charset="UTF-8" Package: emacs Version: 25.3.1 I have encountered a very strange and niche bug that causes Emacs to segfault when a *Colors* buffer is killed that has been created through `M-x customize`, browsing for any face, and then clicking `Choose` for a face to modify. There are some extra requirements in order to get emacs to crash: - The *Colors* buffer must be separated into its own frame (ie. with `C-x 5 2`), as the only buffer viewed in the frame (it cannot be split). - The *Colors* buffer must be killed *while the frame is also being closed*. This can be done by evalutating the following elisp code to kill all buffers viewed by a frame when it is closed: (add-hook 'delete-frame-functions (lambda (frame) (dolist (elem (window-list frame)) (kill-buffer (window-buffer elem))))) The exact steps can be followed to reproduce the issue: 1) Run `emacs -Q` in a terminal with an X server running, spawning the X frontend for emacs 2) Paste the above code into the *scratch* buffer and evaluate it (with `M-x eval-buffer`). 3) Spawn a new frame (with `C-x 5 2`) 4) Enter the customization menus (with `M-x customize`) 5) Navigate to any face in the UI, for example `Emacs -> Faces -> Basic Faces -> Cursor face` 6) Expand the options for the face of interest and click on `Choose` for a color. The colors buffer should appear in a new window, splitting the frame in half. 7) Close the window containing the *Customize Group: ...*, such that the only buffer visible in the frame is the *Colors* buffer (I do this by right-clicking the modeline) 8) Close the frame via the window manager (`X` button, or some hotkey to close the X window). If the steps were followed on Emacs 25.3.1, emacs should crash. I found some other oddities where it wouldn't crash if you didn't follow the steps perfectly, and every once in a while it would lock up instead of crashing (but wouldn't use any CPU resources), or in even rarer occasions, work properly. But it segfaults most of the time in `emacs -Q`. On my custom configuration with the same hooks added to 'delete-frame-functions, emacs just hangs instead of segfaulting. I know nothing about Emacs' codebase, but I assume this is some oddity with how the *Colors* buffer is associated with the *Customize Group: ...* buffer that spawned it through the C code, and when the *Colors* buffer is killed in an odd way (ie. *while the frame containing it is being closed*), Emacs freaks out and does some undefined behaviour. This was obvserved on Linux (uname: 4.13.5-1-ARCH, xorg-server: 1.19.5-1, distribution: Arch Linux). GDB Backtrace: #0 0x00007f09e4b47bc7 in x86_64_fallback_frame_state (context=0xb91050, context=0xb91050, fs=0xb91140) at ./md-unwind-support.h:58 #1 0x00007f09e4b47bc7 in uw_frame_state_for (context=context@entry=0xb91050, fs=fs@entry=0xb91140) at /build/gcc-multilib/src/gcc/ libgcc/unwind-dw2.c:1257 #2 0x00007f09e4b49778 in _Unwind_Backtrace (trace=0x7f09e9f62c60 , trace_argument=0xb91300) at /build/gcc-multilib/src/gcc/ libgcc/unwind.inc:290 #3 0x00007f09e9f62dd8 in backtrace () at /usr/lib/libc.so.6 #4 0x000000000050907f in () #5 0x00000000004eefbc in () #6 0x000000000050771f in () #7 0x00000000005078e9 in () #8 0x0000000000507975 in () #9 0x00007f09ea42bda0 in () at /usr/lib/libpthread.so.0 #10 0x00007f0900000000 in () #11 0x00007f09eece5bcf in () at /usr/lib/libgobject-2.0.so.0 #12 0x00007f09eece697d in g_object_new_with_properties () at /usr/lib/libgobject-2.0.so.0 #13 0x00007f09eece6a7a in g_object_new () at /usr/lib/libgobject-2.0.so.0 #14 0x00007f09efede5f0 in () at /usr/lib/libgtk-3.so.0 #15 0x00007f09efecbe1d in () at /usr/lib/libgtk-3.so.0 #16 0x00007f09efecabd5 in () at /usr/lib/libgtk-3.so.0 #17 0x00007f09efecb9b5 in () at /usr/lib/libgtk-3.so.0 #18 0x00007f09efecb9cb in () at /usr/lib/libgtk-3.so.0 #19 0x00007f09efecb9cb in () at /usr/lib/libgtk-3.so.0 #20 0x00007f09efecb9cb in () at /usr/lib/libgtk-3.so.0 #21 0x00007f09efecb9cb in () at /usr/lib/libgtk-3.so.0 #22 0x00007f09efeb1d98 in () at /usr/lib/libgtk-3.so.0 #23 0x00007f09eece16f5 in g_closure_invoke () at /usr/lib/libgobject-2.0.so.0 #24 0x00007f09eecf50b0 in () at /usr/lib/libgobject-2.0.so.0 #25 0x00007f09eecf9696 in g_signal_emit_valist () at /usr/lib/libgobject-2.0.so.0 #26 0x00007f09eecfa920 in g_signal_emit () at /usr/lib/libgobject-2.0.so.0 #27 0x00007f09efa92f3f in () at /usr/lib/libgdk-3.so.0 #28 0x00007f09efa7d7c3 in () at /usr/lib/libgdk-3.so.0 #29 0x00007f09eea0fcb3 in () at /usr/lib/libglib-2.0.so.0 #30 0x00007f09eea110be in g_main_context_dispatch () at /usr/lib/libglib-2.0.so.0 #31 0x00000000005e0581 in () #32 0x00000000005a6e3d in () #33 0x000000000041ed44 in () #34 0x00000000004fb239 in () #35 0x00000000004fc0a0 in () #36 0x00000000004fdb44 in () #37 0x0000000000562a43 in () #38 0x00000000004ef3e5 in () #39 0x00000000005629c2 in () #40 0x00000000004ef37d in () #41 0x00000000004f3d6c in () #42 0x00000000004f409c in () #43 0x00000000004148b9 in () #44 0x00007f09e9e7ff6a in __libc_start_main () at /usr/lib/libc.so.6 #45 0x000000000041544a in () ... don't ask how I found this issue. My workflow is insane and consists of using a frame for every buffer spawned by emacs -- relevant xkcd . - Levi --001a113d362ecbbea7055ba10de2 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Package: emacs
Version: 25.3.1
=
I have encountered a very strange and niche bug that causes Emacs to=20 segfault when a *Colors* buffer is killed that has been created through=20 `M-x customize`, browsing for any face, and then clicking `Choose` for a face to modify. There are some extra requirements in order to get emacs to crash:

- The *Colors* buffer must be separated into its own frame (ie. with `C-x 5 2`), as the only buffer viewed in the frame=20 (it cannot be split).

- The *Colors* buffer must be killed = while the frame is also being closed. This can be done by evalutating t= he following elisp code to kill all buffers viewed by a frame when it is cl= osed:

(add-hook '= ;delete-frame-functions
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0 (lambda (frame)
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0 (dolist (elem (window-list frame))
=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 (kill-buffer (= window-buffer elem)))))

The exact steps can be followed to reproduce the is= sue:

1) Run `emacs -Q` in a terminal with an X server running, spawning the= X frontend for emacs

2) Paste the above code into the *scratch* buffer and= evaluate it (with `M-x eval-buffer`).

=
3) Spawn a new frame (with `C-x 5 2`)

4) Enter the customization menus (with `M-= x customize`)

5) Navigate to any = face in the UI, for example `Emacs -> Faces -> Basic Faces -> Curs= or face`

6) Expand the options for the face of interest and click on `Choose` for a color. The colors buffer should appear in a new window, splitting the=20 frame in half.

7) Close the window containing the *Customize Group: ...*, such that the=20 only buffer visible in the frame is the *Colors* buffer (I do this by=20 right-clicking the modeline)

8) C= lose the frame via the window manager (`X` button, or some hotkey to close = the X window).

If the steps were followed on Emacs 25.3.1, emacs should crash. I found=20 some other oddities where it wouldn't crash if you didn't follow th= e=20 steps perfectly, and every once in a while it would lock up instead of=20 crashing (but wouldn't use any CPU resources), or in even rarer=20 occasions, work properly. But it segfaults most of the time in `emacs=20 -Q`.

On my custom configuration w= ith the same hooks added to 'delete-frame-functions, emacs just hangs i= nstead of segfaulting.

I know nothing about Emacs' codebase, but I assume this is some oddity= =20 with how the *Colors* buffer is associated with the *Customize Group:=20 ...* buffer that spawned it through the C code, and when the *Colors*=20 buffer is killed in an odd way (ie. while the frame containing it is bei= ng closed), Emacs freaks out and does some undefined behaviour.

=
This was obvserved on Linux (uname: 4.13= .5-1-ARCH, xorg-server: 1.19.5-1, distribution: Arch Linux).<= /div>

GDB Backtrace:

#0=C2=A0 0x00007f09e4b47bc7 in x86_64_fallback_frame_state (context=3D0xb91050,=20 context=3D0xb91050, fs=3D0xb91140) at ./md-unwind-support.h:58
#1=C2=A0 = 0x00007f09e4b47bc7 in uw_frame_state_for (context=3Dcontext@entry=3D0x= b91050, fs=3Dfs@entry=3D0xb91140) at /build/gcc-multilib/src/gcc/libgc= c/unwind-dw2.c:1257
#2=C2=A0 0x00007f09e4b49778 in _Unwind_Backtrace (trace=3D0x7f09e9f62c60=20 <backtrace_helper>, trace_argument=3D0xb91300) at=20 /build/gcc-multilib/src/gcc/libgcc/unwind.inc:290
#3=C2=A0 0x00007f= 09e9f62dd8 in backtrace () at /usr/lib/libc.so.6
#4=C2=A0 0x000000000050= 907f in=C2=A0 ()
#5=C2=A0 0x00000000004eefbc in=C2=A0 ()
#6=C2=A0 0x0= 00000000050771f in=C2=A0 ()
#7=C2=A0 0x00000000005078e9 in=C2=A0 ()
#= 8=C2=A0 0x0000000000507975 in=C2=A0 ()
#9=C2=A0 0x00007f09ea42bda0 in &l= t;signal handler called> () at /usr/lib/libpthread.so.0
#10 0x00007f0= 900000000 in=C2=A0 ()
#11 0x00007f09eece5bcf in=C2=A0 () at /usr/lib/lib= gobject-2.0.so.0
#12 0x00007f09eece697d in g_object_new_with_properties = () at /usr/lib/libgobject-2.0.so.0
#13 0x00007f09eece6a7a in g_object_ne= w () at /usr/lib/libgobject-2.0.so.0
#14 0x00007f09efede5f0 in=C2=A0 () = at /usr/lib/libgtk-3.so.0
#15 0x00007f09efecbe1d in=C2=A0 () at /usr/lib= /libgtk-3.so.0
#16 0x00007f09efecabd5 in=C2=A0 () at /usr/lib/libgtk-3.s= o.0
#17 0x00007f09efecb9b5 in=C2=A0 () at /usr/lib/libgtk-3.so.0
#18 = 0x00007f09efecb9cb in=C2=A0 () at /usr/lib/libgtk-3.so.0
#19 0x00007f09e= fecb9cb in=C2=A0 () at /usr/lib/libgtk-3.so.0
#20 0x00007f09efecb9cb in= =C2=A0 () at /usr/lib/libgtk-3.so.0
#21 0x00007f09efecb9cb in=C2=A0 () a= t /usr/lib/libgtk-3.so.0
#22 0x00007f09efeb1d98 in=C2=A0 () at /usr/lib/= libgtk-3.so.0
#23 0x00007f09eece16f5 in g_closure_invoke () at /usr/lib/= libgobject-2.0.so.0
#24 0x00007f09eecf50b0 in=C2=A0 () at /usr/lib/libgo= bject-2.0.so.0
#25 0x00007f09eecf9696 in g_signal_emit_valist () at /usr= /lib/libgobject-2.0.so.0
#26 0x00007f09eecfa920 in g_signal_emit () at /= usr/lib/libgobject-2.0.so.0
#27 0x00007f09efa92f3f in=C2=A0 () at /usr/l= ib/libgdk-3.so.0
#28 0x00007f09efa7d7c3 in=C2=A0 () at /usr/lib/libgdk-3= .so.0
#29 0x00007f09eea0fcb3 in=C2=A0 () at /usr/lib/libglib-2.0.so.0#30 0x00007f09eea110be in g_main_context_dispatch () at /usr/lib/libglib-2= .0.so.0
#31 0x00000000005e0581 in=C2=A0 ()
#32 0x00000000005a6e3d in= =C2=A0 ()
#33 0x000000000041ed44 in=C2=A0 ()
#34 0x00000000004fb239 i= n=C2=A0 ()
#35 0x00000000004fc0a0 in=C2=A0 ()
#36 0x00000000004fdb44 = in=C2=A0 ()
#37 0x0000000000562a43 in=C2=A0 ()
#38 0x00000000004ef3e5= in=C2=A0 ()
#39 0x00000000005629c2 in=C2=A0 ()
#40 0x00000000004ef37= d in=C2=A0 ()
#41 0x00000000004f3d6c in=C2=A0 ()
#42 0x00000000004f40= 9c in=C2=A0 ()
#43 0x00000000004148b9 in=C2=A0 ()
#44 0x00007f09e9e7f= f6a in __libc_start_main () at /usr/lib/libc.so.6
#45 0x000000000041544a= in=C2=A0 ()

<= span style=3D"font-family:monospace,monospace">... don't ask how I found this issue. My workflow is insa= ne and consists of using a frame for every buffer spawned by emacs -- relevant xkcd.

- Levi
--001a113d362ecbbea7055ba10de2--