Eli Zaretskii writes: >> From: Rainer M Krug >> Cc: 21428@debbugs.gnu.org, mituharu+bug-gnu-emacs-mac@math.s.chiba-u.ac.jp >> 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", | ) | <> | #+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