X-Authentication-Warning: delorie.com: mail set sender to geda-user-bounces using -f X-Recipient: geda-user AT delorie DOT com Date: Mon, 14 Dec 2020 22:29:20 +0100 (CET) From: Roland Lutz To: "Glenn (glimrick AT epilitimus DOT com) [via geda-user AT delorie DOT com]" Subject: Re: [geda-user] Memory leak patches In-Reply-To: <4df42e11-5211-8177-4afc-e3aaaf9a61f4@epilitimus.com> Message-ID: References: <20201130220505 DOT 0AE4282C54FD AT turkos DOT aspodata DOT se> <7c75ed03-456c-b408-8b50-0448f6b3a04f AT epilitimus DOT com> <1b2c64b3-6a36-c1f3-dd54-bb583c6bea17 AT epilitimus DOT com> <475f980e-fddd-60d1-9a02-a5bc5fb5805b AT epilitimus DOT com> <8706c896-e01a-9e6e-2bab-fe3607064093 AT epilitimus DOT com> <63273f86-b0fd-8835-a13e-6ab408f06dfc AT epilitimus DOT com> <4a1fbfca-3921-f674-1499-f11df8d5a58e AT epilitimus DOT com> <4df42e11-5211-8177-4afc-e3aaaf9a61f4 AT epilitimus DOT com> User-Agent: Alpine 2.21 (DEB 202 2017-01-01) MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="8323329-270082969-1607981360=:1180" 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 This message is in MIME format. The first part should be readable text, while the remaining parts are likely unreadable without MIME-aware tools. --8323329-270082969-1607981360=:1180 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8BIT On Mon, 14 Dec 2020, Glenn (glimrick AT epilitimus DOT com) [via geda-user AT delorie DOT com] wrote: > 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) This appears to be current_fonts->patterns->match. As far as I can tell, the last part of the stack trace would read (static functions in braces): FcFontMatch [pango_fc_patterns_get_font_pattern] [pango_fc_fontset_load_next_font] [pango_fc_fontset_get_font_at] [pango_fc_fontset_foreach] [pango_fontset_foreach] [get_base_metrics] pango_context_get_metrics It *may* be that this is not a library leak as much as a usage error, like a Pango context which hasn't been freed somewhere. In that case, I'd expect there to be another leak, though; this is most certainly not an error in eda_renderer_get_font_descent. The other two leaks are much harder to trace (I gave up around pango_font_map_load_fontset), but I think it's safe to assume that they are of a similar kind. Roland --8323329-270082969-1607981360=:1180--