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: Wed, 30 Sep 2015 11:49:10 +0200
> 
> >> No, I mean continue running with them set to t, and see if the crashes
> >> in get_glyph_face_and_encoding are prevented by disabling these
> >> redisplay optimizations.
> >
> > OK - got it. So continue the initial plan.
> 
> They are all set to t and I got the following crash:

One more theory eats dust.

> Let me know if you need any further info - I will leave the session
> open.

Just for the record, please show the usual data about this crash: the
'used' count of the frame's face cache and the output of "pgrow"
command in frame #4.

I guess we are down to using the brute-force approach after all.  I
will prepare a series of GDB commands that you need to invoke before
running a new Emacs session under GDB.  The output will be recorded in
a file, which I will ask you to send me for analysis when a crash
happens.

To prepare those GDB commands, I need to know how many different
frames you are normally using.  If only one, the job of preparing
those commands is easier.  If you normally use more than one frame, do
the crashes happen when you edit in a particular one of them?  IOW,
would it be easy for you to switch to the frame where the crashes are
expected, in order to invoke those GDB commands for that one frame?

Thanks.