bug#56462: 29.0.50; [PATCH] Memory leak in ns_draw_relief

bug#56462: 29.0.50; [PATCH] Memory leak in ns_draw_relief

[Daniel Martín via Bug reports for GNU Emacs, the Swiss army knife of text editors]

[-- Attachment #1: Type: text/plain, Size: 710 bytes --]


I ran the Leaks tool with Emacs 29, and I've found a memory leak in the
NS version of Emacs.

Since commit c7b48b61d08f0b6a08584080badc60fe62ba1db1, in function
ns_draw_relief, static local variables baseCol and lightCol are assigned
to nil separately to their declaration.  That has the subtle consequence
that the further down calls to [baseCol release] and [lightCol release]
become a no-op, so each time ns_draw_relief is called it leaks some
instances of NSColor.

The fix is to revert to the previous way those static variables were
declared.

I've attached a patch with the correction.  With this fix, the leaks
tool doesn't report the NSColor leaks anymore when I play around with
Emacs 29.

Thanks.


[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #2: 0001-Fix-memory-leak-in-ns_draw_relief.patch --]
[-- Type: text/x-patch, Size: 1251 bytes --]

From acebb668e310da526f262f6a47090eddbb9c76a6 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Daniel=20Mart=C3=ADn?= <mardani29@yahoo.es>
Date: Sat, 9 Jul 2022 15:54:07 +0200
Subject: [PATCH] Fix memory leak in ns_draw_relief

* src/nsterm.m (ns_draw_relief): Assigning the static local variables
baseCol and lightCol to nil leaks memory as of the second time
ns_draw_relief is called, because the calls to [baseCol release] and
[lightCol release] further down the function become a no-op.

This bug was introduced in c7b48b61d08f0b6a08584080badc60fe62ba1db1.
---
 src/nsterm.m | 4 +---
 1 file changed, 1 insertion(+), 3 deletions(-)

diff --git a/src/nsterm.m b/src/nsterm.m
index 7f232e7292..dc55edf0eb 100644
--- a/src/nsterm.m
+++ b/src/nsterm.m
@@ -3486,13 +3486,11 @@ larger if there are taller display elements (e.g., characters
     of some sides not being drawn, and because the rect will be filled.
    -------------------------------------------------------------------------- */
 {
-  static NSColor *baseCol, *lightCol, *darkCol;
+  static NSColor *baseCol = nil, *lightCol = nil, *darkCol = nil;
   NSColor *newBaseCol;
   NSRect inner;
   NSBezierPath *p;
 
-  baseCol = nil;
-  lightCol = nil;
   newBaseCol = nil;
   p = nil;
 
-- 
2.34.1

bug#56462: 29.0.50; [PATCH] Memory leak in ns_draw_relief

[Po Lu via Bug reports for GNU Emacs, the Swiss army knife of text editors]

Daniel Martín <mardani29@yahoo.es> writes:

> I ran the Leaks tool with Emacs 29, and I've found a memory leak in the
> NS version of Emacs.
>
> Since commit c7b48b61d08f0b6a08584080badc60fe62ba1db1, in function
> ns_draw_relief, static local variables baseCol and lightCol are assigned
> to nil separately to their declaration.  That has the subtle consequence
> that the further down calls to [baseCol release] and [lightCol release]
> become a no-op, so each time ns_draw_relief is called it leaks some
> instances of NSColor.
>
> The fix is to revert to the previous way those static variables were
> declared.
>
> I've attached a patch with the correction.  With this fix, the leaks
> tool doesn't report the NSColor leaks anymore when I play around with
> Emacs 29.

Thanks.  But I think the use of static variables there is rather ugly,
and it would be much nicer if we replicated the `x_setup_relief_color'
logic there.

Do you want to work on that, or should I?

bug#56462: 29.0.50; [PATCH] Memory leak in ns_draw_relief

[Daniel Martín via Bug reports for GNU Emacs, the Swiss army knife of text editors]

Po Lu <luangruo@yahoo.com> writes:

> Daniel Martín <mardani29@yahoo.es> writes:
>
>> I ran the Leaks tool with Emacs 29, and I've found a memory leak in the
>> NS version of Emacs.
>>
>> Since commit c7b48b61d08f0b6a08584080badc60fe62ba1db1, in function
>> ns_draw_relief, static local variables baseCol and lightCol are assigned
>> to nil separately to their declaration.  That has the subtle consequence
>> that the further down calls to [baseCol release] and [lightCol release]
>> become a no-op, so each time ns_draw_relief is called it leaks some
>> instances of NSColor.
>>
>> The fix is to revert to the previous way those static variables were
>> declared.
>>
>> I've attached a patch with the correction.  With this fix, the leaks
>> tool doesn't report the NSColor leaks anymore when I play around with
>> Emacs 29.
>
> Thanks.  But I think the use of static variables there is rather ugly,
> and it would be much nicer if we replicated the `x_setup_relief_color'
> logic there.
>
> Do you want to work on that, or should I?

Thanks, I can give it a try.

bug#56462: 29.0.50; [PATCH] Memory leak in ns_draw_relief

[Daniel Martín via Bug reports for GNU Emacs, the Swiss army knife of text editors]

[-- Attachment #1: Type: text/plain, Size: 506 bytes --]

Daniel Martín via "Bug reports for GNU Emacs, the Swiss army knife of
text editors" <bug-gnu-emacs@gnu.org> writes:

>>
>> Thanks.  But I think the use of static variables there is rather ugly,
>> and it would be much nicer if we replicated the `x_setup_relief_color'
>> logic there.
>>
>> Do you want to work on that, or should I?
>
> Thanks, I can give it a try.

Here's a patch where the static variables are now proper fields in the
ns_output structure.  Is that what you had in mind?


[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #2: 0001-Fix-memory-leak-in-ns_draw_relief.patch --]
[-- Type: text/x-patch, Size: 4744 bytes --]

From ebcf7ca3e8a2add11050be4c1d7e991e3c0f0a6d Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Daniel=20Mart=C3=ADn?= <mardani29@yahoo.es>
Date: Sun, 10 Jul 2022 22:36:28 +0200
Subject: [PATCH] Fix memory leak in ns_draw_relief

* src/nsterm.h (struct ns_output): New fields to store the relief
colors.
* src/nsterm.m (ns_setup_relief_colors): New function to keep the
relief colors as part of the ns_output structure.
(ns_draw_relief): Remove static local variables.  Assigning them to
nil caused a memory leak of NSColor instances (bug#56462).  Call
ns_setup_relief_colors instead.
---
 src/nsterm.h |  6 +++++
 src/nsterm.m | 68 +++++++++++++++++++++++++++-------------------------
 2 files changed, 42 insertions(+), 32 deletions(-)

diff --git a/src/nsterm.h b/src/nsterm.h
index 7a097b3248..2a4c7571a3 100644
--- a/src/nsterm.h
+++ b/src/nsterm.h
@@ -927,6 +927,9 @@ #define KEY_NS_SHOW_PREFS              ((1<<28)|(0<<16)|14)
   NSColor *cursor_color;
   NSColor *foreground_color;
   NSColor *background_color;
+  NSColor *relief_background_color;
+  NSColor *light_relief_color;
+  NSColor *dark_relief_color;
   EmacsToolbar *toolbar;
 #else
   void *view;
@@ -934,6 +937,9 @@ #define KEY_NS_SHOW_PREFS              ((1<<28)|(0<<16)|14)
   void *cursor_color;
   void *foreground_color;
   void *background_color;
+  void *relief_background_color;
+  void *light_relief_color;
+  void *dark_relief_color;
   void *toolbar;
 #endif
 
diff --git a/src/nsterm.m b/src/nsterm.m
index 7f232e7292..8e0c4b84f0 100644
--- a/src/nsterm.m
+++ b/src/nsterm.m
@@ -3475,6 +3475,35 @@ larger if there are taller display elements (e.g., characters
     }
 }
 
+/* Set up colors for the relief lines around glyph string S.  */
+
+static void
+ns_setup_relief_colors (struct glyph_string *s)
+{
+  struct ns_output *di = FRAME_OUTPUT_DATA (s->f);
+  NSColor *color;
+
+  if (s->face->use_box_color_for_shadows_p)
+    color = [NSColor colorWithUnsignedLong: s->face->box_color];
+  else
+    color = [NSColor colorWithUnsignedLong: s->face->background];
+
+  if (s->hl == DRAW_CURSOR)
+    color = FRAME_CURSOR_COLOR (s->f);
+
+  if (color == nil)
+    color = [NSColor grayColor];
+
+  if (color != di->relief_background_color)
+    {
+      [di->relief_background_color release];
+      di->relief_background_color = [color retain];
+      [di->light_relief_color release];
+      di->light_relief_color = [[color highlightWithLevel: 0.4] retain];
+      [di->dark_relief_color release];
+      di->dark_relief_color = [[color shadowWithLevel: 0.4] retain];
+    }
+}
 
 static void
 ns_draw_relief (NSRect outer, int hthickness, int vthickness, char raised_p,
@@ -3486,40 +3515,13 @@ larger if there are taller display elements (e.g., characters
     of some sides not being drawn, and because the rect will be filled.
    -------------------------------------------------------------------------- */
 {
-  static NSColor *baseCol, *lightCol, *darkCol;
-  NSColor *newBaseCol;
   NSRect inner;
-  NSBezierPath *p;
-
-  baseCol = nil;
-  lightCol = nil;
-  newBaseCol = nil;
-  p = nil;
+  NSBezierPath *p = nil;
 
   NSTRACE ("ns_draw_relief");
 
   /* set up colors */
-
-  if (s->face->use_box_color_for_shadows_p)
-    newBaseCol = [NSColor colorWithUnsignedLong: s->face->box_color];
-  else
-    newBaseCol = [NSColor colorWithUnsignedLong: s->face->background];
-
-  if (s->hl == DRAW_CURSOR)
-    newBaseCol = FRAME_CURSOR_COLOR (s->f);
-
-  if (newBaseCol == nil)
-    newBaseCol = [NSColor grayColor];
-
-  if (newBaseCol != baseCol)  /* TODO: better check */
-    {
-      [baseCol release];
-      baseCol = [newBaseCol retain];
-      [lightCol release];
-      lightCol = [[baseCol highlightWithLevel: 0.4] retain];
-      [darkCol release];
-      darkCol = [[baseCol shadowWithLevel: 0.4] retain];
-    }
+  ns_setup_relief_colors (s);
 
   /* Calculate the inner rectangle.  */
   inner = outer;
@@ -3542,7 +3544,9 @@ larger if there are taller display elements (e.g., characters
   if (bottom_p)
     inner.size.height -= hthickness;
 
-  [(raised_p ? lightCol : darkCol) set];
+  struct ns_output *di = FRAME_OUTPUT_DATA (s->f);
+
+  [(raised_p ? di->light_relief_color : di->dark_relief_color) set];
 
   if (top_p || left_p)
     {
@@ -3564,7 +3568,7 @@ larger if there are taller display elements (e.g., characters
       [p fill];
     }
 
-  [(raised_p ? darkCol : lightCol) set];
+  [(raised_p ? di->dark_relief_color : di->light_relief_color) set];
 
   if (bottom_p || right_p)
     {
@@ -3626,7 +3630,7 @@ larger if there are taller display elements (e.g., characters
 				   NSMaxY (outer) - 0.5)];
     }
 
-  [darkCol set];
+  [di->dark_relief_color set];
   [p stroke];
 
   if (vthickness > 1 && hthickness > 1)
-- 
2.34.1

bug#56462: 29.0.50; [PATCH] Memory leak in ns_draw_relief

[Po Lu via Bug reports for GNU Emacs, the Swiss army knife of text editors]

Daniel Martín <mardani29@yahoo.es> writes:

> Daniel Martín via "Bug reports for GNU Emacs, the Swiss army knife of
> text editors" <bug-gnu-emacs@gnu.org> writes:
>
>>>
>>> Thanks.  But I think the use of static variables there is rather ugly,
>>> and it would be much nicer if we replicated the `x_setup_relief_color'
>>> logic there.
>>>
>>> Do you want to work on that, or should I?
>>
>> Thanks, I can give it a try.
>
> Here's a patch where the static variables are now proper fields in the
> ns_output structure.  Is that what you had in mind?

Yes, this would be great.  Thanks.

Alan might have some comments; if he doesn't, I'll install this now.

bug#56462: 29.0.50; [PATCH] Memory leak in ns_draw_relief

[Alan Third]

On Mon, Jul 11, 2022 at 09:50:11AM +0800, Po Lu via Bug reports for GNU Emacs, the Swiss army knife of text editors wrote:
> Daniel Martín <mardani29@yahoo.es> writes:
> 
> > Daniel Martín via "Bug reports for GNU Emacs, the Swiss army knife of
> > text editors" <bug-gnu-emacs@gnu.org> writes:
> >
> >>>
> >>> Thanks.  But I think the use of static variables there is rather ugly,
> >>> and it would be much nicer if we replicated the `x_setup_relief_color'
> >>> logic there.
> >>>
> >>> Do you want to work on that, or should I?
> >>
> >> Thanks, I can give it a try.
> >
> > Here's a patch where the static variables are now proper fields in the
> > ns_output structure.  Is that what you had in mind?
> 
> Yes, this would be great.  Thanks.
> 
> Alan might have some comments; if he doesn't, I'll install this now.

No, looks fine to me.
-- 
Alan Third

bug#56462: 29.0.50; [PATCH] Memory leak in ns_draw_relief

[Po Lu via Bug reports for GNU Emacs, the Swiss army knife of text editors]

Daniel Martín <mardani29@yahoo.es> writes:

> Daniel Martín via "Bug reports for GNU Emacs, the Swiss army knife of
> text editors" <bug-gnu-emacs@gnu.org> writes:
>
>>>
>>> Thanks.  But I think the use of static variables there is rather ugly,
>>> and it would be much nicer if we replicated the `x_setup_relief_color'
>>> logic there.
>>>
>>> Do you want to work on that, or should I?
>>
>> Thanks, I can give it a try.
>
> Here's a patch where the static variables are now proper fields in the
> ns_output structure.  Is that what you had in mind?

Now installed, so I'm closing this bug.

bug#56462: 29.0.50; [PATCH] Memory leak in ns_draw_relief

[Lars Ingebrigtsen]

Po Lu <luangruo@yahoo.com> writes:

> Now installed, so I'm closing this bug.

The bug report was still open, so I'm closing it now.