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 17:44:39 +0300

> Date: Thu, 05 Sep 2024 17:33:53 +0300
> From: Eli Zaretskii <eliz@gnu.org>
> Cc: execvy@gmail.com, pipcet@protonmail.com, emacs-devel@gnu.org
> 
> > From: Gerd Möllmann <gerd.moellmann@gmail.com>
> > Cc: execvy@gmail.com,  pipcet@protonmail.com,  emacs-devel@gnu.org
> > Date: Thu, 05 Sep 2024 15:57:50 +0200
> > 
> > Eli Zaretskii <eliz@gnu.org> writes:
> > 
> > >> That means FRAME_OUTPUT_DATA can be null during the lifetime of a
> > >> frame. If that happens, we'll crash exactly in that way in the new code
> > >> for window frames.
> > >
> > > We never test for FRAME_OUTPUT_DATA being non-NULL in the code, so I
> > > don't think I understand why igc.c is different.
> > 
> > Our scan functions can run at arbitrary times, including when
> > FRAME_OUTPUT_DATA is still null.
> 
> OK, but if you look at the backtrace, you will see that in this case
> the scan functions were run from within code called by
> redisplay_internal, so I very much doubt that FRAME_OUTPUT_DATA was
> NULL in this case.

But ultimately, it is best to see what happens with our own eyes.  So,
Eval EXEC, next time this happens, please do:

  (gdb) frame 24
  (gdb) p f
  (gdb) p f->output_data
  (gdb) p f->output_data.x
  (gdb) p f->output_data.x->display_info
  (gdb) p f->output_data.x->display_info->mouse_highlight

Here, "frame 24" should get you to this frame:

  #24 0x0000000000692cd8 in fix_frame (f=0x7fdff9ce8f48, ss=0x7ffcfd2025f8) at 
/home/exec/Projects/git.savannah.gnu.org/git/emacs/src/igc.c:2068

If it doesn't change "24" to the number of frame where we are in
fix_frame on line 2068 of igc.c.



reply via email to

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