X-Authentication-Warning: delorie.com: mail set sender to geda-user-bounces using -f
X-Recipient: geda-user AT delorie DOT com
X-CMAE-Analysis: v=2.4 cv=ZIsSJV3b c=1 sm=1 tr=0 ts=5fd7b8e7
 a=+cj0cO56Fp8x7EdhTra87A==:117 a=qDWn4pq2TUohbLv55+KYqA==:17
 a=9+rZDBEiDlHhcck0kWbJtElFXBc=:19 a=IkcTkHD0fZMA:10 a=zTNgK-yGK50A:10
 a=eFMjm0EvCEhctBljNXIA:9 a=QEXdDO2ut3YA:10
X-SECURESERVER-ACCT: glimrick AT epilitimus DOT com
Subject: Re: [geda-user] Memory leak patches
To: geda-user AT delorie DOT com
References: <e4ff3c96-939b-a93e-a32f-5e938b6daa63 AT epilitimus DOT com>
 <alpine DOT DEB DOT 2 DOT 21 DOT 2011302045040 DOT 2894 AT nimbus>
 <20201130220505 DOT 0AE4282C54FD AT turkos DOT aspodata DOT se>
 <7c75ed03-456c-b408-8b50-0448f6b3a04f AT epilitimus DOT com>
 <alpine DOT DEB DOT 2 DOT 21 DOT 2012011606400 DOT 6785 AT nimbus>
 <1b2c64b3-6a36-c1f3-dd54-bb583c6bea17 AT epilitimus DOT com>
 <alpine DOT DEB DOT 2 DOT 21 DOT 2012021253440 DOT 1262 AT nimbus>
 <475f980e-fddd-60d1-9a02-a5bc5fb5805b AT epilitimus DOT com>
 <alpine DOT DEB DOT 2 DOT 21 DOT 2012071333290 DOT 3907 AT nimbus>
 <e6c5135f-b127-fd55-91b2-79aa357a5a07 AT epilitimus DOT com>
 <alpine DOT DEB DOT 2 DOT 21 DOT 2012081644480 DOT 3649 AT nimbus>
 <8706c896-e01a-9e6e-2bab-fe3607064093 AT epilitimus DOT com>
 <alpine DOT DEB DOT 2 DOT 21 DOT 2012111645180 DOT 13096 AT nimbus>
 <63273f86-b0fd-8835-a13e-6ab408f06dfc AT epilitimus DOT com>
 <alpine DOT DEB DOT 2 DOT 21 DOT 2012121301180 DOT 1221 AT nimbus>
 <4a1fbfca-3921-f674-1499-f11df8d5a58e AT epilitimus DOT com>
 <alpine DOT DEB DOT 2 DOT 21 DOT 2012141510100 DOT 22156 AT nimbus>
From: "Glenn (glimrick AT epilitimus DOT com) [via geda-user AT delorie DOT com]" <geda-user AT delorie DOT com>
Message-ID: <4df42e11-5211-8177-4afc-e3aaaf9a61f4@epilitimus.com>
Date: Mon, 14 Dec 2020 11:11:27 -0800
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:60.0) Gecko/20100101
 Firefox/60.0 SeaMonkey/2.53.3
MIME-Version: 1.0
In-Reply-To: <alpine.DEB.2.21.2012141510100.22156@nimbus>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit
X-AntiAbuse: This header was added to track abuse, please include it with any abuse report
X-AntiAbuse: Primary Hostname - a2plcpnl0121.prod.iad2.secureserver.net
X-AntiAbuse: Original Domain - delorie.com
X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12]
X-AntiAbuse: Sender Address Domain - epilitimus.com
X-Get-Message-Sender-Via: a2plcpnl0121.prod.iad2.secureserver.net: authenticated_id: glimrick AT epilitimus DOT com
X-Authenticated-Sender: a2plcpnl0121.prod.iad2.secureserver.net: glimrick AT epilitimus DOT com
X-Source: 
X-Source-Args: 
X-Source-Dir: 
X-CMAE-Envelope: MS4xfJ/7Z7WWWAcGnHcs4d1YM6q6pxXw5Cq70jkB0tkZSQ9hZwc0IbrVjk/U/71BoJjaLMwdRzgExBt9b2tj6SNXy/iCjAdLKnaIN0xWzQ6sY8bnrFPFd9m4
 3JkctGQUFWkoymNiPZcXbvLn+KaPDAEu0OXwYYbo6CHnWgiabqT5/INoaXhtnd5mYkKkgatbGElkkA/69JGUDv2ddHC0JCMF0Mxo5e3J4MXW6pID6qXlTEIp
Reply-To: geda-user AT delorie DOT com
Errors-To: nobody AT delorie DOT com
X-Mailing-List: geda-user AT delorie DOT com
X-Unsubscribes-To: listserv AT delorie DOT com
Precedence: bulk

Roland Lutz wrote:
>
> Are you sure edarenderer.c leaks memory?  It looks to me as if the
> GHashTable is set up correctly with key and value destroy functions.

Something is definitely leaking memory. I couldn't figure out what which
is why I just marked it, It may be a leak in the library and so not
fixable.

There are actually three leaks listed. The first two look to be the same
leak triggered twice:

> ==16700== 11,175 (3,840 direct, 7,335 indirect) bytes in 5 blocks are
> definitely lost in loss record 13,377 of 13,440
> ==16700==    at 0x4839D7B: realloc (vg_replace_malloc.c:836)
> ==16700==    by 0x5318299: ??? (in /usr/lib64/libfontconfig.so.1.8.0)
> ==16700==    by 0x5318921: ??? (in /usr/lib64/libfontconfig.so.1.8.0)
> ==16700==    by 0x5315C6A: FcFontRenderPrepare (in
> /usr/lib64/libfontconfig.so.1.8.0)
> ==16700==    by 0x531614F: FcFontMatch (in
> /usr/lib64/libfontconfig.so.1.8.0)
> ==16700==    by 0x50F3285: ??? (in /usr/lib64/libpangoft2-1.0.so.0.3800.1)
> ==16700==    by 0x50F342C: ??? (in /usr/lib64/libpangoft2-1.0.so.0.3800.1)
> ==16700==    by 0x5FE34ED: pango_context_get_metrics (in
> /usr/lib64/libpango-1.0.so.0.3800.1)
> ==16700==    by 0x57DE1DF: eda_renderer_get_font_descent
> (edarenderer.c:862)
> ==16700==    by 0x57DE1DF: eda_renderer_prepare_text (edarenderer.c:900)
> ==16700==    by 0x57DE570: eda_renderer_get_text_user_bounds
> (edarenderer.c:1531)
> ==16700==    by 0x57DE570: eda_renderer_default_get_user_bounds
> (edarenderer.c:1488)
> ==16700==    by 0x57E0CA2: eda_renderer_get_user_bounds
> (edarenderer.c:1473)
> ==16700==    by 0x45514D: o_text_get_rendered_bounds (o_text.c:77)
Notice that this one follows a somewhat different path after the
pango_context_get_metrics call. So the code between 0x5318299 and
pango_context_get_metrics is probably not at fault. Since it is a
realloc and given the size the code further down the stack trace is more
suspect than higher up.
> ==16700== 30,220 (2,560 direct, 27,660 indirect) bytes in 5 blocks are
> definitely lost in loss record 13,411 of 13,440
> ==16700==    at 0x4839D7B: realloc (vg_replace_malloc.c:836)
> ==16700==    by 0x5318299: ??? (in /usr/lib64/libfontconfig.so.1.8.0)
> ==16700==    by 0x5318A54: ??? (in /usr/lib64/libfontconfig.so.1.8.0)
> ==16700==    by 0x5318E8B: ??? (in /usr/lib64/libfontconfig.so.1.8.0)
> ==16700==    by 0x530C765: FcDefaultSubstitute (in
> /usr/lib64/libfontconfig.so.1.8.0)
> ==16700==    by 0x50F2AE9: ??? (in /usr/lib64/libpangoft2-1.0.so.0.3800.1)
> ==16700==    by 0x5FE34CB: pango_context_get_metrics (in
> /usr/lib64/libpango-1.0.so.0.3800.1)
> ==16700==    by 0x57DE1DF: eda_renderer_get_font_descent
> (edarenderer.c:862)
> ==16700==    by 0x57DE1DF: eda_renderer_prepare_text (edarenderer.c:900)
> ==16700==    by 0x57DE570: eda_renderer_get_text_user_bounds
> (edarenderer.c:1531)
> ==16700==    by 0x57DE570: eda_renderer_default_get_user_bounds
> (edarenderer.c:1488)
> ==16700==    by 0x57E0CA2: eda_renderer_get_user_bounds
> (edarenderer.c:1473)
> ==16700==    by 0x45514D: o_text_get_rendered_bounds (o_text.c:77)
> ==16700==    by 0x624AB7C: world_get_text_bounds (o_text_basic.c:163)

The final one is elsewhere and may be a library leak:
> ==16700== 36,264 (3,072 direct, 33,192 indirect) bytes in 6 blocks are
> definitely lost in loss record 13,420 of 13,440
> ==16700==    at 0x4839D7B: realloc (vg_replace_malloc.c:836)
> ==16700==    by 0x5318299: ??? (in /usr/lib64/libfontconfig.so.1.8.0)
> ==16700==    by 0x5318A54: ??? (in /usr/lib64/libfontconfig.so.1.8.0)
> ==16700==    by 0x5318E8B: ??? (in /usr/lib64/libfontconfig.so.1.8.0)
> ==16700==    by 0x530C765: FcDefaultSubstitute (in
> /usr/lib64/libfontconfig.so.1.8.0)
> ==16700==    by 0x50F2AE9: ??? (in /usr/lib64/libpangoft2-1.0.so.0.3800.1)
> ==16700==    by 0x5FE21B0: ??? (in /usr/lib64/libpango-1.0.so.0.3800.1)
> ==16700==    by 0x5FE32F7: pango_itemize_with_base_dir (in
> /usr/lib64/libpango-1.0.so.0.3800.1)
> ==16700==    by 0x5FEB240: ??? (in /usr/lib64/libpango-1.0.so.0.3800.1)
> ==16700==    by 0x5FED2D7: ??? (in /usr/lib64/libpango-1.0.so.0.3800.1)
> ==16700==    by 0x57DE25C: eda_renderer_calc_text_position
> (edarenderer.c:953)
> ==16700==    by 0x57DE25C: eda_renderer_prepare_text (edarenderer.c:915)
> ==16700==    by 0x57DF3AC: eda_renderer_draw_text (edarenderer.c:800)

Glenn