GNU bug report logs - #79023
30.1.90; Suspicion of memory leak on internal_redisplay (MacOS)

Previous Next

Package: emacs;

Reported by: Przemysław Alexander Kamiński <przemyslaw <at> kaminski.se>

Date: Tue, 15 Jul 2025 07:14:01 UTC

Severity: normal

Found in version 30.1.90

Full log


View this message in rfc822 format

From: Przemysław Alexander Kamiński
 <alexander <at> kaminski.se>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: rudolf <at> adamkovic.org, 79023 <at> debbugs.gnu.org
Subject: bug#79023: 30.1.90; Suspicion of memory leak on internal_redisplay (MacOS)
Date: Mon, 11 Aug 2025 17:15:22 +0200
On Mon, Aug 11, 2025 at 16:36:27 (+0300), Eli Zaretskii wrote:

> This is supposed to cons a list (a Lisp_Object) of relevant fonts,
> which is then reclaimed by GC after face_for_char returns (because
> there are no references to it).  Is that not what happens on macOS?

No, and I think it was designed like that but a bug creeped in.

Function macfont_create_family_with_symbol (macfont.m) uses
symbol-to-font cache, but it seems that cache is set only when pat_desc exists.
Not sure why it's like that, but if that's not on purpose it would
explain why reporting was inconsistent.

I'm not seeing these allocations anymore at all. I started also changing 
ns_can_use_native_image_api function (as it resulted in huge amount of
small allocs). With those two changes I've seen merely 2MiB allocation after my
eshell colorful "fd" listing test - and it seems a legit one (some hook fired).

I need to clean up the code and split patches in smaller ones, hope to
do have that soon.

Best,
Przemysław Alexander Kamiński




This bug report was last modified 1 day ago.

Previous Next


GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.