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

[Eval EXEC]

Pip Cet <pipcet@protonmail.com> writes:

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

I still have the core dump file, but I don't remember the backtrace is
produced by -O2 or O3.

What gdb instructions should I  execute to help you debug this issue?

Thanks.

Eval Exec
--