bug-gnu-emacs
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

bug#43700: 28.0.50; Crash creating a second frame


From: Eli Zaretskii
Subject: bug#43700: 28.0.50; Crash creating a second frame
Date: Thu, 01 Oct 2020 15:53:53 +0300

> From: Andy Moreton <andrewjmoreton@gmail.com>
> Date: Wed, 30 Sep 2020 21:06:01 +0100
> 
> #1  0x00000004002727cc in emacs_abort () at 
> C:/emacs/git/emacs/master/src/w32fns.c:10832
>         button = 0x6
> #2  0x000000040010d005 in terminate_due_to_signal (sig=0xb, 
> backtrace_limit=0x28) at C:/emacs/git/emacs/master/src/emacs.c:408
> No locals.
> #3  0x0000000400137156 in handle_fatal_signal (sig=0xb) at 
> C:/emacs/git/emacs/master/src/sysdep.c:1768
> No locals.
> #4  0x0000000400137129 in deliver_thread_signal (sig=0xb, handler=0x40013713e 
> <handle_fatal_signal>) at C:/emacs/git/emacs/master/src/sysdep.c:1760
>         old_errno = 0x2
> #5  0x0000000400137192 in deliver_fatal_thread_signal (sig=0xb) at 
> C:/emacs/git/emacs/master/src/sysdep.c:1780
> No locals.
> #6  0x0000000400313e52 in _gnu_exception_handler (exception_data=0xbf9380) at 
> C:/_/M/mingw-w64-crt-git/src/mingw-w64/mingw-w64-crt/crt/crt_handler.c:223
>         old_handler = <optimized out>
>         action = 0x0
>         reset_fpu = 0x0
> #7  0x00007ff8cca57ff8 in msvcrt!__C_specific_handler () from 
> C:\WINDOWS\System32\msvcrt.dll
> No symbol table info available.
> #8  0x00007ff8ce3b111f in ntdll!.chkstk () from C:\WINDOWS\SYSTEM32\ntdll.dll
> No symbol table info available.
> #9  0x00007ff8ce35b474 in ntdll!RtlRaiseException () from 
> C:\WINDOWS\SYSTEM32\ntdll.dll
> No symbol table info available.
> #10 0x00007ff8ce3afc4e in ntdll!KiUserExceptionDispatcher () from 
> C:\WINDOWS\SYSTEM32\ntdll.dll
> No symbol table info available.
> #11 0x00000004002c86e5 in lookup_image (f=0x5123410, spec=XIL(0xbc42793), 
> face_id=0xffffffff) at C:/emacs/git/emacs/master/src/image.c:2334
>         img = 0xbc42773
>         hash = 0x5123410
>         face = 0x0
>         foreground = 0x4
>         background = 0x2c0002

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?

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:

  DEFUN ("image-mask-p", Fimage_mask_p, Simage_mask_p, 1, 2, 0,
         doc: /* Return t if image SPEC has a mask bitmap.
  FRAME is the frame on which the image will be displayed.  FRAME nil
  or omitted means use the selected frame.  */)
    (Lisp_Object spec, Lisp_Object frame)
  {
    Lisp_Object mask;

    mask = Qnil;
    if (valid_image_p (spec))
      {
        struct frame *f = decode_window_system_frame (frame);
        ptrdiff_t id = lookup_image (f, spec, -1);  <<<<<<<<<<<<<<

and the prototype of lookup_image says its last argument is an 'int'.
So either this is a GDB bug, or there's some subtle problem here that
I cannot explain (a compiler bug, perhaps?).

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





reply via email to

[Prev in Thread] Current Thread [Next in Thread]