all messages for Emacs-related lists mirrored at yhetil.org
 help / color / mirror / code / Atom feed
From: Andrea Corallo <acorallo@gnu.org>
To: "Björn Bidar" <bjorn.bidar@thaodan.de>
Cc: 69431@debbugs.gnu.org, Eli Zaretskii <eliz@gnu.org>,
	Ihor Radchenko <yantar92@posteo.net>,
	hirofumi@mail.parknet.co.jp
Subject: bug#69431: 30.0.50; Strange fontificaion behavior
Date: Wed, 28 Feb 2024 14:34:07 -0500	[thread overview]
Message-ID: <yp1bk805qog.fsf@fencepost.gnu.org> (raw)
In-Reply-To: <87zfvkfrw0.fsf@> ("Björn Bidar"'s message of "Wed, 28 Feb 2024 18:57:51 +0200")

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?
> It does sound like it.
>
>>>
>>> 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)));
>
> I added the message in the case of my init.el it looks like this:
> XXX comp
> XXX bytecomp
> XXX backquote
> XXX macroexp
> XXX cconv
> XXX cl-lib
> XXX macroexp
> XXX gv
> XXX macroexp
> XXX rx
> XXX subr-x
> XXX warnings
> XXX icons
> XXX cl-lib
> XXX comp-common
> XXX comp-cstr
> XXX cl-lib
> XXX cl-extra
> XXX cl-lib
> XXX seq
> XXX help-mode
> XXX cl-lib
> XXX cl-lib
> XXX borg
> XXX bytecomp
> XXX cl-lib
> XXX info
> XXX pcase
> XXX macroexp
> XXX subr-x
> XXX loaddefs-gen
> XXX radix-tree
> XXX lisp-mnt
> XXX generate-lisp-file
> XXX eieio
> XXX eieio-core
> XXX cl-lib
> XXX cl-macs
> XXX cl-lib
> XXX macroexp
> XXX gv
> XXX cl-generic
> XXX bytecomp
> XXX macroexp
> XXX use-package
> XXX use-package-core
> XXX bytecomp
> XXX cl-lib
> XXX tabulated-list
> XXX use-package-bind-key
> XXX use-package-core
> XXX bind-key
> XXX cl-lib
> XXX easy-mmode
> XXX use-package-diminish
> XXX use-package-core
> XXX use-package-delight
> XXX use-package-core
> XXX use-package-ensure
> XXX cl-lib
> XXX use-package-core
> XXX comp-run
> XXX comp-common
> XXX bytecomp
> XXX epkg
> XXX compat
> XXX llama
> XXX seq
> XXX seq
> XXX subr-x
> XXX closql
> XXX compat
> XXX eieio
> XXX eieio-base
> XXX eieio
> XXX seq
> XXX emacsql
> XXX cl-lib
> XXX cl-generic
> XXX eieio
> XXX emacsql-compiler
> XXX cl-lib
> XXX cl-lib
> XXX cl-lib
> XXX cl-lib
> XXX cl-lib
> XXX cl-lib
> XXX cl-lib
> XXX gv
> XXX cl-lib
> XXX cl-lib
> XXX cl-lib
> XXX cl-lib
> XXX cl-lib
> XXX cl-lib
> XXX cl-lib
> XXX cl-lib
> XXX cl-lib
> XXX emacsql-sqlite-common
> XXX emacsql
> XXX cl-lib
> XXX subr-x
> XXX cl-lib
> XXX cl-lib
> XXX cl-lib
> XXX cl-lib
> XXX cl-lib
> XXX cl-lib
> XXX cl-lib
> XXX cl-lib
> XXX cl-lib
> XXX cl-lib
> XXX cl-lib
> XXX cl-lib
> XXX cl-lib
> XXX cl-lib
> XXX cl-lib
> XXX cl-lib
> XXX cl-lib
> XXX cl-lib
> XXX cl-lib
> XXX cl-lib
> XXX cl-lib
> XXX cl-lib
> XXX cl-lib
> XXX cl-lib
> XXX cl-lib
> XXX cl-lib
> XXX cl-lib
> XXX cl-lib
> XXX macroexp
> XXX cl-lib
> XXX cl-lib
> XXX cl-lib
> XXX epkg-desc
> XXX epkg
> XXX find-func
> XXX wid-edit
> XXX cl-lib
> XXX cl-lib
> XXX epkg-list
> XXX epkg
> XXX epkg-desc
> XXX epkg-utils
> XXX epkg
> XXX cl-lib
> XXX cl-lib
> XXX epkg-elpa
> XXX epkg
> XXX json
> XXX map
> XXX seq
> XXX subr-x
> XXX no-littering
> XXX cl-lib
> XXX compat
> XXX custom
> XXX select
> XXX saveplace
> XXX cl-lib
> XXX cl-lib
> XXX seq
> XXX kmacro
> XXX replace
> XXX cl-lib
> XXX desktop
> XXX cl-lib
> XXX frameset
> XXX cl-lib
> XXX printing
> XXX lpr
> XXX ps-print
> XXX lpr
> XXX ps-print-loaddefs
> XXX cus-face
> XXX wid-edit
> XXX icons
> XXX cus-load
> XXX cus-start
> XXX cl-lib
> XXX cus-load
> XXX cus-start
> XXX cus-start
> XXX auth-source-pass
> XXX seq
> XXX cl-lib
> XXX auth-source
> XXX json
> XXX password-cache
> XXX cl-lib
> XXX eieio
> XXX url-parse
> XXX url-vars
> XXX auth-source
> XXX helm-pass
> XXX helm
> XXX helm-core
> XXX cl-lib
> XXX async
> XXX cl-lib
> XXX helm-lib
> XXX cl-lib
> XXX cl-lib
> XXX cl-lib
> XXX helm-multi-match
> XXX cl-lib
> XXX helm-lib
> XXX helm-source
> XXX cl-lib
> XXX eieio
> XXX helm-lib
> XXX cl-lib
> XXX cl-lib
> XXX cl-lib
> XXX cl-lib
> XXX cl-lib
> XXX cl-lib
> XXX cl-lib
> XXX async-bytecomp
> XXX cl-lib
> XXX async
> XXX bytecomp
> XXX helm-global-bindings
> XXX helm-lib
> XXX helm-easymenu
> XXX easymenu
> XXX password-store
> XXX with-editor
> XXX cl-lib
> XXX compat
> XXX server
> XXX shell
> XXX comint
> XXX ring
> XXX ansi-color
> XXX ansi-osc
> XXX regexp-opt
> XXX pcomplete
> XXX comint
> XXX subr-x
> XXX subr-x
> XXX macroexp
> XXX auth-source-pass
> XXX auth-source-pass
> XXX thingatpt
> XXX seq
> XXX modus-themes
> XXX modus-themes
>

Thanks Björn that's helpful, could we try with the following instead?

modified   src/lread.c
@@ -1402,6 +1402,7 @@ DEFUN ("load", Fload, Sload, 1, 5, 0,
   int version;
 
   CHECK_STRING (file);
+  printf ("YYY %s\n", SSDATA (file));
 
   /* If file name is magic, call the handler.  */
   handler = Ffind_file_name_handler (file, Qload);




>> 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
>
>
> Is the it normal that gdb tell me:
> warning: Corrupted shared library list: 0x1701f5b0 != 0x19cf8b60
>
> When running Emacs in GDB?
> I have the same error with my last known good version.

I think so, I've seen this in the past and never bothered too much (but
I'm not a gdb guru so I can't give you a good explanation).

Thanks

  Andrea





  parent reply	other threads:[~2024-02-28 19:34 UTC|newest]

Thread overview: 57+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2024-02-27 16:58 bug#69431: 30.0.50; Strange fontificaion behavior OGAWA Hirofumi
2024-02-27 17:29 ` Eli Zaretskii
2024-02-27 17:58   ` Ihor Radchenko
2024-02-27 18:49     ` Eli Zaretskii
2024-02-27 19:20       ` OGAWA Hirofumi
2024-02-27 19:26       ` Ihor Radchenko
2024-02-27 19:33         ` Eli Zaretskii
2024-02-27 20:11           ` Andrea Corallo
2024-02-27 20:23             ` OGAWA Hirofumi
2024-02-27 20:24             ` Ihor Radchenko
2024-02-27 20:27             ` Ihor Radchenko
2024-02-27 21:48               ` Andrea Corallo
2024-02-28 12:00                 ` Ihor Radchenko
     [not found]           ` <87v869h86b.fsf@>
2024-02-28 13:53             ` Andrea Corallo
2024-02-28 16:57               ` Björn Bidar via Bug reports for GNU Emacs, the Swiss army knife of text editors
     [not found]               ` <87zfvkfrw0.fsf@>
2024-02-28 18:44                 ` Björn Bidar via Bug reports for GNU Emacs, the Swiss army knife of text editors
2024-02-28 19:34                 ` Andrea Corallo [this message]
2024-02-28 21:41                   ` Björn Bidar via Bug reports for GNU Emacs, the Swiss army knife of text editors
     [not found]                   ` <87jzmofes3.fsf@>
2024-02-29 22:16                     ` Andrea Corallo
2024-03-01  1:13                       ` Björn Bidar via Bug reports for GNU Emacs, the Swiss army knife of text editors
2024-03-01  1:18                       ` Björn Bidar via Bug reports for GNU Emacs, the Swiss army knife of text editors
2024-03-03 16:20               ` Björn Bidar via Bug reports for GNU Emacs, the Swiss army knife of text editors
     [not found]               ` <87bk7vgucb.fsf@>
2024-03-03 17:01                 ` Andrea Corallo
2024-03-06 16:38         ` Andrea Corallo
2024-03-07 11:59           ` OGAWA Hirofumi
2024-03-07 14:49             ` Andrea Corallo
2024-03-07 22:33               ` Andrea Corallo
2024-03-21  8:32                 ` Eli Zaretskii
2024-03-23 19:29                   ` Björn Bidar via Bug reports for GNU Emacs, the Swiss army knife of text editors
     [not found]                   ` <87frwgeohj.fsf@>
2024-03-23 20:34                     ` Björn Bidar via Bug reports for GNU Emacs, the Swiss army knife of text editors
2024-03-23 20:34                     ` Björn Bidar via Bug reports for GNU Emacs, the Swiss army knife of text editors
2024-03-24  9:12                   ` Andrea Corallo
2024-03-24  9:28                     ` Eli Zaretskii
2024-03-26 21:37                     ` Stefan Monnier via Bug reports for GNU Emacs, the Swiss army knife of text editors
2024-03-27  8:31                       ` Andrea Corallo
2024-03-27 14:27                         ` Stefan Monnier via Bug reports for GNU Emacs, the Swiss army knife of text editors
2024-03-31 19:49                           ` Andrea Corallo
2024-03-31 20:40                             ` Andrea Corallo
2024-04-01 10:59                               ` Ihor Radchenko
2024-04-01 12:33                               ` Björn Bidar via Bug reports for GNU Emacs, the Swiss army knife of text editors
2024-04-06 17:01                               ` Andrea Corallo
2024-04-06 18:38                                 ` Ihor Radchenko
2024-04-07  7:47                                   ` Andrea Corallo
     [not found]                                     ` <87plv1v3za.fsf@>
2024-04-07 11:46                                       ` Eli Zaretskii
2024-04-07 12:01                                         ` Björn Bidar via Bug reports for GNU Emacs, the Swiss army knife of text editors
     [not found]                                         ` <875xwtidpn.fsf@>
2024-04-07 12:48                                           ` Eli Zaretskii
     [not found]                                             ` <871q7hi5f9.fsf@>
2024-04-07 15:50                                               ` Eli Zaretskii
2024-04-07 18:02                                                 ` Björn Bidar via Bug reports for GNU Emacs, the Swiss army knife of text editors
     [not found]                                                 ` <87v84tgifz.fsf@>
2024-04-07 18:35                                                   ` Eli Zaretskii
2024-04-07 19:09                                                     ` Björn Bidar via Bug reports for GNU Emacs, the Swiss army knife of text editors
2024-04-08  7:15                                                   ` Andrea Corallo
2024-04-08 11:40                                                     ` Eli Zaretskii
2024-04-07 12:29                                       ` Andrea Corallo
2024-04-07 15:29                                     ` Stefan Monnier via Bug reports for GNU Emacs, the Swiss army knife of text editors
2024-04-08  7:00                                       ` Andrea Corallo
2024-04-08 12:49                                         ` Stefan Monnier via Bug reports for GNU Emacs, the Swiss army knife of text editors
2024-03-07 14:31           ` Ihor Radchenko

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=yp1bk805qog.fsf@fencepost.gnu.org \
    --to=acorallo@gnu.org \
    --cc=69431@debbugs.gnu.org \
    --cc=bjorn.bidar@thaodan.de \
    --cc=eliz@gnu.org \
    --cc=hirofumi@mail.parknet.co.jp \
    --cc=yantar92@posteo.net \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
Code repositories for project(s) associated with this external index

	https://git.savannah.gnu.org/cgit/emacs.git
	https://git.savannah.gnu.org/cgit/emacs/org-mode.git

This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.