bug#22818: 25.0.91; nextstep/Emacs.app Crash ns_compute_glyph_string_overhangs

bug#22818: 25.0.91; nextstep/Emacs.app Crash ns_compute_glyph_string_overhangs

[Aaron S. Hawley]

[-- Attachment #1: Type: text/plain, Size: 4777 bytes --]

Hello,

I'm using Emacs 25.0.91 pretest as built by David Caldwell at
emacsforosx.com, and it crashes after opening a 104 byte file with
UTF-8 characters that causes Emacs to crash.  Admittedly, the file
contains malformed data that I copied from elsewhere.  This will make
it hard to determine what it should do, but at least it shows a
problem with the existing code.  I was able to confirm the issue with
Emacs trunk, and have included a GDB backtrace below.

To reproduce, unpack the attached zip file, and open the UTF-8 text
file as follows:

/Applications/Emacs.app/Contents/MacOS/Emacs -Q test-file

A segmentation fault occurs, and Mac OS complains that "Emacs quit
unexpectedly."

This issues exists with Emacs 24.5, as well.  However, it doesn't
occur if you use the terminal/tty version of Emacs.

Also attached is patch that shows where the segfault occurs and avoids
triggering it because a font struct is NULL.  Although avoiding a
crash, it likely doesn't do the right thing -- it only treats the
symptoms and not the cause.  Perhaps opening on another platform
(GNU/Linux?) would help to learn what the right thing to do is.

Thanks for Emacs,
Aaron

$ gdb --args ./nextstep/Emacs.app/Contents/MacOS/Emacs -Q test-file
GNU gdb (GDB) 7.10.1
Copyright (C) 2015 Free Software Foundation, Inc.
Reading symbols from ./nextstep/Emacs.app/Contents/MacOS/Emacs...done.
(gdb) run
Starting program: .nextstep/Emacs.app/Contents/MacOS/Emacs -Q test-file
[New Thread 0x1713 of process 58247]
[New Thread 0x1803 of process 58247]
[New Thread 0x1903 of process 58247]
[New Thread 0x1a03 of process 58247]
[New Thread 0x1b03 of process 58247]
[New Thread 0x1c0b of process 58247]
[New Thread 0x1d13 of process 58247]
Error while mapping shared library sections:
cl_kernels: No such file or directory.
Error while mapping shared library sections:
cl_kernels: No such file or directory.
[New Thread 0x1e33 of process 58247]

Program received signal SIGSEGV, Segmentation fault.
ns_compute_glyph_string_overhangs (s=0x7fff5fbfd690) at nsterm.m:2551
2551      if (EQ (font->driver->type, Qns))
(gdb) backtrace
#0  ns_compute_glyph_string_overhangs (s=0x7fff5fbfd690) at nsterm.m:2551
#1  0x000000010003a6c7 in draw_glyphs (w=0x101036208, x=<optimized
out>, row=0x101992d00, area=TEXT_AREA, start=0, end=52,
    hl=<optimized out>, overlaps=<optimized out>) at xdisp.c:25534
#2  0x0000000100039916 in x_write_glyphs (w=0x23a, updated_row=0x0,
start=<optimized out>, updated_area=<optimized out>, len=52)
    at xdisp.c:27630
#3  0x000000010000ab96 in update_text_area (w=<optimized out>,
updated_row=0x23b, vpos=<optimized out>) at dispnew.c:3608
#4  update_window_line (w=0x43007877a76c9b44, vpos=26815744,
mouse_face_overwritten_p=0x7fff5fbfdb87) at dispnew.c:3851
#5  0x0000000100006bde in update_window (w=0x43007877a76c9b44,
    force_p=<error reading variable: Cannot access memory at address
0x1>) at dispnew.c:3473
#6  0x00000001000052d4 in update_window_tree (w=<optimized out>,
force_p=<optimized out>) at dispnew.c:3215
#7  0x000000010000511c in update_frame (f=0x43007877a76c9b44,
force_p=<optimized out>, inhibit_hairy_id_p=false)
    at dispnew.c:3104
#8  0x0000000100028ca6 in redisplay_internal () at xdisp.c:13963
#9  0x00000001000c44e4 in read_char (commandflag=1, map=4320568723,
prev_event=0, used_mouse_menu=0x7fff5fbff5ef, end_time=0x0)
    at keyboard.c:2466
#10 0x00000001000c1d1e in read_key_sequence (keybuf=<optimized out>,
bufsize=30, prompt=<optimized out>,
    dont_downcase_last=<optimized out>,
can_return_switch_frame=<optimized out>, fix_current_buffer=<optimized
out>,
    prevent_redisplay=<optimized out>) at keyboard.c:9045
#11 0x00000001000c054d in command_loop_1 () at keyboard.c:1347
#12 0x000000010013d886 in internal_condition_case
(bfun=0x7fff5fbfd690, handlers=<optimized out>, hfun=<optimized out>)
    at eval.c:1309
#13 0x00000001000d1560 in command_loop_2 (ignore=<optimized out>) at
keyboard.c:1089
#14 0x000000010013d3f6 in internal_catch (tag=<optimized out>,
func=0x7fff5fbfd690, arg=4827991255846525764) at eval.c:1074
#15 0x00000001000bf77e in command_loop () at keyboard.c:1068
#16 0x00000001000bf699 in recursive_edit_1 () at keyboard.c:674
#17 0x00000001000bf8bc in Frecursive_edit () at keyboard.c:745
#18 0x00000001000be3c0 in main (argc=<error reading variable: Cannot
access memory at address 0x0>, argv=<optimized out>)
    at emacs.c:1610

---
 src/nsterm.m | 3 +++
 1 file changed, 3 insertions(+)

diff --git a/src/nsterm.m b/src/nsterm.m
index 43d1377..adce35e 100644
--- a/src/nsterm.m
+++ b/src/nsterm.m
@@ -2532,6 +2532,9 @@ ns_compute_glyph_string_overhangs (struct glyph_string *s)
 {
   struct font *font = s->font;

+  if (!font)
+    return;
+
   if (s->char2b)
     {
       struct font_metrics metrics;

[-- Attachment #2: emacs-ns_compute_glyph_string_overhangs-crash.diff --]
[-- Type: text/plain, Size: 733 bytes --]

From e0750887836b5d80fa681526f5cd463cc7d024a6 Mon Sep 17 00:00:00 2001
From: "Aaron S. Hawley" <aaron.s.hawley@gmail.com>
Date: Thu, 25 Feb 2016 13:53:39 -0500
Subject: [PATCH] nextstep/Emacs.app Crash ns_compute_glyph_string_overhangs

* nsterm.m (ns_compute_glyph_string_overhangs): Avoid crash when
glyph_string->font is NULL.
---
 src/nsterm.m | 3 +++
 1 file changed, 3 insertions(+)

diff --git a/src/nsterm.m b/src/nsterm.m
index 43d1377..adce35e 100644
--- a/src/nsterm.m
+++ b/src/nsterm.m
@@ -2532,6 +2532,9 @@ ns_compute_glyph_string_overhangs (struct glyph_string *s)
 {
   struct font *font = s->font;
 
+  if (!font)
+    return;
+
   if (s->char2b)
     {
       struct font_metrics metrics;
-- 
2.3.0 (Apple Git-54)


[-- Attachment #3: test-file.zip --]
[-- Type: application/zip, Size: 242 bytes --]

bug#22818: 25.0.91; nextstep/Emacs.app Crash ns_compute_glyph_string_overhangs

[Alan Third]

"Aaron S. Hawley" <aaron.s.hawley@gmail.com> writes:

> To reproduce, unpack the attached zip file, and open the UTF-8 text
> file as follows:
>
> /Applications/Emacs.app/Contents/MacOS/Emacs -Q test-file
>
> A segmentation fault occurs, and Mac OS complains that "Emacs quit
> unexpectedly."

Hi, I can't reproduce this on 25.1. Can you please check with the latest
pretest and let us know if you're still getting the crash?
-- 
Alan Third

bug#22818: 25.0.91; nextstep/Emacs.app Crash ns_compute_glyph_string_overhangs

[Aaron S. Hawley]

> Hi, I can't reproduce this on 25.1. Can you please check with the latest
> pretest and let us know if you're still getting the crash?

Same result with the latest Emacs on Mac OS X 10.10.5

M-x version RET
GNU Emacs 25.0.94.1 (x86_64-apple-darwin13.4.0, NS appkit-1265.21
Version 10.9.5 (Build 13F1603)) of 2016-05-17

bug#22818: 25.1.1 Emacs.app crash ns_compute_glyph_string_overhangs

[Josh Berdine]

I have encountered a crash in ns_compute_glyph_string_overhangs, seems likely to be the same issue.  I hit this when using the notmuch email client with a message with the following subject header:

Subject: =?UTF-8?B?W1JvYm90IEhvdXNlXSDwn42V?=
 =?UTF-8?B?8J+NlfCfjZXwn42V8J+NlfCfjZXwn42V8J+NlfCfjZXwn42V8J+NlfCfjZXwn42V8J+NlfCfjZXwn42V?=
 =?UTF-8?B?8J+NlfCfjZXwn42V8J+NlfCfjZXwn42V8J+NlfCfjZXwn42V8J+NlfCfjZXwn42V8J+NlfCfjZXwn42V?=

I am running GNU Emacs 25.1.1 (x86_64-apple-darwin13.4.0, NS appkit-1265.21 Version 10.9.5 (Build 13F1911)) of 2016-09-17

I attached lldb to a running emacs and then executed a `notmuch-search` that included the message with above subject.  Backtrace is:

(lldb) c
Process 42346 resuming
Process 42346 stopped
* thread #1: tid = 0x449aca, 0x00000001001b5767 Emacs-x86_64-10_9`ns_compute_glyph_string_overhangs + 119, queue = 'com.apple.main-thread', stop reason = EXC_BAD_ACCESS (code=1, address=0xd0)
    frame #0: 0x00000001001b5767 Emacs-x86_64-10_9`ns_compute_glyph_string_overhangs + 119
Emacs-x86_64-10_9`ns_compute_glyph_string_overhangs:
->  0x1001b5767 <+119>: movq   0xd0(%rdi), %rax
    0x1001b576e <+126>: cmpq   $0x7e00, (%rax)           ; imm = 0x7E00
    0x1001b5775 <+133>: jne    0x1001b579b               ; <+171>
    0x1001b5777 <+135>: xorl   %eax, %eax
(lldb) bt
* thread #1: tid = 0x449aca, 0x00000001001b5767 Emacs-x86_64-10_9`ns_compute_glyph_string_overhangs + 119, queue = 'com.apple.main-thread', stop reason = EXC_BAD_ACCESS (code=1, address=0xd0)
  * frame #0: 0x00000001001b5767 Emacs-x86_64-10_9`ns_compute_glyph_string_overhangs + 119
    frame #1: 0x00000001000379d7 Emacs-x86_64-10_9`draw_glyphs + 3415
    frame #2: 0x0000000100036c16 Emacs-x86_64-10_9`x_write_glyphs + 166
    frame #3: 0x0000000100009e3e Emacs-x86_64-10_9`update_window_line + 670
    frame #4: 0x0000000100005edc Emacs-x86_64-10_9`update_window + 4588
    frame #5: 0x00000001000046a4 Emacs-x86_64-10_9`update_window_tree + 116
    frame #6: 0x00000001000044e7 Emacs-x86_64-10_9`update_frame + 135
    frame #7: 0x00000001000275d2 Emacs-x86_64-10_9`redisplay_internal + 5666
    frame #8: 0x00000001000283fc Emacs-x86_64-10_9`redisplay_preserve_echo_area + 44
    frame #9: 0x000000010017a553 Emacs-x86_64-10_9`wait_reading_process_output + 1651
    frame #10: 0x00000001000076bd Emacs-x86_64-10_9`sit_for + 253
    frame #11: 0x00000001000c1996 Emacs-x86_64-10_9`read_char + 6006
    frame #12: 0x00000001000be2ec Emacs-x86_64-10_9`read_key_sequence + 2092
    frame #13: 0x00000001000bca02 Emacs-x86_64-10_9`command_loop_1 + 1154
    frame #14: 0x0000000100138196 Emacs-x86_64-10_9`internal_condition_case + 70
    frame #15: 0x00000001000cd620 Emacs-x86_64-10_9`command_loop_2 + 48
    frame #16: 0x0000000100137cf6 Emacs-x86_64-10_9`internal_catch + 54
    frame #17: 0x00000001000bbc4e Emacs-x86_64-10_9`command_loop + 158
    frame #18: 0x00000001000bbb65 Emacs-x86_64-10_9`recursive_edit_1 + 117
    frame #19: 0x00000001000bbd8c Emacs-x86_64-10_9`Frecursive_edit + 220
    frame #20: 0x00000001000baa5e Emacs-x86_64-10_9`main + 5854
    frame #21: 0x00007fff9b4225ad libdyld.dylib`start + 1
    frame #22: 0x00007fff9b4225ad libdyld.dylib`start + 1

Using Aaron's test-file, `/Applications/Emacs.app/Contents/MacOS/Emacs -Q test-file` crashes with the same backtrace.  If I leave out -Q, however, it does not crash.

bug#22818: 25.1.1 Emacs.app crash ns_compute_glyph_string_overhangs

[Eli Zaretskii]

> From: Josh Berdine <josh@berdine.net>
> Date: Fri, 18 Nov 2016 21:31:49 +0000
> 
> (lldb) c
> Process 42346 resuming
> Process 42346 stopped
> * thread #1: tid = 0x449aca, 0x00000001001b5767 Emacs-x86_64-10_9`ns_compute_glyph_string_overhangs + 119, queue = 'com.apple.main-thread', stop reason = EXC_BAD_ACCESS (code=1, address=0xd0)
>     frame #0: 0x00000001001b5767 Emacs-x86_64-10_9`ns_compute_glyph_string_overhangs + 119
> Emacs-x86_64-10_9`ns_compute_glyph_string_overhangs:
> ->  0x1001b5767 <+119>: movq   0xd0(%rdi), %rax
>     0x1001b576e <+126>: cmpq   $0x7e00, (%rax)           ; imm = 0x7E00
>     0x1001b5775 <+133>: jne    0x1001b579b               ; <+171>
>     0x1001b5777 <+135>: xorl   %eax, %eax
> (lldb) bt
> * thread #1: tid = 0x449aca, 0x00000001001b5767 Emacs-x86_64-10_9`ns_compute_glyph_string_overhangs + 119, queue = 'com.apple.main-thread', stop reason = EXC_BAD_ACCESS (code=1, address=0xd0)
>   * frame #0: 0x00000001001b5767 Emacs-x86_64-10_9`ns_compute_glyph_string_overhangs + 119
>     frame #1: 0x00000001000379d7 Emacs-x86_64-10_9`draw_glyphs + 3415
>     frame #2: 0x0000000100036c16 Emacs-x86_64-10_9`x_write_glyphs + 166
>     frame #3: 0x0000000100009e3e Emacs-x86_64-10_9`update_window_line + 670
>     frame #4: 0x0000000100005edc Emacs-x86_64-10_9`update_window + 4588
>     frame #5: 0x00000001000046a4 Emacs-x86_64-10_9`update_window_tree + 116
>     frame #6: 0x00000001000044e7 Emacs-x86_64-10_9`update_frame + 135

Can you convert the address in frame #0 into line numbers?  Judging by
the faulting address, 0xd0, some pointer in
ns_compute_glyph_string_overhangs is a null pointer, but it's hard to
tell which one without the line number information.

bug#22818: 25.1.1 Emacs.app crash ns_compute_glyph_string_overhangs

[Alan Third]

On Sat, Nov 19, 2016 at 09:07:50AM +0200, Eli Zaretskii wrote:
> Can you convert the address in frame #0 into line numbers?  Judging by
> the faulting address, 0xd0, some pointer in
> ns_compute_glyph_string_overhangs is a null pointer, but it's hard to
> tell which one without the line number information.

I finally managed to replicate this on my own build:

(lldb) run -Q ~/test-file
Process 66588 launched: '/Users/alan/src/emacs/emacs-25/nextstep/Emacs.app/Contents/MacOS/Emacs' (x86_64)
Process 66588 stopped
* thread #1: tid = 0x154600, 0x00000001002c0940 Emacs`ns_compute_glyph_string_overhangs(s=0x00007fff5fbfb6f0) + 224 at nsterm.m:2681, queue = 'com.apple.main-thread', stop reason = EXC_BAD_ACCESS (code=1, address=0xd0)
    frame #0: 0x00000001002c0940 Emacs`ns_compute_glyph_string_overhangs(s=0x00007fff5fbfb6f0) + 224 at nsterm.m:2681
   2678	  else
   2679	    {
   2680	      s->left_overhang = 0;
-> 2681	      if (EQ (font->driver->type, Qns))
   2682	        s->right_overhang = ((struct nsfont_info *)font)->ital ?
   2683	          FONT_HEIGHT (font) * 0.2 : 0;
   2684	      else
(lldb) bt all
* thread #1: tid = 0x154600, 0x00000001002c0940 Emacs`ns_compute_glyph_string_overhangs(s=0x00007fff5fbfb6f0) + 224 at nsterm.m:2681, queue = 'com.apple.main-thread', stop reason = EXC_BAD_ACCESS (code=1, address=0xd0)
  * frame #0: 0x00000001002c0940 Emacs`ns_compute_glyph_string_overhangs(s=0x00007fff5fbfb6f0) + 224 at nsterm.m:2681
    frame #1: 0x0000000100058e7c Emacs`draw_glyphs(w=0x000000010204f430, x=570, row=0x000000010240e100, area=TEXT_AREA, start=0, end=52, hl=DRAW_NORMAL_TEXT, overlaps=0) + 3324 at xdisp.c:25673
    frame #2: 0x00000001000580cd Emacs`x_write_glyphs(w=0x000000010204f430, updated_row=0x000000010240e100, start=0x0000000102420000, updated_area=TEXT_AREA, len=52) + 269 at xdisp.c:27774
    frame #3: 0x000000010000ea34 Emacs`update_text_area(w=0x000000010204f430, updated_row=0x000000010240e100, vpos=1) + 452 at dispnew.c:3612
    frame #4: 0x000000010000ca32 Emacs`update_window_line(w=0x000000010204f430, vpos=1, mouse_face_overwritten_p=0x00007fff5fbfbdd2) + 274 at dispnew.c:3855
    frame #5: 0x0000000100006be1 Emacs`update_window(w=0x000000010204f430, force_p=true) + 865 at dispnew.c:3477
    frame #6: 0x0000000100005c88 Emacs`update_window_tree(w=0x000000010204f430, force_p=true) + 200 at dispnew.c:3219
    frame #7: 0x0000000100005996 Emacs`update_frame(f=0x0000000102050430, force_p=true, inhibit_hairy_id_p=false) + 182 at dispnew.c:3108
    frame #8: 0x000000010004151d Emacs`redisplay_internal + 6957 at xdisp.c:14085
    frame #9: 0x0000000100042a79 Emacs`redisplay + 9 at xdisp.c:13255
    frame #10: 0x000000010013a985 Emacs`read_char(commandflag=1, map=4362425571, prev_event=0, used_mouse_menu=0x00007fff5fbfefb7, end_time=0x0000000000000000) + 1829 at keyboard.c:2482
    frame #11: 0x0000000100136b09 Emacs`read_key_sequence(keybuf=0x00007fff5fbff2e0, bufsize=30, prompt=0, dont_downcase_last=false, can_return_switch_frame=true, fix_current_buffer=true, prevent_redisplay=false) + 1737 at keyboard.c:9068
    frame #12: 0x00000001001356bb Emacs`command_loop_1 + 1435 at keyboard.c:1370
    frame #13: 0x00000001001f8493 Emacs`internal_condition_case(bfun=(Emacs`command_loop_1 at keyboard.c:1261), handlers=16752, hfun=(Emacs`cmd_error at keyboard.c:940)) + 115 at eval.c:1314
    frame #14: 0x000000010014a8ec Emacs`command_loop_2(ignore=0) + 44 at keyboard.c:1112
    frame #15: 0x00000001001f7c68 Emacs`internal_catch(tag=42480, func=(Emacs`command_loop_2 at keyboard.c:1108), arg=0) + 72 at eval.c:1079
    frame #16: 0x0000000100134688 Emacs`command_loop + 280 at keyboard.c:1091
    frame #17: 0x00000001001344d0 Emacs`recursive_edit_1 + 192 at keyboard.c:697
    frame #18: 0x0000000100134821 Emacs`Frecursive_edit + 305 at keyboard.c:768
    frame #19: 0x0000000100132548 Emacs`main(argc=3, argv=0x00007fff5fbff8e8) + 5864 at emacs.c:1626
    frame #20: 0x00007fff8f1a6255 libdyld.dylib`start + 1
    frame #21: 0x00007fff8f1a6255 libdyld.dylib`start + 1

(lldb) frame variable
(glyph_string *) s = 0x00007fff5fbfb6f0
(font *) font = 0x0000000000000000

(lldb) frame variable *s
(glyph_string) *s = {
  x = 10
  y = 16
  ybase = 30
  width = 11
  background_width = 11
  height = 20
  left_overhang = 0
  right_overhang = 0
  f = 0x0000000102050430
  w = 0x000000010204f430
  display = 0x0000000000000000
  window = 1
  row = 0x000000010240e100
  area = TEXT_AREA
  char2b = 0x0000000000000000
  nchars = 1
  hl = DRAW_NORMAL_TEXT
  face = 0x000000010153b400
  font = 0x0000000000000000
  cmp = 0x0000000000000000
  cmp_id = 0
  cmp_from = 0
  cmp_to = 0
  extends_to_end_of_line_p = false
  background_filled_p = false
  font_not_found_p = false
  stippled_p = false
  for_overlaps = 0
  padding_p = false
  first_glyph = 0x0000000102420000
  img = 0x0000000000000000
  xwidget = 0x0000000000000000
  slice = (x = 0, y = 0, width = 0, height = 0)
  clip_head = 0x0000000000000000
  clip_tail = 0x0000000000000000
  clip = ([0] = (origin = (x = 0, y = 0), size = (width = 0, height = 0)), [1] = (origin = (x = 0, y = 0), size = (width = 0, height = 0)))
  num_clips = 0
  underline_position = 0
  underline_thickness = 0
  next = 0x00007fff5fbfb5d0
  prev = 0x0000000000000000
}

-- 
Alan Third

bug#22818: 25.1.1 Emacs.app crash ns_compute_glyph_string_overhangs

[Eli Zaretskii]

> Date: Sat, 19 Nov 2016 10:07:03 +0000
> From: Alan Third <alan@idiocy.org>
> Cc: Josh Berdine <josh@berdine.net>, 22818@debbugs.gnu.org
> 
> On Sat, Nov 19, 2016 at 09:07:50AM +0200, Eli Zaretskii wrote:
> > Can you convert the address in frame #0 into line numbers?  Judging by
> > the faulting address, 0xd0, some pointer in
> > ns_compute_glyph_string_overhangs is a null pointer, but it's hard to
> > tell which one without the line number information.
> 
> I finally managed to replicate this on my own build:
> 
> (lldb) run -Q ~/test-file
> Process 66588 launched: '/Users/alan/src/emacs/emacs-25/nextstep/Emacs.app/Contents/MacOS/Emacs' (x86_64)
> Process 66588 stopped
> * thread #1: tid = 0x154600, 0x00000001002c0940 Emacs`ns_compute_glyph_string_overhangs(s=0x00007fff5fbfb6f0) + 224 at nsterm.m:2681, queue = 'com.apple.main-thread', stop reason = EXC_BAD_ACCESS (code=1, address=0xd0)
>     frame #0: 0x00000001002c0940 Emacs`ns_compute_glyph_string_overhangs(s=0x00007fff5fbfb6f0) + 224 at nsterm.m:2681
>    2678	  else
>    2679	    {
>    2680	      s->left_overhang = 0;
> -> 2681	      if (EQ (font->driver->type, Qns))
>    2682	        s->right_overhang = ((struct nsfont_info *)font)->ital ?
>    2683	          FONT_HEIGHT (font) * 0.2 : 0;
>    2684	      else
> (lldb) bt all
> * thread #1: tid = 0x154600, 0x00000001002c0940 Emacs`ns_compute_glyph_string_overhangs(s=0x00007fff5fbfb6f0) + 224 at nsterm.m:2681, queue = 'com.apple.main-thread', stop reason = EXC_BAD_ACCESS (code=1, address=0xd0)
>   * frame #0: 0x00000001002c0940 Emacs`ns_compute_glyph_string_overhangs(s=0x00007fff5fbfb6f0) + 224 at nsterm.m:2681
>     frame #1: 0x0000000100058e7c Emacs`draw_glyphs(w=0x000000010204f430, x=570, row=0x000000010240e100, area=TEXT_AREA, start=0, end=52, hl=DRAW_NORMAL_TEXT, overlaps=0) + 3324 at xdisp.c:25673

So the question now becomes: how did that glyph_string got a NULL
font?  The answer is somewhere in the code that generates glyph
strings as part of the call to BUILD_GLYPH_STRINGS.  Can you try
figuring out why does that happen, by stepping through the code in
BUILD_GLYPH_STRINGS?

> (lldb) frame variable
> (glyph_string *) s = 0x00007fff5fbfb6f0
> (font *) font = 0x0000000000000000
> 
> (lldb) frame variable *s
> (glyph_string) *s = {
>   x = 10
>   y = 16
>   ybase = 30
>   width = 11
>   background_width = 11
>   height = 20
>   left_overhang = 0
>   right_overhang = 0
>   f = 0x0000000102050430
>   w = 0x000000010204f430
>   display = 0x0000000000000000
>   window = 1
>   row = 0x000000010240e100
>   area = TEXT_AREA
>   char2b = 0x0000000000000000
>   nchars = 1
>   hl = DRAW_NORMAL_TEXT
>   face = 0x000000010153b400

What kind of face is s->face?

Thanks.

bug#22818: 25.1.1 Emacs.app crash ns_compute_glyph_string_overhangs

[Alan Third]

On Sat, Nov 19, 2016 at 12:27:27PM +0200, Eli Zaretskii wrote:
> So the question now becomes: how did that glyph_string got a NULL
> font?  The answer is somewhere in the code that generates glyph
> strings as part of the call to BUILD_GLYPH_STRINGS.  Can you try
> figuring out why does that happen, by stepping through the code in
> BUILD_GLYPH_STRINGS?

I’m trying to work out how to do this, but in the mean‐time here’s s->face:

(lldb) fr v *s->face
(face) *s->face = {
  lface = {
    [0] = 17952
    [1] = 4311871236
    [2] = 4298401388
    [3] = 32304
    [4] = 482
    [5] = 32304
    [6] = 32304
    [7] = 0
    [8] = 0
    [9] = 4313454388
    [10] = 4313454420
    [11] = 0
    [12] = 0
    [13] = 0
    [14] = 0
    [15] = 4356698701
    [16] = 0
    [17] = 4313448132
    [18] = 44496
  }
  id = 19
  gc = 0x0000000000000000
  stipple = 0
  foreground = 2
  background = 1
  underline_color = 0
  overline_color = 0
  strike_through_color = 0
  box_color = 0
  font = 0x0000000000000000
  fontset = 3
  box_line_width = 0
  box = FACE_NO_BOX
  underline_type = FACE_UNDER_LINE
  use_box_color_for_shadows_p = false
  underline_p = false
  overline_p = false
  strike_through_p = false
  foreground_defaulted_p = false
  background_defaulted_p = false
  underline_defaulted_p = false
  overline_color_defaulted_p = false
  strike_through_color_defaulted_p = false
  box_color_defaulted_p = false
  tty_bold_p = false
  tty_italic_p = false
  tty_underline_p = false
  tty_reverse_p = false
  colors_copied_bitwise_p = true
  overstrike = false
  synth_ital = false
  hash = 7029
  next = 0x000000010fd7e5d0
  prev = 0x000000010c5eda00
  ascii_face = 0x00000001011afac0
}

I don’t know if that tells you anything useful.
-- 
Alan Third

bug#22818: 25.1.1 Emacs.app crash ns_compute_glyph_string_overhangs

[Eli Zaretskii]

> Date: Sat, 19 Nov 2016 11:18:23 +0000
> From: Alan Third <alan@idiocy.org>
> Cc: josh@berdine.net, 22818@debbugs.gnu.org
> 
> I’m trying to work out how to do this, but in the mean‐time here’s s->face:
> 
> (lldb) fr v *s->face
> (face) *s->face = {
> [...]
>   id = 19

What is the value of lface_id_to_name[19]?  It should be a Lisp
symbol; if so, what is that symbol's name?  (The file src/.gdbinit
defines a command, xsymbol, to display the name of a symbol, but I
don't know how to do that with LLDB.)

bug#22818: 25.1.1 Emacs.app crash ns_compute_glyph_string_overhangs

[Alan Third]

On Sat, Nov 19, 2016 at 01:43:17PM +0200, Eli Zaretskii wrote:
> > Date: Sat, 19 Nov 2016 11:18:23 +0000
> > From: Alan Third <alan@idiocy.org>
> > Cc: josh@berdine.net, 22818@debbugs.gnu.org
> > 
> > I’m trying to work out how to do this, but in the mean‐time here’s s->face:
> > 
> > (lldb) fr v *s->face
> > (face) *s->face = {
> > [...]
> >   id = 19
> 
> What is the value of lface_id_to_name[19]?  It should be a Lisp
> symbol; if so, what is that symbol's name?  (The file src/.gdbinit
> defines a command, xsymbol, to display the name of a symbol, but I
> don't know how to do that with LLDB.)

I’ve run into some sort of a problem here as lldb was throwing up an
error, so I signed gdb to try it and it’s also giving an error:

(gdb) p s->face.id
$2 = 17
(gdb) p lface_id_to_name[17]
$3 = 31008
(gdb) xsymbol(lface_id_to_name[17])
$4 = (struct Lisp_Symbol *) 0x7ab8
Cannot access memory at address 0x7ac0

am I doing this wrong?
-- 
Alan Third

bug#22818: 25.1.1 Emacs.app crash ns_compute_glyph_string_overhangs

[Eli Zaretskii]

> Date: Sat, 19 Nov 2016 14:53:36 +0000
> From: Alan Third <alan@idiocy.org>
> Cc: josh@berdine.net, 22818@debbugs.gnu.org
> 
> (gdb) p s->face.id
> $2 = 17
> (gdb) p lface_id_to_name[17]
> $3 = 31008
> (gdb) xsymbol(lface_id_to_name[17])
> $4 = (struct Lisp_Symbol *) 0x7ab8
> Cannot access memory at address 0x7ac0
> 
> am I doing this wrong?

The last command should be simply "xsymbol".  Those x* commands are
defined such that they always operate on the last result printed by
GDB.

Thanks.

bug#22818: 25.1.1 Emacs.app crash ns_compute_glyph_string_overhangs

[Alan Third]

On Sat, Nov 19, 2016 at 05:09:06PM +0200, Eli Zaretskii wrote:
> > Date: Sat, 19 Nov 2016 14:53:36 +0000
> > From: Alan Third <alan@idiocy.org>
> > Cc: josh@berdine.net, 22818@debbugs.gnu.org
> > 
> > (gdb) p s->face.id
> > $2 = 17
> > (gdb) p lface_id_to_name[17]
> > $3 = 31008
> > (gdb) xsymbol(lface_id_to_name[17])
> > $4 = (struct Lisp_Symbol *) 0x7ab8
> > Cannot access memory at address 0x7ac0
> > 
> > am I doing this wrong?
> 
> The last command should be simply "xsymbol".  Those x* commands are
> defined such that they always operate on the last result printed by
> GDB.

Thanks, unfortunately it doesn’t look any different. I’ll paste my
whole gdb session in in case you can see me doing something stupid.

breton:/Users/alan/src/emacs/emacs-25/src>gdb ../nextstep/Emacs.app/Contents/MacOS/Emacs
GNU gdb (GDB) 7.12
Copyright (C) 2016 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/gpl.html>
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law.  Type "show copying"
and "show warranty" for details.
This GDB was configured as "x86_64-apple-darwin16.1.0".
Type "show configuration" for configuration details.
For bug reporting instructions, please see:
<http://www.gnu.org/software/gdb/bugs/>.
Find the GDB manual and other documentation resources online at:
<http://www.gnu.org/software/gdb/documentation/>.
For help, type "help".
Type "apropos word" to search for commands related to "word"...
Reading symbols from ../nextstep/Emacs.app/Contents/MacOS/Emacs...done.
SIGINT is used by the debugger.
Are you sure you want to change it? (y or n) [answered Y; input not from terminal]
DISPLAY = /private/tmp/com.apple.launchd.U7C5wbWrEt/org.macosforge.xquartz:0
TERM = xterm-256color
Breakpoint 1 at 0x100130a42: file emacs.c, line 354.
Temporary breakpoint 2 at 0x10015d86f: file sysdep.c, line 915.
(gdb) run -Q ~/test-file
Starting program: /Users/alan/src/emacs/emacs-25/nextstep/Emacs.app/Contents/MacOS/Emacs -Q ~/test-file
[New Thread 0x1403 of process 716]
warning: unhandled dyld version (15)
[New Thread 0x1207 of process 716]
[New Thread 0x1503 of process 716]
[New Thread 0x1603 of process 716]
[New Thread 0x1703 of process 716]
[New Thread 0x1803 of process 716]
[New Thread 0x1903 of process 716]
[New Thread 0x1a03 of process 716]
[New Thread 0x1b03 of process 716]

Thread 2 received signal SIGSEGV, Segmentation fault.
0x00000001002c0940 in ns_compute_glyph_string_overhangs (s=0x7fff5fbfb780)
    at nsterm.m:2681
2681	      if (EQ (font->driver->type, Qns))
(gdb) p s->face.id
$1 = 17
(gdb) p lface_id_to_name[17]
$2 = 31008
(gdb) xsymbol
$3 = (struct Lisp_Symbol *) 0x7ab8
Cannot access memory at address 0x7ac0
(gdb) 

I’ve tried building with CFLAGS set to:

-g
-g3
-gmodules

and gcc on OS X is actually CLang.
-- 
Alan Third

bug#22818: 25.1.1 Emacs.app crash ns_compute_glyph_string_overhangs

[Eli Zaretskii]

> Date: Sat, 19 Nov 2016 15:51:12 +0000
> From: Alan Third <alan@idiocy.org>
> Cc: josh@berdine.net, 22818@debbugs.gnu.org
> 
> (gdb) p s->face.id
> $1 = 17
> (gdb) p lface_id_to_name[17]
> $2 = 31008
> (gdb) xsymbol
> $3 = (struct Lisp_Symbol *) 0x7ab8
> Cannot access memory at address 0x7ac0
> (gdb) 

So I guess that face was freed or otherwise made invalid.  I thought
we've got rid of these problems, sigh...

If you start "emacs -Q", let Emacs start up, and then look at that
face ID, do you see a valid symbol?  IOW, do this:

  $ gdb ./emacs
  ...
  (gdb) break Fredraw_display
  (gdb) r -Q

Then, after Emacs starts up, type "M-x redraw-display RET", and at the
GDB prompt type:

  (gdb) p lface_id_to_name[17]
  (gdb) xsymbol

What does that show?

And what is the value of next_lface_id at that point?

bug#22818: 25.1.1 Emacs.app crash ns_compute_glyph_string_overhangs

[Alan Third]

On Sat, Nov 19, 2016 at 08:12:07PM +0200, Eli Zaretskii wrote:
> > Date: Sat, 19 Nov 2016 15:51:12 +0000
> > From: Alan Third <alan@idiocy.org>
> > Cc: josh@berdine.net, 22818@debbugs.gnu.org
> > 
> > (gdb) p s->face.id
> > $1 = 17
> > (gdb) p lface_id_to_name[17]
> > $2 = 31008
> > (gdb) xsymbol
> > $3 = (struct Lisp_Symbol *) 0x7ab8
> > Cannot access memory at address 0x7ac0
> > (gdb) 
> 
> So I guess that face was freed or otherwise made invalid.  I thought
> we've got rid of these problems, sigh...
> 
> If you start "emacs -Q", let Emacs start up, and then look at that
> face ID, do you see a valid symbol?  IOW, do this:
> 
>   $ gdb ./emacs
>   ...
>   (gdb) break Fredraw_display
>   (gdb) r -Q
> 
> Then, after Emacs starts up, type "M-x redraw-display RET", and at the
> GDB prompt type:
> 
>   (gdb) p lface_id_to_name[17]
>   (gdb) xsymbol
> 
> What does that show?
> 
> And what is the value of next_lface_id at that point?

(gdb) p lface_id_to_name[17]
$1 = 31008
(gdb) xsymbol
$2 = (struct Lisp_Symbol *) 0x7ab8
Cannot access memory at address 0x7ac0
(gdb) p next_lface_id
$3 = 84

-- 
Alan Third

bug#22818: 25.1.1 Emacs.app crash ns_compute_glyph_string_overhangs

[Eli Zaretskii]

> Date: Sat, 19 Nov 2016 19:05:39 +0000
> From: Alan Third <alan@idiocy.org>
> Cc: josh@berdine.net, 22818@debbugs.gnu.org
> 
> >   (gdb) break Fredraw_display
> >   (gdb) r -Q
> > 
> > Then, after Emacs starts up, type "M-x redraw-display RET", and at the
> > GDB prompt type:
> > 
> >   (gdb) p lface_id_to_name[17]
> >   (gdb) xsymbol
> > 
> > What does that show?
> > 
> > And what is the value of next_lface_id at that point?
> 
> (gdb) p lface_id_to_name[17]
> $1 = 31008
> (gdb) xsymbol
> $2 = (struct Lisp_Symbol *) 0x7ab8
> Cannot access memory at address 0x7ac0
> (gdb) p next_lface_id
> $3 = 84

Strange.  What about other indices between zero and 83?  Are they all
invalid symbols like this one?

bug#22818: 25.1.1 Emacs.app crash ns_compute_glyph_string_overhangs

[Alan Third]

On Sat, Nov 19, 2016 at 09:27:52PM +0200, Eli Zaretskii wrote:
> > 
> > (gdb) p lface_id_to_name[17]
> > $1 = 31008
> > (gdb) xsymbol
> > $2 = (struct Lisp_Symbol *) 0x7ab8
> > Cannot access memory at address 0x7ac0
> > (gdb) p next_lface_id
> > $3 = 84
> 
> Strange.  What about other indices between zero and 83?  Are they all
> invalid symbols like this one?

As far as I can see, yes.
-- 
Alan Third

bug#22818: 25.0.91; nextstep/Emacs.app Crash ns_compute_glyph_string_overhangs

[Lars Ingebrigtsen]

"Aaron S. Hawley" <aaron.s.hawley@gmail.com> writes:

> To reproduce, unpack the attached zip file, and open the UTF-8 text
> file as follows:
>
> /Applications/Emacs.app/Contents/MacOS/Emacs -Q test-file
>
> A segmentation fault occurs, and Mac OS complains that "Emacs quit
> unexpectedly."
>
> This issues exists with Emacs 24.5, as well.  However, it doesn't
> occur if you use the terminal/tty version of Emacs.

(I'm going through old bug reports that unfortunately weren't resolved
at the time.)

This was five years ago -- do you still see this issue on recent Emacs
versions?

-- 
(domestic pets only, the antidote for overdose, milk.)
   bloggy blog: http://lars.ingebrigtsen.no

bug#22818: 25.0.91; nextstep/Emacs.app Crash ns_compute_glyph_string_overhangs

[Aaron S. Hawley]

> (I'm going through old bug reports that unfortunately weren't resolved
> at the time.)
>
> This was five years ago -- do you still see this issue on recent Emacs
> versions?

No, I do not see this issue any longer on recent versions of Emacs for
Macos either for the specific case for the bug report, but also
happily Emacs doesn't crash arbitrarily like it used to from this. The
issue can be closed.

Thanks for Emacs,
Aaron

bug#22818: 25.0.91; nextstep/Emacs.app Crash ns_compute_glyph_string_overhangs

[Lars Ingebrigtsen]

"Aaron S. Hawley" <aaron.s.hawley@gmail.com> writes:

> No, I do not see this issue any longer on recent versions of Emacs for
> Macos either for the specific case for the bug report, but also
> happily Emacs doesn't crash arbitrarily like it used to from this. The
> issue can be closed.

Thanks; done.

-- 
(domestic pets only, the antidote for overdose, milk.)
   bloggy blog: http://lars.ingebrigtsen.no