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

[Pip Cet <pipcet@protonmail.com>]

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

But the frame we crashed tracing wasn't the same frame that was being
redisplayed.  It's possible it was a destroyed ("dead") frame, right?
Then frame destruction would have freed and subsequently zeroed its
FRAME_OUTPUT_DATA.

However, debugging further is the only way to be sure.  If the OP still
has the core dump + executable for this crash, that should contain the
necessary data, even without waiting for the crash to happen again.

And it definitely looks like a different bug from the previous reports,
which all involved consing up a list in -O3 code using -march=native.

Pip