Eli Zaretskii writes: >> From: Rainer M Krug >> Cc: 21428@debbugs.gnu.org >> Date: Mon, 26 Oct 2015 08:59:39 +0100 >> >> the bug does not affect to many users (strange config? OS X?). > > It's not really true that it didn't affect others. We have in the bug > tracker a few similar bug reports where an invalid face ID was the > culprit, I believe they were caused by the same problem. > > It's true that these problems are rare. That's because, for this > situation to happen, you need to have some to enable feature that can > create new faces or change existing faces in code that is invoked by > redisplay, for example some Lisp form that gets evaluated while > displaying the mode line. When a face is created or changed, Emacs > forgets all the cached faces (because a new/changed face could > potentially require fresh realization of the faces that depend on the > changed face, and Emacs doesn't track face dependencies and this > cannot know which ones, if any, need to be recomputed). If this > happens, and if Emacs also needs to redraw the portions of the display > that used one of the "forgotten" faces, it crashes. So this requires > a relatively rare combination of factors, and so went under the radar > for a long time. I think it was exposed more lately because we > consistently introduced more and more redisplay optimizations, which > increased the probability of these rare situations because they allow > Emacs to avoid examining faces in larger areas of its display, thus > failing to recompute them after discarding the cached faces. Thanks for the explanations - makes sense. Cheers, 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: Rainer@krugs.de Skype: RMkrug PGP: 0x0F52F982