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

[Codrut Gusoi]

Yes there is a reliable recipe to reproduce.

I've prepared the VM, just let me know how I should send you the login
credentials (without the whole internet getting their hands on them)
since I can not write them here.

The exact recipe is described in my first email, here is what you need
to do on the VM now that I set it up:

First make sure your terminal is either maximized or fullscreen. Then

cd ~/emacs
emacs -nw .

Now that you have emacs running you should wait untill you see 2
windows: neotree on the left and dired on the right. You need to type:
<SPACE> p f. That is 'spacebar' followed by a 'p' followed by an 'f',
lower case. This will open helm on the lower part of the screen. From
here type what's between the quotes here: "src/term.c" then press
return (RET). You will have to wait a few seconds, then the segfault
will happen.

This is an Ubuntu 14.04 VM, you should be able to do anything you
please with it.

I am also available to chat on any platform you desire if you need
real time feedback from me.

On Mon, Mar 20, 2017 at 8:46 PM, Eli Zaretskii <eliz@gnu.org> wrote:
> [Please keep the bug address on the CC list.]
>
>> From: Codrut Gusoi <codrut.gusoi@gmail.com>
>> Date: Mon, 20 Mar 2017 14:16:29 +0200
>>
>> I've tried watching the `used` count with `watch -l` and there is no
>> place where the font cache shrinks for the current frame. I believe
>> what I experineced previously was the `used` count from different
>> frames (since I added a breakpoint but did not look at the frame
>> address).
>
> For the bug you describe to happen, the 'used' count of a frame's face
> cache _must_ be reset to zero at some point.  There simply isn't any
> other way to "lose" faces from the cache.  So if you don't see that,
> it means you didn't succeed to reproduce the problem.
>
>> Have you managed to reproduce it locally?
>
> No.
>
>> If not, what do you say I set up a VM in AWS and give you the IP and
>> login details to take a look.
>
> That could work if there's a more-or-less reliable recipe for
> reproducing the problem.  Is there?
>
> If there is not recipe, I won't be able to investigate the path to
> disaster, and when the segfault happens, it's already too late.