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: Thu, 24 Sep 2015 19:22:48 +0200
> 
> >> | (gdb) pgrow
> >> | TEXT: 22 glyphs
> >> |   0    0: CHAR[*] str=0xc3502c8[0] blev=0,btyp=L w=8 a+d=14+4 face=17 AVOID
> >> |   1    8: CHAR[*] str=0xc3502c8[1] blev=0,btyp=L w=8 a+d=14+4 face=17 AVOID
> >> |   2   16: CHAR[*] str=0xc3502c8[2] blev=0,btyp=L w=8 a+d=14+4 face=17 AVOID
> >> |   3   24: CHAR[*] str=0xc3502c8[3] blev=0,btyp=L w=8 a+d=14+4 face=17 AVOID
> >> |   4   32: CHAR[*] str=0xc3502c8[4] blev=0,btyp=L w=8 a+d=14+4 face=17 AVOID
> >> |   5   40: CHAR[*] str=0xc3502c8[5] blev=0,btyp=L w=8 a+d=14+4 face=17 AVOID
> >> |   6   48: CHAR[*] str=0xc3502c8[6] blev=0,btyp=L w=8 a+d=14+4 face=17 AVOID
> >> |   7   56: CHAR[ ] str=0xc3502c8[7] blev=0,btyp=L w=8 a+d=14+4 AVOID
> >> |   8   64: CHAR[-] pos=34336 blev=0,btyp=L w=8 a+d=14+4 MB
> >> |   9   72: CHAR[ ] pos=34337 blev=0,btyp=L w=8 a+d=14+4 MB
> >> |  10   80: CHAR[[] pos=34338 blev=0,btyp=L w=8 a+d=14+4 face=18 MB
> >> |  11   88: CHAR[ ] pos=34339 blev=0,btyp=L w=8 a+d=14+4 face=18 MB
> >> |  12   96: CHAR[]] pos=34340 blev=0,btyp=L w=8 a+d=14+4 face=18 MB
> >> |  13  104: CHAR[ ] pos=34341 blev=0,btyp=L w=8 a+d=14+4 MB
> >> |  14  112: CHAR[o] pos=34342 blev=0,btyp=L w=8 a+d=14+4 face=31 MB
> >> |  15  120: CHAR[w] pos=34343 blev=0,btyp=L w=8 a+d=14+4 face=31 MB
> >> |  16  128: CHAR[n] pos=34344 blev=0,btyp=L w=8 a+d=14+4 face=31 MB
> >> |  17  136: CHAR[F] pos=34345 blev=0,btyp=L w=8 a+d=14+4 face=31 MB
> >> |  18  144: CHAR[r] pos=34346 blev=0,btyp=L w=8 a+d=14+4 face=31 MB
> >> |  19  152: CHAR[e] pos=34347 blev=0,btyp=L w=8 a+d=14+4 face=31 MB
> >> |  20  160: CHAR[e] pos=34348 blev=0,btyp=L w=8 a+d=14+4 face=31 MB
> >> |  21  168: CHAR[ ] pos=0 blev=0,btyp=B w=8 a+d=14+4 MB
> >> | (gdb) xbacktrace
> >> | "redisplay_internal (C function)" (0x0)
> >> | "redisplay" (0x5fbfaa68)
> >> | "sit-for" (0x5fbfb430)
> >> | "isearch-lazy-highlight-new-loop" (0x5fbfbe00)
> >> | "replace-highlight" (0x5fbfc7f0)
> >> | "perform-replace" (0x5fbfd220)
> >> | "query-replace" (0x5fbfdd90)
> >> | "funcall-interactively" (0x5fbfdd88)
> >> | "call-interactively" (0x5fbfe6a0)
> >> | "command-execute" (0x5fbff090)
> >
> > Given the above characters displayed on one offending screen lines,
> > can you figure out what kind of face is #31, the one which should be
> > used to display the 7 last characters "ownFree"?
> 
> If you tell me how, I could do this.

Recreate the same display, then use describe-text-properties, see
below.

> How did you identify the characters "ownFree" as causing the being
> in that face?

See the output of the "pgrow" command above:

> >> |  14  112: CHAR[o] pos=34342 blev=0,btyp=L w=8 a+d=14+4 face=31 MB
> >> |  15  120: CHAR[w] pos=34343 blev=0,btyp=L w=8 a+d=14+4 face=31 MB
> >> |  16  128: CHAR[n] pos=34344 blev=0,btyp=L w=8 a+d=14+4 face=31 MB
> >> |  17  136: CHAR[F] pos=34345 blev=0,btyp=L w=8 a+d=14+4 face=31 MB
> >> |  18  144: CHAR[r] pos=34346 blev=0,btyp=L w=8 a+d=14+4 face=31 MB
> >> |  19  152: CHAR[e] pos=34347 blev=0,btyp=L w=8 a+d=14+4 face=31 MB
> >> |  20  160: CHAR[e] pos=34348 blev=0,btyp=L w=8 a+d=14+4 face=31 MB

This shows that characters at columns 14 to 20 that come buffer
positions 34342 through 34340 are "ownFree" and should be displayed
with face=31.

> > Could this by any chance be the 'query-replace' face used by the
> > command query-replace to highlight the matches?
> 
> No - see the attached screenshot - maybe it helps you?

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".)

> >> By the way: these crashes usually happen when I do something quickly -
> >> e.g. here I search-replaced some trivial string in org code blocks, the
> >> last time I deleted repeatedly result blocks and empty lines.
> >
> > If the face involved in these crashes is different each time, we will
> > need to trace all operations that use frame face cache.  But we've not
> > yet established that.
> 
> Hopefully it is easier.

Let's hope.

Thanks.