Subject: bug#79023: 30.1.90; Suspicion of memory leak on internal_redisplay (MacOS)

From: Przemysław Alexander Kamiński<[email-masked]>
Date: Tue, 12 Aug 2025 08:04:10 +0200

On Tue, Aug 12, 2025 at 02:07:04 (+0200), Rudolf Adamkovič wrote:
> Przemysław Alexander Kamiński <[email-masked]> writes:
>> I'm attaching 6 patches (for easy review/scrutiny/integration).
>
> This is fantastic!  When I was fixing view/layer leaks, I saw lots of
> other leaks, and the word "font" certainly caught my attention. :) I
> remember thinking, "I hope we [the community] will fix all these next,
> but let me first focus on the biggest leak [on my system]".

I'll note that I found many red herrings when looking for leaks. MacOS default
instrumentation tools are not recording stacks bigger than 256.
NS version often has much bigger ones and emacs-mac relies on recursion
(instead of start/stop) so the stacks are even deeper.

Only after enabling MallockStackLogging at running the trace data is
more visible. I have a Makefile that sets Malloc logging variable like this:

malloc: export MallocStackLogging := 1
malloc: export MallocStackLoggingNoCompact := 1
malloc: export MallocScribble := 1
malloc: export MallocPreScribble := 1
malloc:
	$(EMACS_SOURCE_ROOT)/src/emacs -Q

Visibility is much higher. I'm starting to wonder if I shouldn't
write documentation about debugging techniques on MacOS, so more people
could help - I suppose that many contributors know this trick, but I
just started writing C last week ;)

> So, I am super-happy someone is doing more!  The NS port badly needs
> some serious love, or replacement.  Its pixelated tool bar icons with
> white background in dark theme, barely responsive C-g, memory leaks,
> freezes, and crashes... scream "unmaintained".  That is where we are.

Render block (i.e. no ability to start new event processing while
keyboard input or socket read is happening) should help with some of the
issues.

C-g problem bothers me the most. It should be processed ASAP. Both
render-blocking wrappers are in functions that prioritize processing
them C-g so it might be better. If not - that will be my next
"minor change". I'll start a new thread od emacs-devel about it.

I wonder if shell-running sleep could work as a reproducer? I don't have
Linux anywhere, but what's the expectation, that C-g would kill the
process ASAP?

As for crashes - understanding much more about what is happening in
Emacs I've seen one and it was unsurprising one - accepting input while
input was blocked (from mouse!). I didn't pay too much of an attention
but this most likely still can happen.

> On my machine, NS often freezes, even `emacs -Q', when closing a frame
> with the mouse, using the standard WM "red circle" button.

Experienced same. Checked this on 10h instance - no issues. I think it
is resolved by nullifying patch. IMO reusing frames instead of creating
new ones was simple expensive and nullyfing reference to the frame
delegated cleanup to much faster (and thorough) OS.

> So, thank you for improving the NS port!

Even though I tried to quit it many times (mostly of boredom) I've been
using Emacs for ~25 years. I'm happy to be able to give something back
and make it better experience.

Sloving non-trivial issue in a decades old software with minimal
knowledge of used technology and architecture is also something that I
consider a welcome "win", and ego points can not be overlooked ;-)

Yet I'd like to thank you Rudy, as your enthusiasm helped me look into
those issues. I tend to avoid zero-feedback problems as it usually mean
an art for art's sake.

Eli, also thank your for gently steering me out of the rabbit hole. You
have great people skill.

Best,
Przemysław Alexander Kamiński
-- 

Pointers are real. They’re what the hardware understands. Somebody has
to deal with them. You can’t just place a LISP book on top of an x86
chip and hope that the hardware learns about lambda calculus by osmosis.

  -- James Mickens "The Night Watch"