bug#69431: 30.0.50; Strange fontificaion behavior

["Björn Bidar via Bug reports for GNU Emacs, the Swiss army knife of text editors" <bug-gnu-emacs@gnu.org>]

Andrea Corallo <acorallo@gnu.org> writes:

> Björn Bidar <bjorn.bidar@thaodan.de> writes:
>
>> Eli Zaretskii <eliz@gnu.org> writes:
>>
>>>> From: Ihor Radchenko <yantar92@posteo.net>
>>>> Cc: hirofumi@mail.parknet.co.jp, 69431@debbugs.gnu.org
>>>> Date: Tue, 27 Feb 2024 19:26:39 +0000
>>>>
>>>> > So maybe the problem is already solved somehow?
>>>>
>>>> ... or it has something to do with loading built-in Org mode.
>>>> when I do
>>>> 1. emacs -Q
>>>> 2. C-x C-f /tmp/a.org
>>>> I do not see fontification.
>>>>
>>>> when I do
>>>> 1. emacs -Q
>>>> 2. M-: (require 'org)
>>>> 3. C-x C-f /tmp/a.org
>>>> I see fontification...
>>>>
>>>> and when I wait long enough for native compilation to finish, I can see
>>>> fontification without loading org.el.
>>>>
>>>> Not sure if it tells anything useful.
>>>
>>>> From: OGAWA Hirofumi <hirofumi@mail.parknet.co.jp>
>>>> Cc: Ihor Radchenko <yantar92@posteo.net>, 69431@debbugs.gnu.org
>>>> Date: Wed, 28 Feb 2024 04:20:13 +0900
>>>>
>>>> I found a bit more about this. If build with --native-compilation=no, I
>>>> can't reproduce, and at least --native-compilation=aot can reproduce.
>>>
>>> Since this seems to be somehow related to native compilation, I'm
>>> adding Andrea to the discussion, in the hope that he could suggest
>>> some ideas.
>>
>> I have the same error since my last build ref
>> 1687adcb5c93b490e2e7edcd14615af295e791ed same issue later in 6a77355527b2f7f1dca9c2296c2684033c9aa875.
>>
>> When running without gdb Emacs just tells in the minubuffer:
>> Re-entering top level after C-stack overflow.
>
> Okay, might be some recursive dependecy issue while loading?
>>
>> With gdb I get a SIGEGV in lface_from_face_name.
>> I attach two log files I've created. It was hard to get an exact point
>> since the bug only triggers when enough is loaded. At first there's
>> memory corruption but no crash.
>
> Would be cool to have a Lisp backtrace at the moment of the SIGEGV to
> understand what we are trying to load and in which order before we stack
> overflow.
>
> Another idea would be to apply something like the following to
> Frequire, run a make, and run again the reproducer to understand what's
> going on.
>
> modified   src/fns.c
> @@ -3408,6 +3408,7 @@ DEFUN ("require", Frequire, Srequire, 1, 3, 0,
>    bool from_file = load_in_progress;
>
>    CHECK_SYMBOL (feature);
> +  printf ("XXX %s\n", SSDATA (Fsymbol_name (feature)));
>
>    /* Record the presence of `require' in this file
>       even if the feature specified is already loaded.
>
> I'd do the investigation myself but my dev machine went KO yesterday and
> to get it fixed it might take till next week :/
>
> Thanks
>
>   Andrea

I found the culprit of the problem: it's load-theme.
The only theme's could trigger the bugs so far for me where modus
themes.