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: Wed, 28 Feb 2024 08:53:18 -0500
User-agent: Gnus/5.13 (Gnus v5.13)

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





reply via email to

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