bug#21394: 25.0.50; Segfault when displaying unprintable character in echo area while frames are being created

[Pip Cet <pipcet@gmail.com>]

[-- Attachment #1.1: Type: text/plain, Size: 1463 bytes --]

On Tue, Sep 1, 2015 at 6:08 PM, Eli Zaretskii <eliz@gnu.org> wrote:

> > Date: Tue, 1 Sep 2015 17:33:10 +0000
> > From: Pip Cet <pipcet@gmail.com>
> >
> > This is the full log, including all my backspacing (so the end might be
> more
> > readable in the edited log I've sent to the list). I'm not sure what the
> size
> > limits are for sending attachments to the list.
> > [...]
> > (gdb) p face
> > $1787 = (struct face *) 0x0
> > (gdb) p it
> > $1788 = (struct it *) 0x7fffffff9de0
> > (gdb) p it->face_id
> > $1789 = 18
> > $1790 = (struct frame *) 0x129f9e0
> > (gdb) p it->f->face_cache->used
> > $1791 = 15
>
> I see the problematic face always has face ID of 18, and the 'used'
> field is always 15 when the segfault strikes.  So I guess the next
> step is to make the breakpoint in cache_face conditional on i being
> 18,


i is used in two different ways in that function, as a face hash and as an
index into faces_by_id. I assume you mean the latter?


> and then see whether c->used is set to 19 during that call to
> cache_face.  If it does, then a watchpoint (by location) on c->used
> should show which code makes the value smaller.
>

So I wrote a perl script to set a watchpoint on c->used whenever we
allocate a new face cache c in make_face_cache, and clear the watchpoint
when we hit free_face_cache. Output attached, but do let me know what else
you would like watched. I think that has all the information your approach
would have given us.

[-- Attachment #1.2: Type: text/html, Size: 2172 bytes --]

[-- Attachment #2: emacs-bug-050.txt.gz --]
[-- Type: application/x-gzip, Size: 289425 bytes --]