bug#28862: Emacs 25.3.1 segmentation fault on killing *Colors* buffer

bug#28862: Emacs 25.3.1 segmentation fault on killing *Colors* buffer

[Levi]

[-- Attachment #1: Type: text/plain, Size: 5351 bytes --]

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
<https://xkcd.com/1172/>.

- Levi

[-- Attachment #2: Type: text/html, Size: 8134 bytes --]

bug#28862: Emacs 25.3.1 segmentation fault on killing *Colors* buffer

[martin rudalics]

 > (add-hook 'delete-frame-functions
 >            (lambda (frame)
 >              (dolist (elem (window-list frame))
 >                (kill-buffer (window-buffer elem)))))

‘delete-frame-functions’ must be used with great care.  For example, I
can crash Emacs 25 by evaluating the following forms in row:

(defvar old-frame (selected-frame))

(defvar new-frame (make-frame))

(add-hook 'delete-frame-functions
	  (lambda (f) (delete-frame new-frame)))

(delete-frame old-frame)

Now if killing a buffer in ‘delete-frame-functions’ may delete a frame
because, for example, the buffer is shown in a dedicated window which is
the only window on that frame, you may run exactly in the scenario
described above.  I hopefully fixed that for Emacs 26 so if you could
try the release version ...

martin

bug#28862: Emacs 25.3.1 segmentation fault on killing *Colors* buffer

[Eli Zaretskii]

> Date: Mon, 16 Oct 2017 10:16:58 +0200
> From: martin rudalics <rudalics@gmx.at>
> 
> Now if killing a buffer in ‘delete-frame-functions’ may delete a frame
> because, for example, the buffer is shown in a dedicated window which is
> the only window on that frame, you may run exactly in the scenario
> described above.  I hopefully fixed that for Emacs 26 so if you could
> try the release version ...

FWIW, the recipe doesn't crash for me in Emacs 26.0.90, so I guess
your fix solved at least this case.

Thanks.

bug#28862: Emacs 25.3.1 segmentation fault on killing *Colors* buffer

[Levi]

[-- Attachment #1: Type: text/plain, Size: 6014 bytes --]

Hey, Emacs 26.0.90 seems to have a similar bug when going through the same
steps on my system. If other users can't reproduce this, it may also be
related to the window manager's behaviour -- although that would still be
strange.

With 26.0.90, Emacs always hangs when trying to reproduce the issue, and
prints to stderr: 'Fatal error 11: Segmentation fault'. Sending SIGTERM or
^C does not terminate the process, only killing it works.

I tried running emacs through GDB in order to get a backtrace, but couldn't
reproduce the crash there (memory corruption issue). Attaching to the
process with `gdb -p <pid>` allowed me to obtain this dump:

#0  0x00007f66ca0a038b in __lll_lock_wait_private () at /usr/lib/libc.so.6
#1  0x00007f66ca01c609 in _int_free () at /usr/lib/libc.so.6
#2  0x00007f66cc8a7a43 in xmlCleanupCharEncodingHandlers () at
/usr/lib/libxml2.so.2
#3  0x00007f66cc8c6819 in xmlCleanupParser () at /usr/lib/libxml2.so.2
#4  0x00000000005c7a95 in xml_cleanup_parser () at xml.c:266
#5  0x00000000004f5cf2 in shut_down_emacs (sig=sig@entry=11,
stuff=stuff@entry=0)
    at emacs.c:2122
#6  0x00000000004f5ec3 in terminate_due_to_signal (sig=sig@entry=11,
backtrace_limit=backtrace_limit@entry=40) at emacs.c:377
#7  0x000000000050e3ce in handle_fatal_signal (sig=sig@entry=11) at
sysdep.c:1768
#8  0x000000000050e5e8 in deliver_thread_signal (sig=11, handler=0x50e3c0
<handle_fatal_signal>) at sysdep.c:1742
#9  0x000000000050e66c in deliver_fatal_thread_signal (sig=<optimized out>)
    at sysdep.c:1780
#10 0x000000000050e66c in handle_sigsegv (sig=<optimized out>,
siginfo=<optimized out>, arg=<optimized out>) at sysdep.c:1865
#11 0x00007f66cac72da0 in <signal handler called> () at
/usr/lib/libpthread.so.0
#12 0x00007f66ca01afc3 in malloc_consolidate () at /usr/lib/libc.so.6
#13 0x00007f66ca01df52 in _int_malloc () at /usr/lib/libc.so.6
#14 0x00007f66ca01faf4 in malloc () at /usr/lib/libc.so.6
#15 0x00000000005eb6d5 in hybrid_malloc (size=<optimized out>) at
gmalloc.c:1734
#16 0x000000000054faad in lmalloc (size=4096) at alloc.c:1450
#17 0x000000000054faad in xmalloc (size=size@entry=4096) at alloc.c:846
#18 0x0000000000550bb3 in allocate_vector_block () at alloc.c:3063
#19 0x0000000000550bb3 in allocate_vector_from_block (nbytes=1160) at
alloc.c:3127
#20 0x0000000000550bb3 in allocate_vectorlike (len=144) at alloc.c:3332
#21 0x000000000055181d in allocate_vectorlike (len=144) at alloc.c:3376
#22 0x000000000055181d in allocate_vector (len=len@entry=144) at
alloc.c:3372
#23 0x0000000000551967 in Fmake_vector (length=length@entry=578,
init=init@entry=0)
    at alloc.c:3466
#24 0x0000000000575116 in concat (nargs=nargs@entry=1,
args=args@entry=0x7fff73dbe7f8,
target_type=Lisp_Vectorlike, last_special=last_special@entry=false) at
fns.c:648
#25 0x0000000000575260 in Fcopy_sequence (arg=<optimized out>) at fns.c:514
#26 0x00000000004334d2 in update_tool_bar (f=f@entry=0x114dc30
<bss_sbrk_buffer+5520464>, save_match_data=save_match_data@entry=false) at
xdisp.c:12272
#27 0x00000000004579d3 in update_tool_bar (save_match_data=false,
f=<optimized out>)
    at xdisp.c:12217
#28 0x00000000004579d3 in prepare_menu_bars () at xdisp.c:12054
#29 0x00000000004579d3 in redisplay_internal () at xdisp.c:13907
#30 0x00000000004591d5 in redisplay_preserve_echo_area
(from_where=from_where@entry=5) at xdisp.c:14602
#31 0x00000000004fff3a in read_char (commandflag=commandflag@entry=1,
map=map@entry=70360643, prev_event=0,
used_mouse_menu=used_mouse_menu@entry=0x7fff73dc027b,
end_time=end_time@entry=0x0) at keyboard.c:2478
#32 0x0000000000502dac in read_key_sequence
(keybuf=keybuf@entry=0x7fff73dc0370,
prompt=prompt@entry=0, dont_downcase_last=dont_downcase_last@entry=false,
can_return_switch_frame=can_return_switch_frame@entry=true,
fix_current_buffer=fix_current_buffer@entry=true, prevent_redisplay=prevent_
redisplay@entry=false, bufsize=30)
    at keyboard.c:9147
#33 0x00000000005047e4 in command_loop_1 () at keyboard.c:1368
#34 0x000000000056a8be in internal_condition_case (bfun=bfun@entry=0x5045c0
<command_loop_1>, handlers=handlers@entry=21024, hfun=hfun@entry=0x4fb4d0
<cmd_error>)
    at eval.c:1332
#35 0x00000000004f62a4 in command_loop_2 (ignore=ignore@entry=0) at
keyboard.c:1110
#36 0x000000000056a82d in internal_catch (tag=tag@entry=50880,
func=func@entry=0x4f6280 <command_loop_2>, arg=arg@entry=0) at eval.c:1097
#37 0x00000000004f623b in command_loop () at keyboard.c:1089
#38 0x00000000004fb0e3 in recursive_edit_1 () at keyboard.c:695
#39 0x00000000004fb3fe in Frecursive_edit () at keyboard.c:766
#40 0x0000000000419ffe in main (argc=<optimized out>, argv=0x7fff73dc0728)
    at emacs.c:1713

It looks like this time around the stack isn't corrupted, and symbol
information is there.

Another point is that during one of the runs (albiet with my own
configuration, rather than `emacs -Q`) is that I got the process to hang
with the following output instead:

*** Error in `./emacs': malloc(): memory corruption (fast):
0x0000000004066390 ***
Fatal error 6: Aborted

Is there a quick workaround I can use to avoid this crash for the time
being? I would like to close all visible buffers when a frame is
closed/deleted, like how I was initially doing so via
'delete-frame-functions.

Thanks in advance,

-Levi

On Mon, Oct 16, 2017 at 8:10 AM, Eli Zaretskii <eliz@gnu.org> wrote:

> > Date: Mon, 16 Oct 2017 10:16:58 +0200
> > From: martin rudalics <rudalics@gmx.at>
> >
> > Now if killing a buffer in ‘delete-frame-functions’ may delete a frame
> > because, for example, the buffer is shown in a dedicated window which is
> > the only window on that frame, you may run exactly in the scenario
> > described above.  I hopefully fixed that for Emacs 26 so if you could
> > try the release version ...
>
> FWIW, the recipe doesn't crash for me in Emacs 26.0.90, so I guess
> your fix solved at least this case.
>
> Thanks.
>

[-- Attachment #2: Type: text/html, Size: 7234 bytes --]

bug#28862: Emacs 25.3.1 segmentation fault on killing *Colors* buffer

[martin rudalics]

 > I tried running emacs through GDB in order to get a backtrace, but couldn't
 > reproduce the crash there (memory corruption issue). Attaching to the
 > process with `gdb -p <pid>` allowed me to obtain this dump:

Is this with emacs -Q and your original scenario, i.e., just the

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

addition?  If you simplify that to removing the ‘window-list’ call and
only kill the *Colors* buffer does the crash occur as well?

martin

bug#28862: Emacs 25.3.1 segmentation fault on killing *Colors* buffer

[Levi]

[-- Attachment #1: Type: text/plain, Size: 491 bytes --]

Yes, all the tests (except for the one mentioned where I used my own
config) were using `emacs -Q`. Attempting to remove the `window-list` call,
resulted in the following code:

(add-hook 'delete-frame-functions
          (lambda (frame)
            (kill-buffer "*Colors*")))

-- which did not prevent Emacs 26.0.90 from crashing if the given steps
were used.

Have you (or anyone else) been able to reproduce the issue? If not, I can
start looking at other potential factors on my system.

[-- Attachment #2: Type: text/html, Size: 793 bytes --]

bug#28862: Emacs 25.3.1 segmentation fault on killing *Colors* buffer

[martin rudalics]

 > Have you (or anyone else) been able to reproduce the issue? If not, I can
 > start looking at other potential factors on my system.

I was not able to reproduce it.  But I do not understand some parts of
your scenario:

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

Is 1) strictly necessary?

 > 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)

Can't you instead of 4)-7) simply run ‘list-colors-display’?

 > 8) Close the frame via the window manager (`X` button, or some hotkey to
 > close the X window).

Does C-x 5 0 not exhibit the bug?

In any case please use GDB to step through delete_frame.  If it survives
‘delete-frame-functions’ it should be easy to see where it crashes.

martin

bug#28862: Emacs 25.3.1 segmentation fault on killing *Colors* buffer

[Noam Postavsky]

tags 28862 + unreproducible
quit

martin rudalics <rudalics@gmx.at> writes:

>> Have you (or anyone else) been able to reproduce the issue? If not, I can
>> start looking at other potential factors on my system.
>
> I was not able to reproduce it.  But I do not understand some parts of
> your scenario:

I couldn't reproduce it here either.

bug#28862: Emacs 25.3.1 segmentation fault on killing *Colors* buffer

[Stefan Kangas]

martin rudalics <rudalics@gmx.at> writes:

>> Have you (or anyone else) been able to reproduce the issue? If not, I can
>> start looking at other potential factors on my system.
>
> I was not able to reproduce it.  But I do not understand some parts of
> your scenario:
>
>> 1) Run `emacs -Q` in a terminal with an X server running, spawning the X
>> frontend for emacs
>
> Is 1) strictly necessary?
>
>> 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)
>
> Can't you instead of 4)-7) simply run ‘list-colors-display’?
>
>> 8) Close the frame via the window manager (`X` button, or some hotkey to
>> close the X window).
>
> Does C-x 5 0 not exhibit the bug?
>
> In any case please use GDB to step through delete_frame.  If it survives
> ‘delete-frame-functions’ it should be easy to see where it crashes.
>
> martin

Hi Levi,

I've attempted to reproduce this on Emacs 26.2 and current master, but
haven't been able to.  Can you still reproduce it on Emacs 26.2, the
latest version of Emacs?  If yes, could you please look at the questions
posed by martin above?

Thanks,
Stefan Kangas

bug#28862: Emacs 25.3.1 segmentation fault on killing *Colors* buffer

[Stefan Kangas]

Stefan Kangas <stefan@marxist.se> writes:

> I've attempted to reproduce this on Emacs 26.2 and current master, but
> haven't been able to.  Can you still reproduce it on Emacs 26.2, the
> latest version of Emacs?  If yes, could you please look at the questions
> posed by martin above?

No reply in 2 months, so I'm therefore closing this as unreproducible.
If you still see this issue, please let us know so that we can re-open
the bug.

Thanks,
Stefan Kangas