[debbugs-tracker] bug#28862: closed (Emacs 25.3.1 segmentation fault on

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 <backtrace_helper>, 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 <signal handler called> () 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

From:	GNU bug Tracking System
Subject:	[debbugs-tracker] bug#28862: closed (Emacs 25.3.1 segmentation fault on killing Colors buffer)
Date:	Fri, 23 Aug 2019 06:29:01 +0000