* bug#56462: 29.0.50; [PATCH] Memory leak in ns_draw_relief
[not found] <m1fsjaz84s.fsf.ref@yahoo.es>
@ 2022-07-09 14:13 ` Daniel Martín via Bug reports for GNU Emacs, the Swiss army knife of text editors
2022-07-10 2:25 ` Po Lu via Bug reports for GNU Emacs, the Swiss army knife of text editors
0 siblings, 1 reply; 8+ messages in thread
From: Daniel Martín via Bug reports for GNU Emacs, the Swiss army knife of text editors @ 2022-07-09 14:13 UTC (permalink / raw)
To: 56462
[-- 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
^ permalink raw reply related [flat|nested] 8+ messages in thread
* bug#56462: 29.0.50; [PATCH] Memory leak in ns_draw_relief
2022-07-09 14:13 ` 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
@ 2022-07-10 2:25 ` Po Lu via Bug reports for GNU Emacs, the Swiss army knife of text editors
2022-07-10 10:37 ` Daniel Martín via Bug reports for GNU Emacs, the Swiss army knife of text editors
0 siblings, 1 reply; 8+ messages in thread
From: Po Lu via Bug reports for GNU Emacs, the Swiss army knife of text editors @ 2022-07-10 2:25 UTC (permalink / raw)
To: Daniel Martín; +Cc: 56462
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?
^ permalink raw reply [flat|nested] 8+ messages in thread
* bug#56462: 29.0.50; [PATCH] Memory leak in ns_draw_relief
2022-07-10 2:25 ` Po Lu via Bug reports for GNU Emacs, the Swiss army knife of text editors
@ 2022-07-10 10:37 ` Daniel Martín via Bug reports for GNU Emacs, the Swiss army knife of text editors
2022-07-10 20:52 ` Daniel Martín via Bug reports for GNU Emacs, the Swiss army knife of text editors
0 siblings, 1 reply; 8+ messages in thread
From: Daniel Martín via Bug reports for GNU Emacs, the Swiss army knife of text editors @ 2022-07-10 10:37 UTC (permalink / raw)
To: Po Lu; +Cc: 56462
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.
^ permalink raw reply [flat|nested] 8+ messages in thread
* bug#56462: 29.0.50; [PATCH] Memory leak in ns_draw_relief
2022-07-10 10:37 ` Daniel Martín via Bug reports for GNU Emacs, the Swiss army knife of text editors
@ 2022-07-10 20:52 ` Daniel Martín via Bug reports for GNU Emacs, the Swiss army knife of text editors
2022-07-11 1:50 ` Po Lu via Bug reports for GNU Emacs, the Swiss army knife of text editors
2022-07-11 10:25 ` Po Lu via Bug reports for GNU Emacs, the Swiss army knife of text editors
0 siblings, 2 replies; 8+ messages in thread
From: Daniel Martín via Bug reports for GNU Emacs, the Swiss army knife of text editors @ 2022-07-10 20:52 UTC (permalink / raw)
To: 56462; +Cc: luangruo
[-- 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
^ permalink raw reply related [flat|nested] 8+ messages in thread
* bug#56462: 29.0.50; [PATCH] Memory leak in ns_draw_relief
2022-07-10 20:52 ` Daniel Martín via Bug reports for GNU Emacs, the Swiss army knife of text editors
@ 2022-07-11 1:50 ` Po Lu via Bug reports for GNU Emacs, the Swiss army knife of text editors
2022-07-11 8:01 ` Alan Third
2022-07-11 10:25 ` Po Lu via Bug reports for GNU Emacs, the Swiss army knife of text editors
1 sibling, 1 reply; 8+ messages in thread
From: Po Lu via Bug reports for GNU Emacs, the Swiss army knife of text editors @ 2022-07-11 1:50 UTC (permalink / raw)
To: Daniel Martín; +Cc: Alan Third, 56462
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.
^ permalink raw reply [flat|nested] 8+ messages in thread
* bug#56462: 29.0.50; [PATCH] Memory leak in ns_draw_relief
2022-07-11 1:50 ` Po Lu via Bug reports for GNU Emacs, the Swiss army knife of text editors
@ 2022-07-11 8:01 ` Alan Third
0 siblings, 0 replies; 8+ messages in thread
From: Alan Third @ 2022-07-11 8:01 UTC (permalink / raw)
To: Po Lu; +Cc: 56462, Daniel Martín
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
^ permalink raw reply [flat|nested] 8+ messages in thread
* bug#56462: 29.0.50; [PATCH] Memory leak in ns_draw_relief
2022-07-10 20:52 ` Daniel Martín via Bug reports for GNU Emacs, the Swiss army knife of text editors
2022-07-11 1:50 ` Po Lu via Bug reports for GNU Emacs, the Swiss army knife of text editors
@ 2022-07-11 10:25 ` Po Lu via Bug reports for GNU Emacs, the Swiss army knife of text editors
2022-09-05 19:23 ` Lars Ingebrigtsen
1 sibling, 1 reply; 8+ messages in thread
From: Po Lu via Bug reports for GNU Emacs, the Swiss army knife of text editors @ 2022-07-11 10:25 UTC (permalink / raw)
To: Daniel Martín; +Cc: 56462
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.
^ permalink raw reply [flat|nested] 8+ messages in thread
* bug#56462: 29.0.50; [PATCH] Memory leak in ns_draw_relief
2022-07-11 10:25 ` Po Lu via Bug reports for GNU Emacs, the Swiss army knife of text editors
@ 2022-09-05 19:23 ` Lars Ingebrigtsen
0 siblings, 0 replies; 8+ messages in thread
From: Lars Ingebrigtsen @ 2022-09-05 19:23 UTC (permalink / raw)
To: Po Lu; +Cc: 56462, Daniel Martín
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.
^ permalink raw reply [flat|nested] 8+ messages in thread
end of thread, other threads:[~2022-09-05 19:23 UTC | newest]
Thread overview: 8+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
[not found] <m1fsjaz84s.fsf.ref@yahoo.es>
2022-07-09 14:13 ` 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
2022-07-10 2:25 ` Po Lu via Bug reports for GNU Emacs, the Swiss army knife of text editors
2022-07-10 10:37 ` Daniel Martín via Bug reports for GNU Emacs, the Swiss army knife of text editors
2022-07-10 20:52 ` Daniel Martín via Bug reports for GNU Emacs, the Swiss army knife of text editors
2022-07-11 1:50 ` Po Lu via Bug reports for GNU Emacs, the Swiss army knife of text editors
2022-07-11 8:01 ` Alan Third
2022-07-11 10:25 ` Po Lu via Bug reports for GNU Emacs, the Swiss army knife of text editors
2022-09-05 19:23 ` Lars Ingebrigtsen
Code repositories for project(s) associated with this external index
https://git.savannah.gnu.org/cgit/emacs.git
https://git.savannah.gnu.org/cgit/emacs/org-mode.git
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.