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: Eval EXEC
Subject: Re: [scratch/igc] 985247b6bee crash on Linux, KDE, Wayland
Date: Fri, 06 Sep 2024 01:29:55 +0800

Pip Cet <pipcet@protonmail.com> writes:

> "Eval EXEC" <execvy@gmail.com> writes:
>
>> 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 reproduce the crash again:
>
> Thanks! I think we crash when scanning deleted frames, and I'll push a
> tentative fix in a bit (but it would be good to be sure first, as Eli
> had another viable theory for what might have happened).
>
>> Its build by -O2:
>> ```bash
>> #!/usr/bin/env bash
>> set -ex
>>
>> make extraclean
>>
>> BRANCH_NAME=$(git branch --show-current | sed 's/\//_/g')
>> COMMIT_ID=$(git rev-parse --short=8 HEAD)
>> BUILD_DIR=${BRANCH_NAME}-commit-${COMMIT_ID}
>> INSTALL_PREFIX=$(realpath ../emacs-build/${BUILD_DIR})
>>
>> ./autogen.sh
>> ./configure CFLAGS='-g3 -ggdb -O2 -fno-omit-frame-pointer -mtune=native 
>> -march=native' \
>>   --prefix=${INSTALL_PREFIX} \
>>   --with-mps=yes \
>>   --with-imagemagick  \
>>   --with-modules \
>>   --without-compress-install \
>>   --with-native-compilation  --with-mailutils\
>>   --enable-link-time-optimization \
>>   --with-tree-sitter --with-xinput2  \
>>   --with-dbus  --with-native-compilation=aot \
>>   --with-file-notification=inotify\
>>   && make -j30 install
>>
>> rm ../emacs-build/emacs
>> ln -s ${INSTALL_PREFIX} ../emacs-build/emacs
>
>
>
>> #24 0x0000000000692cd8 in fix_frame (f=0x7fe4284bb270,
>> ss=0x7ffd2708ff28) at
>> /home/exec/Projects/git.savannah.gnu.org/git/emacs/src/igc.c:2068
>>         hlinfo = <optimized out>
>>         _ss = 0x7ffd2708ff28
>>         _mps_zs = <optimized out>
>>         _mps_ufs = 144115188176519176
>>         _mps_wt = <optimized out>
>>         _mps_w = <optimized out>
>
> Can you run the commands Eli posted?  They were:
>
>>  (gdb) frame 24
>>  (gdb) p f
>>  (gdb) p f->output_data
>>  (gdb) p f->output_data.x
>>  (gdb) p f->output_data.x->display_info
>>  (gdb) p f->output_data.x->display_info->mouse_highlight
>
> Thanks!
>
> Pip

I created a video to show how the crash happen:
https://youtu.be/baHyYHC39_U

Thanks

Eval Exec
-- 



reply via email to

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