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