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.