bug#43700: 28.0.50; Crash creating a second frame

[Andy Moreton <andrewjmoreton@gmail.com>]

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.

> If 'face' is a NULL pointer there (as your backtrace shows), the next
> line will segfault, and the rest is more-or-less clear.  What I don't
> understand is this part:
> 
>> #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.

> Did you change anything in your development environment lately, like
> installed a different version of the compiler or Binutils or the MinGW
> runtime?

MSYS2 is a rolling release distro, so the runtime, binutils and compiler 
are regularly updated. Currently that is gcc 10.2.0, and binutils 2.35, 
and msys2 runtime 3.1.7, all of which have been updated in recent weeks.

     AndyM