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>
To reply to this bug, email your comments to 78654 AT debbugs.gnu.org.
There is no need to reopen the bug first.
Toggle the display of automated, internal messages from the tracker.
View this report as an mbox folder, status mbox, maintainer mbox
bug-gnu-emacs <at> gnu.org:bug#78654; Package emacs.
(Sat, 31 May 2025 21:47:01 GMT) Full text and rfc822 format available.Ship Mints <shipmints <at> gmail.com>:bug-gnu-emacs <at> gnu.org.
(Sat, 31 May 2025 21:47:01 GMT) Full text and rfc822 format available.Message #5 received at submit <at> debbugs.gnu.org (full text, mbox):
From: Ship Mints <shipmints <at> gmail.com> To: bug-gnu-emacs <at> gnu.org Cc: ben <at> bensimms.moe Subject: NS Emacs crashing (since stipples?) Date: Sat, 31 May 2025 17:46:11 -0400
[Message part 1 (text/plain, inline)]
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]
frame #3: 0x000000010004bab4 emacs`draw_glyphs(w=0x0000000112f01140,
x=917, row=<unavailable>, area=TEXT_AREA, start=<unavailable>,
end=<unavailable>, hl=DRAW_CURSOR, overlaps=0) at xdisp.c:31666:5 [opt]
frame #4: 0x00000001000501d1
emacs`draw_phys_cursor_glyph(w=0x0000000112f01140, row=0x0000000181f1e100,
hl=DRAW_CURSOR) at xdisp.c:34369:12 [opt]
frame #5: 0x000000010025c091
emacs`ns_draw_window_cursor(w=0x0000000112f01140,
glyph_row=0x0000000181f1e100, x=<unavailable>, y=<unavailable>,
cursor_type=<unavailable>, cursor_width=<unavailable>, on_p=<unavailable>,
active_p=true) at nsterm.m:3126:7 [opt]
frame #6: 0x0000000100050d78
emacs`display_and_set_cursor(w=0x0000000112f01140, on=true, hpos=0, vpos=1,
x=0, y=21) at xdisp.c:34637:5 [opt]
frame #7: 0x000000010000b71b
emacs`gui_update_window_end(w=0x0000000112f01140, cursor_on_p=true,
mouse_face_overwritten_p=true) at dispnew.c:4653:2 [opt]
frame #8: 0x000000010000a931 emacs`update_window(w=<unavailable>) at
dispnew.c:4587:3 [opt]
frame #9: 0x000000010000effc
emacs`update_window_tree(w=0x0000000112f01140) at dispnew.c:4234:2 [opt]
frame #10: 0x000000010000efbe
emacs`update_window_tree(w=0x0000000113224260) at dispnew.c:4232:2 [opt]
frame #11: 0x0000000100009257 emacs`update_frame [inlined]
update_window_frame(f=0x0000000102f41b70) at dispnew.c:3866:3 [opt]
frame #12: 0x00000001000091e3 emacs`update_frame(f=0x0000000102f41b70,
inhibit_scrolling=<unavailable>) at dispnew.c:4118:5 [opt]
frame #13: 0x0000000100037573 emacs`redisplay_internal at
xdisp.c:17736:5 [opt]
frame #14: 0x000000010003d0b6
emacs`redisplay_preserve_echo_area(from_where=9) at xdisp.c:18001:5 [opt]
frame #15: 0x00000001001eed97
emacs`wait_reading_process_output(time_limit=<unavailable>, nsecs=0,
read_kbd=<unavailable>, do_display=true, wait_for_cell=0x0000000000000000,
wait_proc=0x0000000000000000, just_wait_proc=0) at process.c:5457:3 [opt]
frame #16: 0x000000010000ca35 emacs`sit_for(timeout=<unavailable>,
reading=true, display_option=1) at dispnew.c:6979:7 [opt]
frame #17: 0x00000001000fefd1 emacs`read_char(commandflag=1,
map=0x000000010f3b77c3, prev_event=0x0000000000000000,
used_mouse_menu=0x00007ff7bfefc46f, end_time=0x0000000000000000) at
keyboard.c:2925:11 [opt]
frame #18: 0x00000001000fb4b4
emacs`read_key_sequence(keybuf=0x00007ff7bfefc560, prompt=<unavailable>,
dont_downcase_last=false, can_return_switch_frame=true,
fix_current_buffer=true, prevent_redisplay=<unavailable>,
disable_text_conversion_p=<unavailable>) at keyboard.c:10848:12 [opt]
frame #19: 0x00000001000f9529 emacs`command_loop_1 at
keyboard.c:1424:15 [opt]
frame #20: 0x000000010019197b
emacs`internal_condition_case(bfun=(emacs`command_loop_1 at
keyboard.c:1319), handlers=0x0000000000000090, hfun=(emacs`cmd_error at
keyboard.c:965)) at eval.c:1684:25 [opt]
frame #21: 0x00000001000f915e
emacs`command_loop_2(handlers=0x0000000000000090) at keyboard.c:1163:11
[opt]
frame #22: 0x0000000100190e4f
emacs`internal_catch(tag=0x0000000000011ac0, func=(emacs`command_loop_2 at
keyboard.c:1159), arg=0x0000000000000090) at eval.c:1364:25 [opt]
frame #23: 0x0000000100288a58 emacs`command_loop.cold.1 at
keyboard.c:1141:2 [opt]
frame #24: 0x00000001000f89d4 emacs`command_loop at keyboard.c:1138:5
[opt]
frame #25: 0x00000001000f889f emacs`recursive_edit_1 at
keyboard.c:749:9 [opt]
frame #26: 0x00000001000f8b40 emacs`Frecursive_edit at keyboard.c:832:3
[opt]
frame #27: 0x00000001000f79dd emacs`main(argc=<unavailable>,
argv=0x00007ff7bfefcae0) at emacs.c:2582:3 [opt]
frame #28: 0x00000001004d152e dyld`start + 462
-Stephane
[Message part 2 (text/html, inline)]
bug-gnu-emacs <at> gnu.org:bug#78654; Package emacs.
(Sat, 31 May 2025 21:55:02 GMT) Full text and rfc822 format available.Message #8 received at 78654 <at> debbugs.gnu.org (full text, mbox):
From: Ship Mints <shipmints <at> gmail.com> To: 78654 <at> debbugs.gnu.org Cc: ben <at> bensimms.moe Subject: Re: bug#78654: NS Emacs crashing (since stipples?) Date: Sat, 31 May 2025 17:53:41 -0400
[Message part 1 (text/plain, inline)]
On Sat, May 31, 2025 at 5:47 PM Ship Mints <shipmints <at> gmail.com> wrote: > 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] > frame #3: 0x000000010004bab4 emacs`draw_glyphs(w=0x0000000112f01140, > x=917, row=<unavailable>, area=TEXT_AREA, start=<unavailable>, > end=<unavailable>, hl=DRAW_CURSOR, overlaps=0) at xdisp.c:31666:5 [opt] > frame #4: 0x00000001000501d1 > emacs`draw_phys_cursor_glyph(w=0x0000000112f01140, row=0x0000000181f1e100, > hl=DRAW_CURSOR) at xdisp.c:34369:12 [opt] > frame #5: 0x000000010025c091 > emacs`ns_draw_window_cursor(w=0x0000000112f01140, > glyph_row=0x0000000181f1e100, x=<unavailable>, y=<unavailable>, > cursor_type=<unavailable>, cursor_width=<unavailable>, on_p=<unavailable>, > active_p=true) at nsterm.m:3126:7 [opt] > frame #6: 0x0000000100050d78 > emacs`display_and_set_cursor(w=0x0000000112f01140, on=true, hpos=0, vpos=1, > x=0, y=21) at xdisp.c:34637:5 [opt] > frame #7: 0x000000010000b71b > emacs`gui_update_window_end(w=0x0000000112f01140, cursor_on_p=true, > mouse_face_overwritten_p=true) at dispnew.c:4653:2 [opt] > frame #8: 0x000000010000a931 emacs`update_window(w=<unavailable>) at > dispnew.c:4587:3 [opt] > frame #9: 0x000000010000effc > emacs`update_window_tree(w=0x0000000112f01140) at dispnew.c:4234:2 [opt] > frame #10: 0x000000010000efbe > emacs`update_window_tree(w=0x0000000113224260) at dispnew.c:4232:2 [opt] > frame #11: 0x0000000100009257 emacs`update_frame [inlined] > update_window_frame(f=0x0000000102f41b70) at dispnew.c:3866:3 [opt] > frame #12: 0x00000001000091e3 emacs`update_frame(f=0x0000000102f41b70, > inhibit_scrolling=<unavailable>) at dispnew.c:4118:5 [opt] > frame #13: 0x0000000100037573 emacs`redisplay_internal at > xdisp.c:17736:5 [opt] > frame #14: 0x000000010003d0b6 > emacs`redisplay_preserve_echo_area(from_where=9) at xdisp.c:18001:5 [opt] > frame #15: 0x00000001001eed97 > emacs`wait_reading_process_output(time_limit=<unavailable>, nsecs=0, > read_kbd=<unavailable>, do_display=true, wait_for_cell=0x0000000000000000, > wait_proc=0x0000000000000000, just_wait_proc=0) at process.c:5457:3 [opt] > frame #16: 0x000000010000ca35 emacs`sit_for(timeout=<unavailable>, > reading=true, display_option=1) at dispnew.c:6979:7 [opt] > frame #17: 0x00000001000fefd1 emacs`read_char(commandflag=1, > map=0x000000010f3b77c3, prev_event=0x0000000000000000, > used_mouse_menu=0x00007ff7bfefc46f, end_time=0x0000000000000000) at > keyboard.c:2925:11 [opt] > frame #18: 0x00000001000fb4b4 > emacs`read_key_sequence(keybuf=0x00007ff7bfefc560, prompt=<unavailable>, > dont_downcase_last=false, can_return_switch_frame=true, > fix_current_buffer=true, prevent_redisplay=<unavailable>, > disable_text_conversion_p=<unavailable>) at keyboard.c:10848:12 [opt] > frame #19: 0x00000001000f9529 emacs`command_loop_1 at > keyboard.c:1424:15 [opt] > frame #20: 0x000000010019197b > emacs`internal_condition_case(bfun=(emacs`command_loop_1 at > keyboard.c:1319), handlers=0x0000000000000090, hfun=(emacs`cmd_error at > keyboard.c:965)) at eval.c:1684:25 [opt] > frame #21: 0x00000001000f915e > emacs`command_loop_2(handlers=0x0000000000000090) at keyboard.c:1163:11 > [opt] > frame #22: 0x0000000100190e4f > emacs`internal_catch(tag=0x0000000000011ac0, func=(emacs`command_loop_2 at > keyboard.c:1159), arg=0x0000000000000090) at eval.c:1364:25 [opt] > frame #23: 0x0000000100288a58 emacs`command_loop.cold.1 at > keyboard.c:1141:2 [opt] > frame #24: 0x00000001000f89d4 emacs`command_loop at keyboard.c:1138:5 > [opt] > frame #25: 0x00000001000f889f emacs`recursive_edit_1 at > keyboard.c:749:9 [opt] > frame #26: 0x00000001000f8b40 emacs`Frecursive_edit at > keyboard.c:832:3 [opt] > frame #27: 0x00000001000f79dd emacs`main(argc=<unavailable>, > argv=0x00007ff7bfefcae0) at emacs.c:2582:3 [opt] > frame #28: 0x00000001004d152e dyld`start + 462 > Same result without images so it's not that. I'll see if I can narrow this down more.
[Message part 2 (text/html, inline)]
bug-gnu-emacs <at> gnu.org:bug#78654; Package emacs.
(Sat, 31 May 2025 22:01:02 GMT) Full text and rfc822 format available.Message #11 received at 78654 <at> debbugs.gnu.org (full text, mbox):
From: Ship Mints <shipmints <at> gmail.com> To: 78654 <at> debbugs.gnu.org Cc: ben <at> bensimms.moe Subject: Re: bug#78654: NS Emacs crashing (since stipples?) Date: Sat, 31 May 2025 18:00:20 -0400
[Message part 1 (text/plain, inline)]
On Sat, May 31, 2025 at 5:53 PM Ship Mints <shipmints <at> gmail.com> wrote:
> On Sat, May 31, 2025 at 5:47 PM Ship Mints <shipmints <at> gmail.com> wrote:
>
>> 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]
>> frame #3: 0x000000010004bab4 emacs`draw_glyphs(w=0x0000000112f01140,
>> x=917, row=<unavailable>, area=TEXT_AREA, start=<unavailable>,
>> end=<unavailable>, hl=DRAW_CURSOR, overlaps=0) at xdisp.c:31666:5 [opt]
>> frame #4: 0x00000001000501d1
>> emacs`draw_phys_cursor_glyph(w=0x0000000112f01140, row=0x0000000181f1e100,
>> hl=DRAW_CURSOR) at xdisp.c:34369:12 [opt]
>> frame #5: 0x000000010025c091
>> emacs`ns_draw_window_cursor(w=0x0000000112f01140,
>> glyph_row=0x0000000181f1e100, x=<unavailable>, y=<unavailable>,
>> cursor_type=<unavailable>, cursor_width=<unavailable>, on_p=<unavailable>,
>> active_p=true) at nsterm.m:3126:7 [opt]
>> frame #6: 0x0000000100050d78
>> emacs`display_and_set_cursor(w=0x0000000112f01140, on=true, hpos=0, vpos=1,
>> x=0, y=21) at xdisp.c:34637:5 [opt]
>> frame #7: 0x000000010000b71b
>> emacs`gui_update_window_end(w=0x0000000112f01140, cursor_on_p=true,
>> mouse_face_overwritten_p=true) at dispnew.c:4653:2 [opt]
>> frame #8: 0x000000010000a931 emacs`update_window(w=<unavailable>) at
>> dispnew.c:4587:3 [opt]
>> frame #9: 0x000000010000effc
>> emacs`update_window_tree(w=0x0000000112f01140) at dispnew.c:4234:2 [opt]
>> frame #10: 0x000000010000efbe
>> emacs`update_window_tree(w=0x0000000113224260) at dispnew.c:4232:2 [opt]
>> frame #11: 0x0000000100009257 emacs`update_frame [inlined]
>> update_window_frame(f=0x0000000102f41b70) at dispnew.c:3866:3 [opt]
>> frame #12: 0x00000001000091e3
>> emacs`update_frame(f=0x0000000102f41b70, inhibit_scrolling=<unavailable>)
>> at dispnew.c:4118:5 [opt]
>> frame #13: 0x0000000100037573 emacs`redisplay_internal at
>> xdisp.c:17736:5 [opt]
>> frame #14: 0x000000010003d0b6
>> emacs`redisplay_preserve_echo_area(from_where=9) at xdisp.c:18001:5 [opt]
>> frame #15: 0x00000001001eed97
>> emacs`wait_reading_process_output(time_limit=<unavailable>, nsecs=0,
>> read_kbd=<unavailable>, do_display=true, wait_for_cell=0x0000000000000000,
>> wait_proc=0x0000000000000000, just_wait_proc=0) at process.c:5457:3 [opt]
>> frame #16: 0x000000010000ca35 emacs`sit_for(timeout=<unavailable>,
>> reading=true, display_option=1) at dispnew.c:6979:7 [opt]
>> frame #17: 0x00000001000fefd1 emacs`read_char(commandflag=1,
>> map=0x000000010f3b77c3, prev_event=0x0000000000000000,
>> used_mouse_menu=0x00007ff7bfefc46f, end_time=0x0000000000000000) at
>> keyboard.c:2925:11 [opt]
>> frame #18: 0x00000001000fb4b4
>> emacs`read_key_sequence(keybuf=0x00007ff7bfefc560, prompt=<unavailable>,
>> dont_downcase_last=false, can_return_switch_frame=true,
>> fix_current_buffer=true, prevent_redisplay=<unavailable>,
>> disable_text_conversion_p=<unavailable>) at keyboard.c:10848:12 [opt]
>> frame #19: 0x00000001000f9529 emacs`command_loop_1 at
>> keyboard.c:1424:15 [opt]
>> frame #20: 0x000000010019197b
>> emacs`internal_condition_case(bfun=(emacs`command_loop_1 at
>> keyboard.c:1319), handlers=0x0000000000000090, hfun=(emacs`cmd_error at
>> keyboard.c:965)) at eval.c:1684:25 [opt]
>> frame #21: 0x00000001000f915e
>> emacs`command_loop_2(handlers=0x0000000000000090) at keyboard.c:1163:11
>> [opt]
>> frame #22: 0x0000000100190e4f
>> emacs`internal_catch(tag=0x0000000000011ac0, func=(emacs`command_loop_2 at
>> keyboard.c:1159), arg=0x0000000000000090) at eval.c:1364:25 [opt]
>> frame #23: 0x0000000100288a58 emacs`command_loop.cold.1 at
>> keyboard.c:1141:2 [opt]
>> frame #24: 0x00000001000f89d4 emacs`command_loop at keyboard.c:1138:5
>> [opt]
>> frame #25: 0x00000001000f889f emacs`recursive_edit_1 at
>> keyboard.c:749:9 [opt]
>> frame #26: 0x00000001000f8b40 emacs`Frecursive_edit at
>> keyboard.c:832:3 [opt]
>> frame #27: 0x00000001000f79dd emacs`main(argc=<unavailable>,
>> argv=0x00007ff7bfefcae0) at emacs.c:2582:3 [opt]
>> frame #28: 0x00000001004d152e dyld`start + 462
>>
>
> Same result without images so it's not that. I'll see if I can narrow
> this down more.
>
Adding the line in question, according to lldb (this is not a debug build,
I guess I'll rebuild with debug next):
* 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=0x0000000103566770,
face=0x0000000000000000) at xfaces.c:4657:16 [opt]
4654
4655 eassert (FRAME_WINDOW_P (f));
4656
-> 4657 if (face->gc == 0)
4658 {
4659 mask = GCForeground | GCBackground | GCGraphicsExposures;
4660
[Message part 2 (text/html, inline)]
bug-gnu-emacs <at> gnu.org:bug#78654; Package emacs.
(Sun, 01 Jun 2025 05:28:02 GMT) Full text and rfc822 format available.Message #14 received at 78654 <at> debbugs.gnu.org (full text, mbox):
From: Eli Zaretskii <eliz <at> gnu.org> To: Ship Mints <shipmints <at> gmail.com> Cc: 78654 <at> debbugs.gnu.org, ben <at> bensimms.moe Subject: Re: bug#78654: NS Emacs crashing (since stipples?) Date: Sun, 01 Jun 2025 08:27:05 +0300
> 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?
bug-gnu-emacs <at> gnu.org:bug#78654; Package emacs.
(Sun, 01 Jun 2025 10:07:02 GMT) Full text and rfc822 format available.Message #17 received at 78654 <at> debbugs.gnu.org (full text, mbox):
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: Re: bug#78654: NS Emacs crashing (since stipples?) Date: Sun, 1 Jun 2025 06:06:05 -0400
[Message part 1 (text/plain, inline)]
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.
[Message part 2 (text/html, inline)]
bug-gnu-emacs <at> gnu.org:bug#78654; Package emacs.
(Sun, 01 Jun 2025 14:41:02 GMT) Full text and rfc822 format available.Message #20 received at 78654 <at> debbugs.gnu.org (full text, mbox):
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: Re: 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)]
bug-gnu-emacs <at> gnu.org:bug#78654; Package emacs.
(Wed, 04 Jun 2025 16:35:03 GMT) Full text and rfc822 format available.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)]
Eli Zaretskii <eliz <at> gnu.org>:Ship Mints <shipmints <at> gmail.com>:Message #28 received at 78654-done <at> debbugs.gnu.org (full text, mbox):
From: Eli Zaretskii <eliz <at> gnu.org> To: Stéphane Marks <shipmints <at> gmail.com> Cc: ben <at> bensimms.moe, 78654-done <at> debbugs.gnu.org Subject: Re: bug#78654: NS Emacs crashing (since stipples?) Date: Wed, 04 Jun 2025 19:58:18 +0300
> From: Stéphane Marks <shipmints <at> gmail.com>
> Date: Wed, 4 Jun 2025 12:34:24 -0400
> Cc: 78654 <at> debbugs.gnu.org, ben <at> bensimms.moe
>
> 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?
Thanks, I've now installed this on the master branch, and I'm closing
this bug.
GNU bug tracking system
Copyright (C) 1999 Darren O. Benham,
1997,2003 nCipher Corporation Ltd,
1994-97 Ian Jackson.