GNU bug report logs - #31312
Segmentation fault with doom-emacs, NeoTree and Zoom

Previous Next

Package: emacs;

Reported by: Andrea Cardaci <cyrus.and <at> gmail.com>

Date: Sun, 29 Apr 2018 17:01:02 UTC

Severity: normal

Tags: confirmed, fixed

Fixed in version 26.1

Done: Noam Postavsky <npostavs <at> gmail.com>

Bug is archived. No further changes may be made.

Full log


Message #60 received at 31312 <at> debbugs.gnu.org (full text, mbox):

From: Eli Zaretskii <eliz <at> gnu.org>
To: martin rudalics <rudalics <at> gmx.at>
Cc: cyrus.and <at> gmail.com, npostavs <at> gmail.com, 31312 <at> debbugs.gnu.org
Subject: Re: bug#31312: Segmentation fault with doom-emacs, NeoTree and Zoom
Date: Wed, 02 May 2018 18:03:45 +0300
> Date: Wed, 02 May 2018 15:42:58 +0200
> From: martin rudalics <rudalics <at> gmx.at>
> CC: 31312 <at> debbugs.gnu.org, Andrea Cardaci <cyrus.and <at> gmail.com>
> 
>  > So we need the same defense after prepare_menu_bars as we
>  > have after do_pending_changes, I think.
> 
> If you mean something like
> 
>    if (WINDOWP (selected_window) && (w = XWINDOW (selected_window)) != sw)
>      sw = w;
> 
> I'm afraid that this would fail since selected_window has no buffer
> any more (or may have even been recycled already).

Is that a fact?  I might be mistaken, but my take on what Noam found
was that the selected window is OK, it's just that the window held in
W is dead (i.e. it was deleted inside the tempest that happened in
run_window_size_change_functions called by prepare_menu_bars).  So my
suggestion is to update W with the new selected window.

In general, if the selected window has no buffer, we are in deep
trouble, and not just in redisplay.  So I very much hope this is not
what happens here.




This bug report was last modified 7 years and 73 days ago.

Previous Next


GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.