bug-gnu-emacs
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

bug#69431: 30.0.50; Strange fontificaion behavior


From: Andrea Corallo
Subject: bug#69431: 30.0.50; Strange fontificaion behavior
Date: Sun, 03 Mar 2024 12:01:22 -0500
User-agent: Gnus/5.13 (Gnus v5.13)

Björn Bidar <bjorn.bidar@thaodan.de> writes:

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

Hi Björn,

thanks.  Sorry I had to pause on this as I'm focused on fixing
everything I've broke recently on master 😅.  I'll be back on looking at
this soon.

  Andrea





reply via email to

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