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

[Eli Zaretskii]

> From: Rainer M Krug <Rainer@krugs.de>
> Cc: 21428@debbugs.gnu.org,  mituharu+bug-gnu-emacs-mac@math.s.chiba-u.ac.jp
> Date: Thu, 24 Sep 2015 20:37:00 +0200
> 
> > It helps: the offending line seems to be the one that shows this:
> >
> >        - [ ] ownFree
> >
> > with "ownFree" highlighted by a green underwave.  Do you know what is
> > that underwave face?  (If you don't, you could recreate the buffer in
> > a live session, then go to that place and type "M-x
> > describe-text-properties RET".)
> 
> In the life session, I get the following: (as I continued some editing,
> the position might be off compared to the session which crashed)
> 
> ,----
> | Text content at position 34253:
> | 
> | 
> | There is an overlay here:
> |  From 34252 to 34259
> |   evaporate            t
> |   face                 flyspell-duplicate
> |   flyspell-overlay     t
> |   help-echo            "mouse-2: correct word at point"
> |   keymap               [Show]
> |   mouse-face           highlight

OK, so the face is flyspell-duplicate.

> ,----
> | Face: flyspell-duplicate (sample) (customize this face)
> | 
> | Documentation:
> | Flyspell face for words that appear twice in a row.
> | See also ‘flyspell-duplicate-distance’.
> | 
> | Defined in ‘flyspell.el’.
> | 
> |            Family: unspecified
> |           Foundry: unspecified
> |             Width: unspecified
> |            Height: unspecified
> |            Weight: unspecified
> |             Slant: unspecified
> |        Foreground: unspecified
> | DistantForeground: unspecified
> |        Background: unspecified
> |         Underline: (:style wave :color #008000)
> |          Overline: unspecified
> |    Strike-through: unspecified
> |               Box: unspecified
> |           Inverse: unspecified
> |           Stipple: unspecified
> |              Font: unspecified
> |           Fontset: unspecified
> |           Inherit: nil
> | 
> | [back]
> `----
> 
> Anything strange here?

No, looks perfectly OK.  The problem is not with the face itself, it's
with its "realization" and caching by the display engine.

> I leave the session as it is to provide further info.

Actually, I think we've got all the info I need at this point.

We now need to repeat this procedure in another 2 or 3 similar
crashes: display the face ID, the "used" count of the frame's face
cache, then use "pgrow" in the call-stack frame that calls the
'draw_glyphs' function, to show the text to be displayed in that face,
and finally see which face it is in a "live" display.  Maybe we will
see some pattern common to all those cases, although I'm starting to
doubt that.

Thanks.