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

From: Rainer M Krug <[email-masked]>
Date: Thu, 24 Sep 2015 19:22:48 +0200

Eli Zaretskii <[email-masked]> writes:

>> From: Rainer M Krug <[email-masked]>
>> Cc: [email-masked],  [email-masked]
>> Date: Thu, 24 Sep 2015 15:22:22 +0200
>> 
>> OK - next crash and the session is open. I give you here some output:
>
> Thanks, we are getting somewhere.

That is good to hear.

>
>> | #7 0x0000000100063797 in get_glyph_face_and_encoding
>> | (f=0x10201bba0, glyph=0x11c159ea0, char2b=0x7fff5fbf73c0) at
>> | xdisp.c:24330
>> | 	face = (struct face *) 0x0
>> | 	code = 0
>> | #8 0x00000001000b5ffd in fill_glyph_string (s=0x7fff5fbf73d0,
>> | face_id=31, start=14, end=22, overlaps=0) at xdisp.c:24555
>                                                                    ^^^^^^^^^^
> Here, Emacs tries to display characters 14..21 of some screen line
> with face whose cache index is 31.  But there's no such face in the
> cache, so FACE_FROM_ID returns NULL, and the assertion on line 24330
> of xdisp.c aborts Emacs.

OK

>
>> | (gdb) p f->face_cache->used
>> | $1 = 31
>
> Here we see that the frame's face cache knows only about faces whose
> indices are zero to 30, inclusive.  There's no face number 31 in the
> cache.

Makes sense.

>
>> | (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. How did you identify the characters
"ownFree" as causing the being in that face?

The last lines continue like this - if it helps:

,----
| - [ ] mahat ::
| #+begin_src R
| fn <- file.path(CACHE, "wpFitMultiple.fitOptim.wpLEL.mahat.multiple_NelderMead..rds")
| 
| fileNames <- list(
|     mahat.fit.all   = "wpFitMultiple.fitOptim.wpLEL.mahat.multiple_NelderMead.fit_all",
|     mahat.fit.10    = "wpFitMultiple.fitOptim.wpLEL.mahat.multiple_NelderMead.fit_10x100",
|     mahat.fit.100   = "wpFitMultiple.fitOptim.wpLEL.mahat.multiple_NelderMead.fit_100x100",
|     mahat.excl.1    = "wpFitMultiple.fitOptim.wpLEL.mahat.multiple_NelderMead.excl_1x50"
| ##     mahat.excl.10   = "wpFitMultiple.fitOptim.wpLEL.mahat.multiple_NelderMead.excl_10x50",
|     )
| <<analysisMultiple>>
| #+end_src
| 
`----

> 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?

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

Thanks,

Rainer

-- 
Rainer M. Krug, PhD (Conservation Ecology, SUN), MSc (Conservation Biology, UCT), Dipl. Phys. (Germany)

Centre of Excellence for Invasion Biology
Stellenbosch University
South Africa

Tel :       +33 - (0)9 53 10 27 44
Cell:       +33 - (0)6 85 62 59 98
Fax :       +33 - (0)9 58 10 27 44

Fax (D):    +49 - (0)3 21 21 25 22 44

email:      [email-masked]

Skype:      RMkrug

PGP: 0x0F52F982