bug-gnu-emacs
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

bug#43886: 28.0.50; daemon segfaults when loading theme as second emacsc


From: Sam Brightman
Subject: bug#43886: 28.0.50; daemon segfaults when loading theme as second emacsclient connects
Date: Sat, 10 Oct 2020 08:09:56 +0100

That patch indeed prevents a crash but the second client exiting seems
a bit strong/unhelpful - how would you suggest changing the theme more
appropriately?

I believe code of this type was introduced because new frames were not
getting themed properly:

https://stackoverflow.com/questions/18904529/after-emacs-deamon-i-can-not-see-new-theme-in-emacsclient-frame-it-works-fr

Some of the later answers indeed try to avoid repeatedly loading the
theme. However - even removing that hook - it is now impossible to
load a theme when a client is suspended (which is basically always for
me - I'll have half a dozen or more clients open at any time, one of
them will be suspended).

On Fri, 9 Oct 2020 at 20:32, Eli Zaretskii <eliz@gnu.org> wrote:
>
> > From: Sam Brightman <sam.brightman@gmail.com>
> > Date: Fri, 9 Oct 2020 16:58:38 +0100
> >
> > 1. Start emacs -Q -l test.el --fg-daemon. (see test.el below)
> > 2. Connect with emacsclient -t.
> > 3. Suspend the first client.
> > 4. Connect with another emacsclient -t.
> > 5. Server crashes.
> >
> > I've seen other variations, and sometimes seen many clients connect
> > without issue and then suddenly another one causes it to crash. This
> > method appears to reproduce every time. I am connecting the client
> > from another mate-terminal tab. It also works in the same terminal
> > with --bg-daemon.
> >
> > test.el:
> >
> > (defun my/after-make-frame-functions-hook (frame)
> >   (with-selected-frame frame
> >     (load-theme 'tango-dark t)))
> >
> > (if (daemonp)
> >     (add-hook 'after-make-frame-functions 
> > 'my/after-make-frame-functions-hook))
>
> This after-make-frame-function makes no sense: a theme is turned on or
> off globally, so you don't need to do that for every frame, just for
> the first one.
>
> Of course, Emacs shouldn't crash, so I have now made a change on the
> emacs-27 branch which should simply signal an error in this case (it
> is possible you will not see the error message, just see the 2nd
> client exit immediately).
>
> (In general, when a TTY frame is suspended, doing anything that
> iterates over all the frames might produce surprising results.)
>
> Thanks.



-- 
sam brightman





reply via email to

[Prev in Thread] Current Thread [Next in Thread]