emacs-devel
[Top][All Lists]
Advanced

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

Re: [scratch/igc] 985247b6bee crash on Linux, KDE, Wayland


From: Eli Zaretskii
Subject: Re: [scratch/igc] 985247b6bee crash on Linux, KDE, Wayland
Date: Thu, 05 Sep 2024 21:46:40 +0300

> From: Gerd Möllmann <gerd.moellmann@gmail.com>
> Cc: Pip Cet <pipcet@protonmail.com>,  Eli Zaretskii <eliz@gnu.org>,
>   emacs-devel@gnu.org
> Date: Thu, 05 Sep 2024 19:16:14 +0200
> 
> Eval EXEC <execvy@gmail.com> writes:
> 
> > (gdb) p f->output_data
> > $2 = {
> >   tty = 0x0,
> >   x = 0x0,
> 
> That's the FRAME_OUTPUT_DATA thing I mentioned. I pushed something for
> that now, please give it a try.

Thanks, but I don't think this is the right change.  It is not useful
to make MOUSE_HL_INFO return NULL, because it is immediately
dereferenced in many places in the Emacs code.  Here's one example:

  /* If a row with mouse-face was overwritten, arrange for
     frame_up_to_date_hook to redisplay the mouse highlight.  */
  if (mouse_face_overwritten_p)
    {
      Mouse_HLInfo *hlinfo = MOUSE_HL_INFO (f);

      hlinfo->mouse_face_beg_row = hlinfo->mouse_face_beg_col = -1;
      hlinfo->mouse_face_end_row = hlinfo->mouse_face_end_col = -1;
      hlinfo->mouse_face_window = Qnil;
    }

GCC emits warnings in all of these places, like this:

  dispnew.c: In function 'gui_update_window_end':
  dispnew.c:3991:34: warning: potential null pointer dereference 
[-Wnull-dereference]

   3991 |       hlinfo->mouse_face_beg_row = hlinfo->mouse_face_beg_col = -1;
        |       ~~~~~~~~~~~~~~~~~~~~~~~~~~~^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
  dispnew.c:3992:63: warning: potential null pointer dereference 
[-Wnull-dereference]

   3992 |       hlinfo->mouse_face_end_row = hlinfo->mouse_face_end_col = -1;
        |                                    ~~~~~~~~~~~~~~~~~~~~~~~~~~~^~~~
  dispnew.c:3992:34: warning: potential null pointer dereference 
[-Wnull-dereference]

If we think that fix_frame can be called for a frame that was deleted,
we should test FRAME_LIVE_P, like we do elsewhere.

So please fix it in some other way.



reply via email to

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