GNU bug report logs -
#77240
30.1; Native-comp causing large memory leak
Previous Next
To reply to this bug, email your comments to 77240 AT debbugs.gnu.org.
Toggle the display of automated, internal messages from the tracker.
Report forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#77240; Package
emacs.
(Mon, 24 Mar 2025 16:46:02 GMT)
Full text and
rfc822 format available.
Acknowledgement sent
to
N Winkel <nw1905 <at> outlook.com>:
New bug report received and forwarded. Copy sent to
bug-gnu-emacs <at> gnu.org.
(Mon, 24 Mar 2025 16:46:02 GMT)
Full text and
rfc822 format available.
Message #5 received at submit <at> debbugs.gnu.org (full text, mbox):
Evaluating the following snippet in 'emacs -Q' after removing any
relevant eln-cache gives me memory leaks that don't seem to have
an upper limit (largest I've had before killing was 10G):
(require 'package)
(add-to-list 'package-archives '("melpa" .
"https://melpa.org/packages/") t)
(package-initialize)
(use-package smartparens
:config (require 'smartparens-config))
(defun +select-buffer-in-side-window (buffer alist)
"Display BUFFER in a side window and select it, ALIST controls where it
opens."
(let ((window (display-buffer-in-side-window buffer alist)))
(select-window window)))
(add-to-list 'display-buffer-alist
'("\\*\\(?:Warnings\\|Compile-Log\\|Messages\\)\\*"
(+select-buffer-in-side-window)))
This opens a Warnings popup buffer that displays "🚫 Warning
(native-compiler): "
many times over with a single bit of information that is only sometimes
visible:
"smartparens-config.el:96:24: Warning the function
'org-element-property' is not
known to be defined." which doesn't seem relevant. Here's a link to a
screenshot
after evaluation: https://winkel.wolkesicher.de/index.php/s/HNTcdQMLCWNJ7Zq
Any interaction with the window after evaluating the snippet freezes the
window, but cpu (100% on a single core) and memory usage continue, with
memory rising at what appears to be a steady rate. The first couple
seconds have separate processes that have high memory usage, but after
that it all goes to the main 'emacs -Q' process.
On my system it reaches over 2G within 3min.
Adding (run-with-timer 0 10 'malloc-trim) does not seem to help, nor
does adding (malloc-trim) between statements.
In GNU Emacs 30.1 (build 1, x86_64-pc-linux-gnu, GTK+ Version 3.24.49,
cairo version 1.18.4)
System Description: Arch Linux
Configured using:
'configure --with-pgtk --sysconfdir=/etc --prefix=/usr
--libexecdir=/usr/lib --localstatedir=/var --disable-build-details
--with-cairo --with-harfbuzz --with-libsystemd --with-modules
--with-native-compilation=aot --with-tree-sitter 'CFLAGS=-march=x86-64
-mtune=generic -O2 -pipe -fno-plt -fexceptions -Wp,-D_FORTIFY_SOURCE=3
-Wformat -Werror=format-security -fstack-clash-protection
-fcf-protection -fno-omit-frame-pointer -mno-omit-leaf-frame-pointer -g
-ffile-prefix-map=/build/emacs/src=/usr/src/debug/emacs -flto=auto'
'LDFLAGS=-Wl,-O1 -Wl,--sort-common -Wl,--as-needed -Wl,-z,relro
-Wl,-z,now -Wl,-z,pack-relative-relocs -flto=auto'
'CXXFLAGS=-march=x86-64 -mtune=generic -O2 -pipe -fno-plt -fexceptions
-Wp,-D_FORTIFY_SOURCE=3 -Wformat -Werror=format-security
-fstack-clash-protection -fcf-protection -fno-omit-frame-pointer
-mno-omit-leaf-frame-pointer -Wp,-D_GLIBCXX_ASSERTIONS -g
-ffile-prefix-map=/build/emacs/src=/usr/src/debug/emacs -flto=auto''
Configured features:
ACL CAIRO DBUS FREETYPE GIF GLIB GMP GNUTLS GPM GSETTINGS HARFBUZZ JPEG
LCMS2 LIBOTF LIBSYSTEMD LIBXML2 MODULES NATIVE_COMP NOTIFY INOTIFY
PDUMPER PGTK PNG RSVG SECCOMP SOUND SQLITE3 THREADS TIFF
TOOLKIT_SCROLL_BARS TREE_SITTER WEBP XIM GTK3 ZLIB
Important settings:
value of $LANG: en_GB.UTF-8
locale-coding-system: utf-8-unix
Major mode: Lisp Interaction
Minor modes in effect:
tooltip-mode: t
global-eldoc-mode: t
eldoc-mode: t
show-paren-mode: t
electric-indent-mode: t
mouse-wheel-mode: t
tool-bar-mode: t
menu-bar-mode: t
file-name-shadow-mode: t
global-font-lock-mode: t
font-lock-mode: t
blink-cursor-mode: t
minibuffer-regexp-mode: t
line-number-mode: t
indent-tabs-mode: t
transient-mark-mode: t
auto-composition-mode: t
auto-encryption-mode: t
auto-compression-mode: t
Load-path shadows:
None found.
Features:
(shadow sort mail-extr emacsbug message mailcap yank-media puny dired
dired-loaddefs rfc822 mml mml-sec password-cache epa derived epg rfc6068
epg-config gnus-util text-property-search time-date subr-x mm-decode
mm-bodies mm-encode mail-parse rfc2231 mailabbrev gmm-utils mailheader
cl-loaddefs cl-lib sendmail rfc2047 rfc2045 ietf-drums mm-util
mail-prsvr mail-utils rmc iso-transl tooltip cconv eldoc paren electric
uniquify ediff-hook vc-hooks lisp-float-type elisp-mode mwheel
term/pgtk-win pgtk-win term/common-win touch-screen pgtk-dnd tool-bar
dnd fontset image regexp-opt fringe tabulated-list replace newcomment
text-mode lisp-mode prog-mode register page tab-bar menu-bar rfn-eshadow
isearch easymenu timer select scroll-bar mouse jit-lock font-lock syntax
font-core term/tty-colors frame minibuffer nadvice seq simple cl-generic
indonesian philippine cham georgian utf-8-lang misc-lang vietnamese
tibetan thai tai-viet lao korean japanese eucjp-ms cp51932 hebrew greek
romanian slovak czech european ethiopic indian cyrillic chinese
composite emoji-zwj charscript charprop case-table epa-hook
jka-cmpr-hook help abbrev obarray oclosure cl-preloaded button loaddefs
theme-loaddefs faces cus-face macroexp files window text-properties
overlay sha1 md5 base64 format env code-pages mule custom widget keymap
hashtable-print-readable backquote threads dbusbind inotify
dynamic-setting system-font-setting font-render-setting cairo gtk pgtk
lcms2 multi-tty move-toolbar make-network-process native-compile emacs)
Memory information:
((conses 16 48924 9857) (symbols 48 5332 0) (strings 32 13938 1128)
(string-bytes 1 456835) (vectors 16 9042)
(vector-slots 8 126048 10856) (floats 8 22 2) (intervals 56 276 0)
(buffers 992 10))
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#77240; Package
emacs.
(Mon, 24 Mar 2025 18:32:02 GMT)
Full text and
rfc822 format available.
Message #8 received at 77240 <at> debbugs.gnu.org (full text, mbox):
> Date: Mon, 24 Mar 2025 16:23:49 +0100
> From: N Winkel <nw1905 <at> outlook.com>
>
> Evaluating the following snippet in 'emacs -Q' after removing any
> relevant eln-cache gives me memory leaks that don't seem to have
> an upper limit (largest I've had before killing was 10G):
>
> (require 'package)
> (add-to-list 'package-archives '("melpa" .
> "https://melpa.org/packages/") t)
> (package-initialize)
>
> (use-package smartparens
> :config (require 'smartparens-config))
>
> (defun +select-buffer-in-side-window (buffer alist)
> "Display BUFFER in a side window and select it, ALIST controls where it
> opens."
> (let ((window (display-buffer-in-side-window buffer alist)))
> (select-window window)))
> (add-to-list 'display-buffer-alist
> '("\\*\\(?:Warnings\\|Compile-Log\\|Messages\\)\\*"
> (+select-buffer-in-side-window)))
>
> This opens a Warnings popup buffer that displays "🚫 Warning
> (native-compiler): "
> many times over with a single bit of information that is only sometimes
> visible:
> "smartparens-config.el:96:24: Warning the function
> 'org-element-property' is not
> known to be defined." which doesn't seem relevant. Here's a link to a
> screenshot
> after evaluation: https://winkel.wolkesicher.de/index.php/s/HNTcdQMLCWNJ7Zq
>
> Any interaction with the window after evaluating the snippet freezes the
> window, but cpu (100% on a single core) and memory usage continue, with
> memory rising at what appears to be a steady rate. The first couple
> seconds have separate processes that have high memory usage, but after
> that it all goes to the main 'emacs -Q' process.
> On my system it reaches over 2G within 3min.
>
> Adding (run-with-timer 0 10 'malloc-trim) does not seem to help, nor
> does adding (malloc-trim) between statements.
Why do you say this is related to native-compiler?
Adding Andrea and Martin in the hope that they will have comments or
insights.
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#77240; Package
emacs.
(Mon, 24 Mar 2025 20:25:02 GMT)
Full text and
rfc822 format available.
Message #11 received at 77240 <at> debbugs.gnu.org (full text, mbox):
N Winkel <nw1905 <at> outlook.com> writes:
> On 24/03/2025 19:31, Eli Zaretskii wrote:
>
> Why do you say this is related to native-compiler?
>
> Sorry that is something I should have mentioned: I started getting this after upgrading to emacs 30, with it occurring
> every time an update was applied, which was frequent after the distro release of version 30. This is due to the new
> versions adding and populating a new .config/emacs/eln-cache/30.x-[commit hash]/
> Once it is generated (i.e. emacs has been opened a couple of times, waited a bit, killed manually once it used too much
> memory and reopened) the leak no longer happens. Without restarting emacs the memory continues to climb and the cpu usage
> remains even when everything has been compiled.
My impression is that you are just observing libgccjit running in
background while we are populating the eln cache. How long have you
tried waiting for the compilation to finish (and the memory to be
released) before coming to the conlusion this is a memory leak?
Thanks
Andrea
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#77240; Package
emacs.
(Tue, 25 Mar 2025 04:40:04 GMT)
Full text and
rfc822 format available.
Message #14 received at 77240 <at> debbugs.gnu.org (full text, mbox):
[Message part 1 (text/plain, inline)]
On 24/03/2025 19:31, Eli Zaretskii wrote:
> Why do you say this is related to native-compiler?
Sorry that is something I should have mentioned: I started getting this
after upgrading to emacs 30, with it occurring every time an update was
applied, which was frequent after the distro release of version 30. This
is due to the new versions adding and populating a new
.config/emacs/eln-cache/30.x-[commit hash]/
Once it is generated (i.e. emacs has been opened a couple of times,
waited a bit, killed manually once it used too much memory and reopened)
the leak no longer happens. Without restarting emacs the memory
continues to climb and the cpu usage remains even when everything has
been compiled.
The minimal instructions also only work if the eln-cache has been
cleared and needs to be regenerated. If it is run once the 5 files it
compiles are there, nothing will happen.
[Message part 2 (text/html, inline)]
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#77240; Package
emacs.
(Tue, 25 Mar 2025 04:40:05 GMT)
Full text and
rfc822 format available.
Message #17 received at 77240 <at> debbugs.gnu.org (full text, mbox):
[Message part 1 (text/plain, inline)]
On 24/03/2025 21:24, Andrea Corallo wrote:
> My impression is that you are just observing libgccjit running in
> background while we are populating the eln cache. How long have you
> tried waiting for the compilation to finish (and the memory to be
> released) before coming to the conlusion this is a memory leak?
I've waited until all the memory my system has was full, this was
emacs using over 10G of memory, with no indication of the increase
slowing, even though no further .eln files were being compiled.
Can I somehow check if libgccjit is still running?
[Message part 2 (text/html, inline)]
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#77240; Package
emacs.
(Tue, 25 Mar 2025 07:59:01 GMT)
Full text and
rfc822 format available.
Message #20 received at 77240 <at> debbugs.gnu.org (full text, mbox):
>> (add-to-list 'display-buffer-alist
>> '("\\*\\(?:Warnings\\|Compile-Log\\|Messages\\)\\*"
>> (+select-buffer-in-side-window)))
[...]
> Adding Andrea and Martin in the hope that they will have comments or
> insights.
Does the problem also happen when you do not modify
'display-buffer-alist'?
martin
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#77240; Package
emacs.
(Tue, 25 Mar 2025 08:13:01 GMT)
Full text and
rfc822 format available.
Message #23 received at 77240 <at> debbugs.gnu.org (full text, mbox):
> Does the problem also happen when you do not modify
> 'display-buffer-alist'?
It does not, it just generates the eln files and shows three errors
"â›” Warning (native-compiler): smartparens-config.el:96:24: Warning:
the function ‘org-element-property’ is not known to be defined."
just with different functions, which would imply that it's not
native-comp but the interaction between the warning buffer and what
I've added to 'display-buffer-alist'?
N
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#77240; Package
emacs.
(Tue, 25 Mar 2025 09:35:02 GMT)
Full text and
rfc822 format available.
Message #26 received at 77240 <at> debbugs.gnu.org (full text, mbox):
>> Does the problem also happen when you do not modify
>> 'display-buffer-alist'?
> It does not, it just generates the eln files and shows three errors
In the echo area?
> "â›” Warning (native-compiler): smartparens-config.el:96:24: Warning:
> the function ‘org-element-property’ is not known to be defined."
> just with different functions, which would imply that it's not
> native-comp but the interaction between the warning buffer and what
> I've added to 'display-buffer-alist'?
Maybe. What happens when you do not select the window in
(defun +select-buffer-in-side-window (buffer alist)
(let ((window (display-buffer-in-side-window buffer alist)))
(select-window window)))
here? Whatever it is, the bug seems to happen in 'display-warning' so I
added Juri to the discussion.
martin
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#77240; Package
emacs.
(Tue, 25 Mar 2025 10:58:02 GMT)
Full text and
rfc822 format available.
Message #29 received at 77240 <at> debbugs.gnu.org (full text, mbox):
On 25/03/2025 10:34, martin rudalics wrote:
> >> Does the problem also happen when you do not modify
> >> 'display-buffer-alist'?
> > It does not, it just generates the eln files and shows three errors
>
> In the echo area?
No, in the "*Warnings*" buffer, that shows in a popup (as in the screenshot
linked in my original mail).
> > "â›” Warning (native-compiler): smartparens-config.el:96:24: Warning:
> > the function ‘org-element-property’ is not known to be defined."
> > just with different functions, which would imply that it's not
> > native-comp but the interaction between the warning buffer and what
> > I've added to 'display-buffer-alist'?
>
> Maybe. What happens when you do not select the window in
>
> (defun +select-buffer-in-side-window (buffer alist)
> Â (let ((window (display-buffer-in-side-window buffer alist)))
> Â Â Â (select-window window)))
>
> here?
Running the snippet without (select-window window) also results in the
described not occurring.
N
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#77240; Package
emacs.
(Tue, 25 Mar 2025 15:11:01 GMT)
Full text and
rfc822 format available.
Message #32 received at 77240 <at> debbugs.gnu.org (full text, mbox):
>> > It does not, it just generates the eln files and shows three errors
>>
>> In the echo area?
> No, in the "*Warnings*" buffer, that shows in a popup (as in the screenshot
> linked in my original mail).
I hardly ever see that pop up here.
>> What happens when you do not select the window in
>>
>> (defun +select-buffer-in-side-window (buffer alist)
>> (let ((window (display-buffer-in-side-window buffer alist)))
>> (select-window window)))
>>
>> here?
> Running the snippet without (select-window window) also results in the
> described not occurring.
Maybe that 'select-window' call enters a fight with 'display-warning'
which tries to select that window temporarily. But I was not able to
produce anything strange with a simple loop that calls 'warn'. Let's
wait for Juri to chime in.
Thanks, martin
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#77240; Package
emacs.
(Tue, 25 Mar 2025 17:22:01 GMT)
Full text and
rfc822 format available.
Message #35 received at 77240 <at> debbugs.gnu.org (full text, mbox):
>>> > It does not, it just generates the eln files and shows three errors
>>>
>>> In the echo area?
>> No, in the "*Warnings*" buffer, that shows in a popup (as in the screenshot
>> linked in my original mail).
>
> I hardly ever see that pop up here.
>
>>> What happens when you do not select the window in
>>>
>>> (defun +select-buffer-in-side-window (buffer alist)
>>> (let ((window (display-buffer-in-side-window buffer alist)))
>>> (select-window window)))
>>>
>>> here?
>> Running the snippet without (select-window window) also results in the
>> described not occurring.
>
> Maybe that 'select-window' call enters a fight with 'display-warning'
> which tries to select that window temporarily. But I was not able to
> produce anything strange with a simple loop that calls 'warn'. Let's
> wait for Juri to chime in.
What is the minimal test case without installing packages?
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#77240; Package
emacs.
(Tue, 25 Mar 2025 23:41:02 GMT)
Full text and
rfc822 format available.
Message #38 received at 77240 <at> debbugs.gnu.org (full text, mbox):
On 25/03/2025 18:12, Juri Linkov wrote:
> What is the minimal test case without installing packages?
I have not been able to identify what in smartparens-config.el
is causing the issue, and I am not personally great with
elisp. If anything is found that might be an issue I'd be
happy to test, but I'm not currently sure how to continue
looking.
Martin Rudalics mentioned an idea in the email above, I don't
know how to try that out myself, simply running a timer that
sends a warning quite frequently with the display-buffer-alist
change, however this does not cause the issue for me.
Maybe we need to also get emacs to natively compile something
at the same time?
-N
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#77240; Package
emacs.
(Wed, 26 Mar 2025 08:56:01 GMT)
Full text and
rfc822 format available.
Message #41 received at 77240 <at> debbugs.gnu.org (full text, mbox):
>> What is the minimal test case without installing packages?
> I have not been able to identify what in smartparens-config.el
> is causing the issue, and I am not personally great with
> elisp. If anything is found that might be an issue I'd be
> happy to test, but I'm not currently sure how to continue
> looking.
The first thing we'd have to investigate is whether smartparens can (and
does) act on the *Warnings* buffer (something it shouldn't IMHO). If
IIUC it adds an overlay in the function below, something you could try
is inhibiting that as
(defun sp--pair-overlay-create (start end id)
"Create an overlay over the currently inserted pair.
This overlay is used for tracking the position of the point and
marks the active expression. START and END are the boundaries of
the overlay, ID is the id of the pair."
(unless (equal (buffer-name (current-buffer)) "*Warnings*")
(let ((overlay (make-overlay start end)))
;; set priority to 99 so that yasnippet with 100 overloads the
;; keymap #625
(overlay-put overlay 'priority 99)
(overlay-put overlay 'keymap sp-pair-overlay-keymap)
(overlay-put overlay 'pair-id id)
(overlay-put overlay 'type 'pair)
(!cons overlay sp-pair-overlay-list)
(sp--pair-overlay-fix-highlight)
(add-hook 'post-command-hook 'sp--pair-overlay-post-command-handler nil t))))
and re-run your experiments.
A second question is how 'org-element-property' is related to it and why
native compilation complains about it. I know neither smartparens, nor
org nor native compilation to answer that.
> Martin Rudalics mentioned an idea in the email above, I don't
> know how to try that out myself, simply running a timer that
> sends a warning quite frequently with the display-buffer-alist
> change, however this does not cause the issue for me.
I didn't mention that idea but I think it's a good one to simulate
asynchronous behavior so we can avoid the following
> Maybe we need to also get emacs to natively compile something
> at the same time?
which might be hard to reproduce elsewhere.
martin
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#77240; Package
emacs.
(Mon, 31 Mar 2025 13:24:04 GMT)
Full text and
rfc822 format available.
Message #44 received at 77240 <at> debbugs.gnu.org (full text, mbox):
N Winkel <nw1905 <at> outlook.com> writes:
> On 24/03/2025 21:24, Andrea Corallo wrote:
>
> My impression is that you are just observing libgccjit running in
> background while we are populating the eln cache. How long have you
> tried waiting for the compilation to finish (and the memory to be
> released) before coming to the conlusion this is a memory leak?
>
> I've waited until all the memory my system has was full, this was
> emacs using over 10G of memory, with no indication of the increase
> slowing, even though no further .eln files were being compiled.
> Can I somehow check if libgccjit is still running?
I think the expected observation would be like:
1- you have your Emacs process X running, there the mem consumption is
normal.
2- you observe a process Y (child of X) which is another Emacs, this one
is the one doing the actual compilation and is supposed to be the one
going overboard with memory allocation.
Profiling memory allocation in process Y should reveal who it's actually
allocating.
Andrea
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#77240; Package
emacs.
(Mon, 31 Mar 2025 22:26:01 GMT)
Full text and
rfc822 format available.
Message #47 received at 77240 <at> debbugs.gnu.org (full text, mbox):
[Message part 1 (text/plain, inline)]
On 31/03/2025 15:23, Andrea Corallo wrote:
> I think the expected observation would be like:
>
> 1- you have your Emacs process X running, there the mem consumption is
> normal.
>
> 2- you observe a process Y (child of X) which is another Emacs, this one
> is the one doing the actual compilation and is supposed to be the one
> going overboard with memory allocation.
I do see that, however once compilation is done that process is stopped,
releasing that memory, but the main process keeps steadily increasing its
usage (along with cpu usage remaining).
> Profiling memory allocation in process Y should reveal who it's actually
> allocating.
I wasn't sure what "profiling memory allocation" meant, so after a quick
search I found 'heaptrack', which appears to do that? I've attached the
produced file from it after causing the leak and waiting for it to reach
1G of used memory.
From what I can read from the summary, the leak comes from a "location"
it describes as "<unresolved function> in emacs-30.1", which produces
most of the memory leak which appears to be in hundreds of thousands of
allocations of 1.0K and around that.
It also shows a contribution by "libglib-2.0.so.0", which is also
hundreds of thousands of allocations, but only around 5M total, so
entirely irrelevant… There is also a leak of 75.4M from "xrealloc",
which I assume is the compilation.
Is that helpful? I could also try another utility if that'd be better.
 N
[heaptrack.emacs.93341.zst (application/zstd, attachment)]
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#77240; Package
emacs.
(Mon, 31 Mar 2025 22:49:02 GMT)
Full text and
rfc822 format available.
Message #50 received at 77240 <at> debbugs.gnu.org (full text, mbox):
On 26/03/2025 09:54, martin rudalics wrote:
> The first thing we'd have to investigate is whether smartparens can (and
> does) act on the *Warnings* buffer (something it shouldn't IMHO). If
> IIUC it adds an overlay in the function below, something you could try
> is inhibiting that as
>
> (defun sp--pair-overlay-create (start end id)
> Â "Create an overlay over the currently inserted pair.
>
> This overlay is used for tracking the position of the point and
> marks the active expression. START and END are the boundaries of
> the overlay, ID is the id of the pair."
> Â (unless (equal (buffer-name (current-buffer)) "*Warnings*")
> Â Â Â (let ((overlay (make-overlay start end)))
> Â Â Â Â Â ;; set priority to 99 so that yasnippet with 100 overloads the
> Â Â Â Â Â ;; keymap #625
> Â Â Â Â Â (overlay-put overlay 'priority 99)
> Â Â Â Â Â (overlay-put overlay 'keymap sp-pair-overlay-keymap)
> Â Â Â Â Â (overlay-put overlay 'pair-id id)
> Â Â Â Â Â (overlay-put overlay 'type 'pair)
> Â Â Â Â Â (!cons overlay sp-pair-overlay-list)
> Â Â Â Â Â (sp--pair-overlay-fix-highlight)
> Â Â Â Â Â (add-hook 'post-command-hook
> 'sp--pair-overlay-post-command-handler nil t))))
>
> and re-run your experiments.
Adding this to my smartparens.el had no effect, the leak still happened
as if nothing had changed.
> A second question is how 'org-element-property' is related to it and why
> native compilation complains about it. I know neither smartparens, nor
> org nor native compilation to answer that.
From what I can tell, that might just be an error message that
smartparens throws when being loaded, I'm not sure it has any bearing on
the leak, as I also get that message (as well as for
'org-element-at-point' and 'org-in-src-block-p') when I don't
(select-window window)
> > Martin Rudalics mentioned an idea in the email above, I don't
> > know how to try that out myself, simply running a timer that
> > sends a warning quite frequently with the display-buffer-alist
> > change, however this does not cause the issue for me.
>
> I didn't mention that idea but I think it's a good one to simulate
> asynchronous behavior
Sorry I formulated that unclearly, what I was referring to was this:
> Maybe that 'select-window' call enters a fight with 'display-warning'
> which tries to select that window temporarily. But I was not able to
> produce anything strange with a simple loop that calls 'warn'.
 N
P.S. I was certain I had sent an email to this effect a couple days
ago, but it is neither in my sent folder nor on the archive, so I
very much apologise for the delay, it was not intentional
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#77240; Package
emacs.
(Tue, 01 Apr 2025 08:35:01 GMT)
Full text and
rfc822 format available.
Message #53 received at 77240 <at> debbugs.gnu.org (full text, mbox):
> P.S. I was certain I had sent an email to this effect a couple days
> ago, but it is neither in my sent folder nor on the archive, so I
> very much apologise for the delay, it was not intentional
Don't worry. I suspect that the behavior you see is caused by an
asynchronous process (like native compilation) that triggers
'display-warning' and that function recursively triggers a warning
itself. But I'm still groping in the dark for a way to debug such
behavior. Maybe we can eliminate some suspects as follows: Do
(setopt warning-display-at-bottom nil)
and conduct your experiment again.
martin
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#77240; Package
emacs.
(Tue, 01 Apr 2025 10:04:01 GMT)
Full text and
rfc822 format available.
Message #56 received at 77240 <at> debbugs.gnu.org (full text, mbox):
On 01/04/2025 10:33, martin rudalics wrote:
> I suspect that the behavior you see is caused by an
> asynchronous process (like native compilation) that triggers
> 'display-warning' and that function recursively triggers a warning
> itself. But I'm still groping in the dark for a way to debug such
> behavior. Maybe we can eliminate some suspects as follows: Do
>
> (setopt warning-display-at-bottom nil)
>
> and conduct your experiment again.
That appears to resolve it, while still showing the warning buffer
at the bottom of the window, which is slightly confusing.
N
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#77240; Package
emacs.
(Tue, 01 Apr 2025 12:11:03 GMT)
Full text and
rfc822 format available.
Message #59 received at 77240 <at> debbugs.gnu.org (full text, mbox):
> Date: Tue, 1 Apr 2025 10:33:41 +0200
> Cc: Eli Zaretskii <eliz <at> gnu.org>, Andrea Corallo <acorallo <at> gnu.org>,
> 77240 <at> debbugs.gnu.org
> From: martin rudalics <rudalics <at> gmx.at>
>
> Don't worry. I suspect that the behavior you see is caused by an
> asynchronous process (like native compilation) that triggers
> 'display-warning' and that function recursively triggers a warning
> itself.
Doesn't display-warning protect itself against such recursion?
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#77240; Package
emacs.
(Tue, 01 Apr 2025 14:44:03 GMT)
Full text and
rfc822 format available.
Message #62 received at 77240 <at> debbugs.gnu.org (full text, mbox):
> That appears to resolve it, while still showing the warning buffer
> at the bottom of the window, which is slightly confusing.
It at least seems narrows down the list of potential culprits. What
precisely is confusing about the buffer? That it appears at the bottom
of the frame?
Anyway. Please, apply the following diff
diff --git a/lisp/emacs-lisp/warnings.el b/lisp/emacs-lisp/warnings.el
index 8a5c73ebd3a..d773fb46aec 100644
--- a/lisp/emacs-lisp/warnings.el
+++ b/lisp/emacs-lisp/warnings.el
@@ -291,6 +291,7 @@ display-warning
(or (< (warning-numeric-level level)
(warning-numeric-level warning-minimum-log-level))
(warning-suppress-p type warning-suppress-log-types)
+ (> (buffer-size) 10000)
(let* ((typename (if (consp type) (car type) type))
(old (get-buffer buffer-name))
(buffer (or old (get-buffer-create buffer-name)))
which should simply stop warning when the buffer has become too large.
Then post the contents of the *Warnings* buffer here.
martin
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#77240; Package
emacs.
(Tue, 01 Apr 2025 14:47:16 GMT)
Full text and
rfc822 format available.
Message #65 received at 77240 <at> debbugs.gnu.org (full text, mbox):
> Doesn't display-warning protect itself against such recursion?
It should IMHO but I do not see where. 'with-suppressed-warnings' is
about byte-compiler errors; the one at work here might be something
different, maybe caused by the package mechanism or by not disabling
'undo' orderly.
martin
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#77240; Package
emacs.
(Tue, 01 Apr 2025 20:30:02 GMT)
Full text and
rfc822 format available.
Message #68 received at 77240 <at> debbugs.gnu.org (full text, mbox):
On 01/04/2025 16:42, martin rudalics wrote:
> Anyway. Please, apply the following diff
>
> diff --git a/lisp/emacs-lisp/warnings.el b/lisp/emacs-lisp/warnings.el
> index 8a5c73ebd3a..d773fb46aec 100644
> --- a/lisp/emacs-lisp/warnings.el
> +++ b/lisp/emacs-lisp/warnings.el
> @@ -291,6 +291,7 @@ display-warning
> Â Â Â Â (or (< (warning-numeric-level level)
> Â Â Â Â Â Â Â (warning-numeric-level warning-minimum-log-level))
> Â Â Â Â (warning-suppress-p type warning-suppress-log-types)
> +Â Â Â (> (buffer-size) 10000)
> Â Â Â Â (let* ((typename (if (consp type) (car type) type))
> Â Â Â Â Â Â Â Â Â Â Â (old (get-buffer buffer-name))
> Â Â Â Â Â Â Â Â Â Â Â (buffer (or old (get-buffer-create buffer-name)))
>
> which should simply stop warning when the buffer has become too large.
> Then post the contents of the *Warnings* buffer here.
That seems to fix it, the warnings thrown only look erratic while
compilation is happening, after which it settles and only shows
three of the 'org-element-property' warnings. Looking at the
whole buffer afterwards shows that it generated 70 lines of this
warning with the first 20-odd lines containing multiple warnings
each, apparently each missing the line break.
These 20-odd lines are roughly how the buffer would look when
frozen when the issue was occurring.
Now, all of the leaking seems to happen in the subprocesses,
which then end, releasing the memory again, as intended.
Even loading with my whole init it compiles for about 1m40, but
emacs doesn't freeze at all, just near 100% cpu usage and a lot
of subprocesses using substantial (but still <700M) amounts of
memory.
 Neri
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#77240; Package
emacs.
(Wed, 02 Apr 2025 07:01:03 GMT)
Full text and
rfc822 format available.
Message #71 received at 77240 <at> debbugs.gnu.org (full text, mbox):
>> Doesn't display-warning protect itself against such recursion?
>
> It should IMHO but I do not see where. 'with-suppressed-warnings' is
> about byte-compiler errors; the one at work here might be something
> different, maybe caused by the package mechanism or by not disabling
> 'undo' orderly.
Trying
(progn
(setq display-buffer-alist
'(((category . warning)
((lambda (&rest _) (warn "Compilation error"))))))
(warn "Compilation error"))
soon stops with
"Lisp nesting exceeds ‘max-lisp-eval-depth’: 1622"
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#77240; Package
emacs.
(Wed, 02 Apr 2025 08:16:02 GMT)
Full text and
rfc822 format available.
Message #74 received at 77240 <at> debbugs.gnu.org (full text, mbox):
> That seems to fix it, the warnings thrown only look erratic while
> compilation is happening, after which it settles and only shows
> three of the 'org-element-property' warnings. Looking at the
> whole buffer afterwards shows that it generated 70 lines of this
> warning with the first 20-odd lines containing multiple warnings
> each, apparently each missing the line break.
>
> These 20-odd lines are roughly how the buffer would look when
> frozen when the issue was occurring.
Thanks, but you forgot to attach the contents of the *Warnings* buffer
or whatever it is called. We need to understand how text gets put into
it and why it gets so large. So please post them here.
> Even loading with my whole init it compiles for about 1m40, but
> emacs doesn't freeze at all, just near 100% cpu usage and a lot
> of subprocesses using substantial (but still <700M) amounts of
> memory.
Putting text into the buffer causes 'display-warning' and/or
'display-buffer' do something very, very strange and we have to
understand what it is. Compilation per se is not the culprit IMO.
martin
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#77240; Package
emacs.
(Wed, 02 Apr 2025 08:16:03 GMT)
Full text and
rfc822 format available.
Message #77 received at 77240 <at> debbugs.gnu.org (full text, mbox):
> Trying
>
> (progn
> (setq display-buffer-alist
> '(((category . warning)
> ((lambda (&rest _) (warn "Compilation error"))))))
> (warn "Compilation error"))
>
> soon stops with
>
> "Lisp nesting exceeds ‘max-lisp-eval-depth’: 1622"
That's the idea - each time you display the *Warnings* buffer you add a
new line to it and ask to display it again. So we have to make sure
that displaying a buffer does not do that. I'm sure you could write a
similar scenario for the *Messages* buffer too. But first we would have
to know what precisely triggers that "write again and again" for the OP.
martin
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#77240; Package
emacs.
(Wed, 02 Apr 2025 08:29:02 GMT)
Full text and
rfc822 format available.
Message #80 received at 77240 <at> debbugs.gnu.org (full text, mbox):
[Message part 1 (text/plain, inline)]
On 02/04/2025 10:15, martin rudalics wrote:
> Thanks, but you forgot to attach the contents of the *Warnings* buffer
> or whatever it is called. We need to understand how text gets put into
> it and why it gets so large. So please post them here.
Sorry, I assumed a description would suffice, I've attached a text file
with the contents of the buffer now.
Neri
[warnings.txt (text/plain, attachment)]
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#77240; Package
emacs.
(Wed, 02 Apr 2025 08:59:01 GMT)
Full text and
rfc822 format available.
Message #83 received at 77240 <at> debbugs.gnu.org (full text, mbox):
> Sorry, I assumed a description would suffice, I've attached a text file
> with the contents of the buffer now.
Thanks, this should suffice for a while. Anyone who looks into this:
The order of the text as it appears in this file is _not_ necessarily
the order in which it was written. This is a separate issue we might
have to fix.
But these repetitions
â›” Warning (native-compiler): â›” Warning (native-compiler):
can be explained iff the "(if " in the middle here
(unless (or noninteractive (eq type 'bytecomp))
(insert (buttonize (icon-string 'warnings-suppress)
#'warnings-suppress type)
" "))
(if warning-prefix-function
(setq level-info (funcall warning-prefix-function
level level-info)))
(insert (format (nth 1 level-info)
(format warning-type-format typename))
message)
causes them. So 'byte-compile-warning-prefix' seems to mess things up
here. How? And who is responsible for not removing duplicate warnings
in the first place?
martin
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#77240; Package
emacs.
(Wed, 02 Apr 2025 12:21:02 GMT)
Full text and
rfc822 format available.
Message #86 received at 77240 <at> debbugs.gnu.org (full text, mbox):
> Date: Wed, 2 Apr 2025 10:58:29 +0200
> Cc: Eli Zaretskii <eliz <at> gnu.org>, Andrea Corallo <acorallo <at> gnu.org>,
> 77240 <at> debbugs.gnu.org
> From: martin rudalics <rudalics <at> gmx.at>
>
> > Sorry, I assumed a description would suffice, I've attached a text file
> > with the contents of the buffer now.
>
> Thanks, this should suffice for a while. Anyone who looks into this:
> The order of the text as it appears in this file is _not_ necessarily
> the order in which it was written. This is a separate issue we might
> have to fix.
>
> But these repetitions
>
> â›” Warning (native-compiler): â›” Warning (native-compiler):
>
> can be explained iff the "(if " in the middle here
>
> (unless (or noninteractive (eq type 'bytecomp))
> (insert (buttonize (icon-string 'warnings-suppress)
> #'warnings-suppress type)
> " "))
> (if warning-prefix-function
> (setq level-info (funcall warning-prefix-function
> level level-info)))
> (insert (format (nth 1 level-info)
> (format warning-type-format typename))
> message)
>
> causes them. So 'byte-compile-warning-prefix' seems to mess things up
> here. How? And who is responsible for not removing duplicate warnings
> in the first place?
Adding Stefan in the hope that he could help us out.
This bug report was last modified 138 days ago.
Previous Next
GNU bug tracking system
Copyright (C) 1999 Darren O. Benham,
1997,2003 nCipher Corporation Ltd,
1994-97 Ian Jackson.