GNU bug report logs - #75056
31.0.50; tty-child-frames with server / multiple clients possible hangs

Previous Next

Full log

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

From: Gerd Möllmann <gerd.moellmann <at> gmail.com>
To: martin rudalics <rudalics <at> gmx.at>
Cc: Eli Zaretskii <eliz <at> gnu.org>, lenbok <at> gmail.com, 75056 <at> debbugs.gnu.org
Subject: Re: bug#75056: 31.0.50; tty-child-frames with server / multiple
 clients possible hangs
Date: Wed, 29 Jan 2025 08:48:56 +0100

[Message part 1 (text/plain, inline)]

Gerd Möllmann <gerd.moellmann <at> gmail.com> writes:

>>> (make-frame '((window-system . x)))
>>>
>>> move to the graphical and back to the tty frame	I get a crash like
>>>
>>> #0  terminate_due_to_signal (sig=6, backtrace_limit=2147483647) at ../../src/emacs.c:432
>
> FWIW, I tried the equivalent with (window-system . ns) here, and
> couldn't provoke the assertion.

Using the right worktree helped.

Taking a closer look at tty_set_cursor, using the selected frame here
doesn't make sense to me. I don't see a good reason why the selected
frame has to have anything to do with where to place the cursor in an
updated frame. That looks more like a left-over from times before
multi-tty.

Could you please try the attached, Martin? The first one is what I think
it the fix. The second one is a cleanup that leads to more checks
without having GLYPH_DEBUG. If this also work for you, I'll put that in
master.

(I see a "flicker" of the tty frame after the make-frame. That is also
the case in Emacs 30.)

[0001-Don-t-use-selected-frame-in-tty_set_cursor.patch (text/x-patch, attachment)]

[0002-Replace-two-macros-with-functions-in-dispnew.c.patch (text/x-patch, attachment)]

Previous Next

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