bug#26097: Segmentation fault due to missing faces in face_cache.

[Eli Zaretskii <eliz@gnu.org>]

> From: Codrut Gusoi <codrut.gusoi@gmail.com>
> Date: Tue, 14 Mar 2017 15:49:49 +0200
> 
> This is a bit weird to describe so please bear with me.

Thanks for your investigations.

This should not happen: the display engine attempts to prevent faces
from being released while it works on redrawing a frame.  So something
doesn't quite work as planned here.

However, the patches you propose don't really solve the problem, they
are just band-aids.  I'd like to try to find the real reason for the
problem and fix it.

> - Before opening helm in the setup above there are 28 faces in the face_cache.
> - After I open helm the cache fills with around 48 faces.
> - When i hit return after selecting a file, the cache fills up with
> more faces, until it gets to displaying the frame corresponding to the
> file (buffer). Then the face_cache drops to 33 (f->used == 33).

Can you show the backtrace from where the face use count drops?  One
way of doing that is to put a conditional watchpoint on the cache's
'used' count with the condition that it becomes smaller (or maybe
zero).  Make sure you use "watch -l" to avoid automatic deletion of
the watchpoint when some variable goes out of scope.

> - When it gets to the line where it must redisplay helm (vpos == 29 on
> dgb frame 2 above), it wants to redisplay the faces for helm but they
> are no longer in the cache, so FACE_FROM_ID returns NULL and a crash
> happens when the code dereferences the porinter a line below.

The display engine tries to prevent this by setting
inhibit_free_realized_faces to a non-zero value, but I guess something
doesn't quite work in that regard.  I wonder what that is.

Thanks.