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

[Gerd Möllmann]

Eli Zaretskii <eliz@gnu.org> writes:

>> 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.

Our scan functions can run at arbitrary times, including when
FRAME_OUTPUT_DATA is still null.