bug#43700: 28.0.50; Crash creating a second frame

[Eli Zaretskii]

> Cc: 43700@debbugs.gnu.org
> From: Andy Moreton <andrewjmoreton@gmail.com>
> Date: Fri, 2 Oct 2020 01:38:25 +0100
> 
> On 01/10/2020 13:53, Eli Zaretskii wrote:
> > If you put a breakpoint in lookup_image, on the line indicated below:
> > 
> >    ptrdiff_t
> >    lookup_image (struct frame *f, Lisp_Object spec, int face_id)
> >    {
> >      struct image *img;
> >      EMACS_UINT hash;
> > 
> >      struct face *face = (face_id >= 0) ? FACE_FROM_ID (f, face_id)
> >        : FACE_FROM_ID (f, DEFAULT_FACE_ID);
> >      unsigned long foreground = FACE_COLOR_TO_PIXEL (face->foreground, f); 
> > <<<<
> >      unsigned long background = FACE_COLOR_TO_PIXEL (face->background, f);
> > 
> > and condition the breakpoint by face == 0, does it break before the
> > crash when you perform the steps that reproduces the problem?
> 
> Yes it does.

So the next question is: how come the default face is not available?
When that breakpoint breaks, what is the value of

   FRAME_FACE_CACHE (f)->used

Is it zero, per chance?  If so, I'd be interested to understand which
code resets the frame's face cache in this recipe.

> >> #11 0x00000004002c86e5 in lookup_image (f=0x5123410, spec=XIL(0xbc42793), 
> >> face_id=0xffffffff) at C:/emacs/git/emacs/master/src/image.c:2334
> > 
> > Why does face_id have the value 0xffffffff?  The caller passes -1:
> 
> This seems to be because I have "set output-radix 16" in ~/.gdbinit, so 
> it displays the raw hex value. After "set output-radix 10" it displays 
> the value as -1. Nothing untoward here.

Ah, okay.  Nothing to worry about, then.

Thanks.