Subject: bug#77240: 30.1; Native-comp causing large memory leak

From: N Winkel <[email-masked]>
Date: Tue, 1 Apr 2025 00:48:48 +0200

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