bug#21428: 24.5; Crash of emacs on OS X, installed via homebrew cask

[Eli Zaretskii <eliz@gnu.org>]

> From: Rainer M Krug <Rainer@krugs.de>
> Cc: 21428@debbugs.gnu.org,  mituharu+bug-gnu-emacs-mac@math.s.chiba-u.ac.jp
> Date: Fri, 25 Sep 2015 14:30:05 +0200
> 
> ,----
> | xdisp.c:24333: Emacs fatal error: assertion failed: face != NULL
> | 
> | Breakpoint 1, terminate_due_to_signal (sig=6, backtrace_limit=2147483647) at emacs.c:370
> | 370	  signal (sig, SIG_DFL);
> | (gdb) bt
> | #0  terminate_due_to_signal (sig=6, backtrace_limit=2147483647) at emacs.c:370
> | #1  0x00000001002256eb in die (msg=0x1003b680a "face != NULL", file=0x1003b24f0 "xdisp.c", line=24333) at alloc.c:6951
> | #2  0x0000000100062f17 in get_glyph_face_and_encoding (f=0x103811830, glyph=0x103c4b060, char2b=0x7fff5fbfb310) at xdisp.c:24333
> | #3  0x00000001000b581d in fill_glyph_string (s=0x7fff5fbfb360, face_id=50, start=34, end=71, overlaps=0) at xdisp.c:24558

OK, I think I've seen enough of these for now, thanks.  It seems like
a face is removed from the frame's face cache, but Emacs still thinks
the face is cached and tries to use its (stale) cache slot.  The face
is different each time, and there's nothing problematic with the face
itself.

I took a look at the code, and couldn't find any obvious way this
could happen.  I need some way to narrow down the search.  So I need
to ask you to try a few things, okay?

First, I'd like to know whether the line of code marked below is ever
executed:

  static void
  uncache_face (struct face_cache *c, struct face *face)
  {
    int i = face->hash % FACE_CACHE_BUCKETS_SIZE;

    if (face->prev)
      face->prev->next = face->next;
    else
      c->buckets[i] = face->next;

    if (face->next)
      face->next->prev = face->prev;

    c->faces_by_id[face->id] = NULL;
    if (face->id == c->used)
      --c->used;  <<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<
  }

This is from xfaces.c, line 4322 with the current Git master.  Please
put a breakpoint there, and run Emacs under GDB until it crashes as
before, or until this breakpoint breaks.  If it breaks, please show
the backtrace.

If this breakpoint never breaks before another crash, please
reconfigure Emacs like this:

  CFLAGS="-ggdb3 -O0" CXXFLAGS="-ggdb3 -O0" LDFLAGS="-ggdb3" ./configure --enable-checking='yes,glyphs'

then rebuild, and run it after setting these three variables to t:

  inhibit-try-cursor-movement
  inhibit-try-window-id
  inhibit-try-window-reusing

This disables some redisplay optimizations, so you might see slow
redisplay; this is normal.  What is important is to see whether the
crashes disappear when these variables are set to non-nil values.  If
you run for a long time without crashes, then set these variables to
nil, one by one, in the order they are shown above, and each time let
Emacs run enough time for you to be sure the problem doesn't happen,
before you proceed to the next variable.

I hope these two procedures will collect data that will help me zero
in on the problematic code.

Thanks.