GNU bug report logs - #78654
NS Emacs crashing (since stipples?)

Previous Next

Full log

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

From: Stéphane Marks <shipmints <at> gmail.com>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: 78654 <at> debbugs.gnu.org, ben <at> bensimms.moe
Subject: Re: bug#78654: NS Emacs crashing (since stipples?)
Date: Wed, 4 Jun 2025 12:34:24 -0400

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

On Sun, Jun 1, 2025 at 10:40 AM Ship Mints <shipmints <at> gmail.com> wrote:

> On Sun, Jun 1, 2025 at 6:06 AM Ship Mints <shipmints <at> gmail.com> wrote:
>
>> On Sun, Jun 1, 2025 at 1:27 AM Eli Zaretskii <eliz <at> gnu.org> wrote:
>>
>>> > Cc: ben <at> bensimms.moe
>>> > From: Ship Mints <shipmints <at> gmail.com>
>>> > Date: Sat, 31 May 2025 17:46:11 -0400
>>> >
>>> > I'm thinking it might have been this (I cc'd Ben) commit
>>> 9cbbdcee132588a11dc03c3da371176aaa13927c it's
>>> > the only one that looks relevant.  That said, it is possible I'm
>>> tickling a bug that's been there longer.
>>> >
>>> > I pulled a master today and recompiled from clean and it still
>>> happens.  It's a bit spurious, but regular over
>>> > the last few days.  There are no stipples used in the buffer in
>>> question, so this looks like a side effect of that
>>> > change, I'm guessing.  There are specified spaces in the body of the
>>> buffer and also in the header-line that
>>> > are "stretch" glyphs.
>>> >
>>> > This comes up as I go through a battery of tests for the revised
>>> vtable that has image content in a test jig
>>> > and with multiple vtables sharing the same buffer (I doubt that has
>>> any bearing).
>>> >
>>> > I will try to see if I can reproduce without images if that indicates
>>> anything.
>>> >
>>> > $ uname -a
>>> >
>>> > Darwin host.local 21.6.0 Darwin Kernel Version 21.6.0: Mon Jun 24
>>> 00:56:10 PDT 2024;
>>> > root:xnu-8020.240.18.709.2~1/RELEASE_X86_64 x86_64
>>> >
>>> > * thread #1, queue = 'com.apple.main-thread', stop reason =
>>> EXC_BAD_ACCESS (code=1, address=0xa8)
>>> >   * frame #0: 0x00000001000e79bb
>>> emacs`prepare_face_for_display(f=0x0000000102f41b70,
>>> > face=0x0000000000000000) at xfaces.c:4657:16 [opt]
>>> >     frame #1: 0x000000010025d599
>>> emacs`ns_draw_stretch_glyph_string(s=0x00007ff7bfef9eb0) at
>>> > nsterm.m:4176:8 [opt]
>>> >     frame #2: 0x000000010025a532
>>> emacs`ns_draw_glyph_string(s=0x00007ff7bfef9eb0) at
>>> > nsterm.m:4571:7 [opt]
>>>
>>> This code:
>>>
>>>           if (s->row->mouse_face_p
>>>               && cursor_in_mouse_face_p (s->w))
>>>             {
>>>               face = FACE_FROM_ID_OR_NULL (s->f,
>>>                                            MOUSE_HL_INFO
>>> (s->f)->mouse_face_face_id);
>>>
>>>               if (!s->face)
>>>                 face = FACE_FROM_ID (s->f, MOUSE_FACE_ID);
>>>               prepare_face_for_display (s->f, face);
>>>
>>> seems to have a thinko: it should say this instead:
>>>
>>>           if (s->row->mouse_face_p
>>>               && cursor_in_mouse_face_p (s->w))
>>>             {
>>>               face = FACE_FROM_ID_OR_NULL (s->f,
>>>                                            MOUSE_HL_INFO
>>> (s->f)->mouse_face_face_id);
>>>
>>>               if (!face)  <<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<
>>>                 face = FACE_FROM_ID (s->f, MOUSE_FACE_ID);
>>>               prepare_face_for_display (s->f, face);
>>>
>>> Can you try that change?
>>>
>>
>> Making a normal build now.  Will test today/tomorrow.
>>
>
> So far, so good.  I'll give it more time before declaring success.  Thank
> you for the fast patch.
>

I have not seen this recur.  Would you prefer I submit a patch for this or
would you handle this?

-Stéphane

[Message part 2 (text/html, inline)]

Previous Next

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