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
> Date: Mon, 26 Oct 2015 08:59:39 +0100
> 
> the bug does not affect to many users (strange config? OS X?).

It's not really true that it didn't affect others.  We have in the bug
tracker a few similar bug reports where an invalid face ID was the
culprit, I believe they were caused by the same problem.

It's true that these problems are rare.  That's because, for this
situation to happen, you need to have some to enable feature that can
create new faces or change existing faces in code that is invoked by
redisplay, for example some Lisp form that gets evaluated while
displaying the mode line.  When a face is created or changed, Emacs
forgets all the cached faces (because a new/changed face could
potentially require fresh realization of the faces that depend on the
changed face, and Emacs doesn't track face dependencies and this
cannot know which ones, if any, need to be recomputed).  If this
happens, and if Emacs also needs to redraw the portions of the display
that used one of the "forgotten" faces, it crashes.  So this requires
a relatively rare combination of factors, and so went under the radar
for a long time.  I think it was exposed more lately because we
consistently introduced more and more redisplay optimizations, which
increased the probability of these rare situations because they allow
Emacs to avoid examining faces in larger areas of its display, thus
failing to recompute them after discarding the cached faces.