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