Eli Zaretskii writes: >> From: Rainer M Krug >> Cc: 21428@debbugs.gnu.org, mituharu+bug-gnu-emacs-mac@math.s.chiba-u.ac.jp >> Date: Mon, 28 Sep 2015 11:33:49 +0200 >> >> > First, I'd like to know whether the line of code marked below is ever >> > executed: >> > >> > static void >> > uncache_face (struct face_cache *c, struct face *face) >> > { >> > int i = face->hash % FACE_CACHE_BUCKETS_SIZE; >> > >> > if (face->prev) >> > face->prev->next = face->next; >> > else >> > c->buckets[i] = face->next; >> > >> > if (face->next) >> > face->next->prev = face->prev; >> > >> > c->faces_by_id[face->id] = NULL; >> > if (face->id == c->used) >> > --c->used; <<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<< >> > } >> > >> > This is from xfaces.c, line 4322 with the current Git master. Please >> > put a breakpoint there, and run Emacs under GDB until it crashes as >> > before, or until this breakpoint breaks. If it breaks, please show >> > the backtrace. >> >> OK - Emacs crashed again (same pattern) and the breakpoint was >> triggered: >> >> ,---- >> | xdisp.c:24333: Emacs fatal error: assertion failed: face != NULL > > You mean, the breakpoint did NOT trigger, right? Because I cannot see > any backtraces from the breakpoint in uncache_face. Did I miss > something? No - I missed something. I am new to gdb and sometimes (often?) get confused. This is the latest one - and if I understand correctly, again not triggered. ,---- | xdisp.c:19795: Emacs fatal error: assertion failed: it->method == GET_FROM_BUFFER || it->method == GET_FROM_DISPLAY_VECTOR || it->method == GET_FROM_STRING | | Breakpoint 1, terminate_due_to_signal (sig=6, backtrace_limit=2147483647) at emacs.c:370 | 370 signal (sig, SIG_DFL); | (gdb) `---- > >> I am sure the crash occurs again, so please let me know what further >> info you need from the next crash. > > If indeed the breakpoint in uncache_face never breaks, please proceed > to configuring Emacs with --enable-checking='yes,glyphs' and disabling > the redisplay optimizations, as I've described here: OK - I will reconfigure then. > >> > If this breakpoint never breaks before another crash, please >> > reconfigure Emacs like this: >> > >> > CFLAGS="-ggdb3 -O0" CXXFLAGS="-ggdb3 -O0" LDFLAGS="-ggdb3" ./configure --enable-checking='yes,glyphs' reconfiguring. >> > >> > then rebuild, and run it after setting these three variables to t: >> > >> > inhibit-try-cursor-movement >> > inhibit-try-window-id >> > inhibit-try-window-reusing OK - I evaluated (setq inhibit-try-cursor-movement t) (setq inhibit-try-window-id t) (setq inhibit-try-window-reusing t) immediately in scratch after starting emacs - is this correct? >> > >> > This disables some redisplay optimizations, so you might see slow >> > redisplay; this is normal. What is important is to see whether the >> > crashes disappear when these variables are set to non-nil values. If >> > you run for a long time without crashes, then set these variables to >> > nil, one by one, in the order they are shown above, and each time let >> > Emacs run enough time for you to be sure the problem doesn't happen, >> > before you proceed to the next variable. OK - running emacs now with all set to t = will keep you posted. Thanks, Rainer > > Thanks. -- 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