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

Previous Next

Package: emacs;

Reported by: Ship Mints <shipmints <at> gmail.com>

Date: Sat, 31 May 2025 21:47:01 UTC

Severity: normal

Done: Eli Zaretskii <eliz <at> gnu.org>

Bug is archived. No further changes may be made.

Full log


View this message in rfc822 format

From: Ship Mints <shipmints <at> gmail.com>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: 78654 <at> debbugs.gnu.org, ben <at> bensimms.moe
Subject: bug#78654: NS Emacs crashing (since stipples?)
Date: Sun, 1 Jun 2025 10:40:27 -0400
[Message part 1 (text/plain, inline)]
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.

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

This bug report was last modified 45 days ago.

Previous Next


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