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

From: martin rudalics <[email-masked]>
Date: Wed, 26 Mar 2025 09:54:50 +0100

>> 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