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

Ok, but the check for FRAME_OUTPUT_DATA is missing in any case.

I guess it's X in this case? That would mean output_data.x->display_info
would be null. Don't know at the moment how that happens. And I wonder
if it crashes here in fix_frame, then

    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;
                           ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^

AFAIU, that's the same case? FRAME_OUTPUT_DATA would be non-null, and we
access something via FRAME_DISPLAY_INFO. Do we know something about
crashes there?