GNU bug report logs -
#77240
30.1; Native-comp causing large memory leak
Previous Next
Full log
View this message in rfc822 format
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
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.