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

From: Rainer M Krug <[email-masked]>
Date: Mon, 28 Sep 2015 13:12:53 +0200

Eli Zaretskii <[email-masked]> writes:

>> From: Rainer M Krug <[email-masked]>
>> Cc: [email-masked],  [email-masked]
>> 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:      [email-masked]

Skype:      RMkrug

PGP: 0x0F52F982