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 16:52:55 +0300

> 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:37:38 +0200
> 
> Eli Zaretskii <eliz@gnu.org> writes:
> 
> >> Hm, sesms we have to check for FRAME_OUTPUT_DATA being null for window
> >> frames.
> >
> > Why do you think so?  Are we sure FRAME_OUTPUT_DATA is NULL in this
> > case (as opposed to a pointer that cannot be dereferenced because it
> > was moved)?
> 
> I would be 100% sure only if I had it in the debugger :-).
> But if you look a bit further down in fix_frame:
> 
>     if (FRAME_WINDOW_P (f) && FRAME_OUTPUT_DATA (f))
>       {
>       struct font **font_ptr = &FRAME_FONT (f);
>       if (*font_ptr)
>         IGC_FIX12_PVEC (ss, font_ptr);
>       Lisp_Object *nle = &FRAME_DISPLAY_INFO (f)->name_list_element;
> 
> 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.



reply via email to

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