Rocksolid Light

Welcome to novaBBS (click a section below)

mail  files  register  newsreader  groups  login

Message-ID:  

19 May, 2024: Line wrapping has been changed to be more consistent with Usenet standards.
 If you find that it is broken please let me know here rocksolid.nodes.help


devel / comp.lang.c++ / Re: Memory leaks in C libraries linked into C++ program

SubjectAuthor
* Memory leaks in C libraries linked into C++ programFrederick Virchanza Gotham
+* Re: Memory leaks in C libraries linked into C++ programred floyd
|`- Re: Memory leaks in C libraries linked into C++ programFrederick Virchanza Gotham
+* Re: Memory leaks in C libraries linked into C++ programPaavo Helde
|+- Re: Memory leaks in C libraries linked into C++ programFrederick Virchanza Gotham
|`- Re: Memory leaks in C libraries linked into C++ programVir Campestris
+- Re: Memory leaks in C libraries linked into C++ programScott Lurndal
`* Re: Memory leaks in C libraries linked into C++ programFrederick Virchanza Gotham
 `* Re: Memory leaks in C libraries linked into C++ programPaavo Helde
  `- Re: Memory leaks in C libraries linked into C++ programFrederick Virchanza Gotham

1
Memory leaks in C libraries linked into C++ program

<0a39da69-c5c7-4583-93eb-27aa01bd2554n@googlegroups.com>

  copy mid

https://www.novabbs.com/devel/article-flat.php?id=271&group=comp.lang.c%2B%2B#271

  copy link   Newsgroups: comp.lang.c++
X-Received: by 2002:a05:622a:11d0:b0:3f6:1f6e:b022 with SMTP id n16-20020a05622a11d000b003f61f6eb022mr2151948qtk.3.1685310581635;
Sun, 28 May 2023 14:49:41 -0700 (PDT)
X-Received: by 2002:a05:620a:1a87:b0:75b:262d:4051 with SMTP id
bl7-20020a05620a1a8700b0075b262d4051mr1240785qkb.7.1685310581373; Sun, 28 May
2023 14:49:41 -0700 (PDT)
Path: i2pn2.org!i2pn.org!usenet.blueworldhosting.com!diablo1.usenet.blueworldhosting.com!peer03.iad!feed-me.highwinds-media.com!news.highwinds-media.com!news-out.google.com!nntp.google.com!postnews.google.com!google-groups.googlegroups.com!not-for-mail
Newsgroups: comp.lang.c++
Date: Sun, 28 May 2023 14:49:41 -0700 (PDT)
Injection-Info: google-groups.googlegroups.com; posting-host=92.40.183.215; posting-account=w4UqJAoAAAAYC-PItfDbDoVGcg0yISyA
NNTP-Posting-Host: 92.40.183.215
User-Agent: G2/1.0
MIME-Version: 1.0
Message-ID: <0a39da69-c5c7-4583-93eb-27aa01bd2554n@googlegroups.com>
Subject: Memory leaks in C libraries linked into C++ program
From: cauldwel...@gmail.com (Frederick Virchanza Gotham)
Injection-Date: Sun, 28 May 2023 21:49:41 +0000
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
X-Received-Bytes: 4214
 by: Frederick Virchanza - Sun, 28 May 2023 21:49 UTC

About 15 - 20 years ago, I started writing a desktop PC program with a graphical user interface to analyse Ethernet networks. Over the years I've added functionality here and there in dribs and drabs, and so now today I have about 11 thousand lines of code in about 80 source and header files.

In the past few weeks though I've become serious about releasing a new version of my software with many new features. But the thing is though, I want it to be rock solid. I'm going to torture test it on a network with dozens of hosts and leave it running for days on end.

But first I need to fix something. When building my program for Linux, it links with the GTK3 port of wxWidgets, which in turn links with libpango and libfontconfig. When my program ends, AddressSanitiser reports memory leaks for allocations that took place inside libfontconfig. I have identified three such leaks. The first one is actually the fault of libpango, and there's a solution to it in an issue raised on GitLab:

https://gitlab.gnome.org/GNOME/pango/-/issues/748

I haven't figured out the other two yet, and so in order to troubleshoot, I want to put together a little subsystem for managing deallocations. libpango and libfontconfig are both written in C, and so inside these C libraries, I would put C code like the following:

#include <stdlib.h> // malloc, free

extern void ReleaseAtExit(void (*const funcptr)(void*), void *const handle);

void Some_Library_Function(void)
{
void *p = malloc(64);
ReleaseAtExit(free, p);
}

And then inside my main program, I would put:

#include <cassert> // assert
#include <cstdlib> // atexit
#include <vector> // vector
#include <utility> // pair
#include <mutex> // mutex, lock_guard

namespace {

std::vector< std::pair<void (*)(void*), void*> > to_be_released;

void Releaser(void)
{
for ( auto &e : to_be_released )
{
assert( nullptr != e.first );
assert( nullptr != e.second );
e.first(e.second);
}
}
}

extern "C" void ReleaseAtExit(void (*const funcptr)(void*), void *const handle)
{
static int const retval_from_atexit = std::atexit(Releaser);

static std::mutex mtx;
std::lock_guard mylock(mtx);
to_be_released.emplace_back(funcptr,handle);
}

So using this little subsystem, I can then for example edit C source files inside libfontconfig, and where I see it allocate a new list, I can do:

FcValueListPtr p = FcValueListCreate();
ReleaseAtExit( FcValueListDestroy, p );

So then I can run my program and see if it 'fixes' the memory leak. Of course this isn't a real solution, because if it's an accumulative memory leak then it will just get worse and worse until the program ends, but it will at least let me know what tree to bark up.

Anyone got any pointers for me here?

Re: Memory leaks in C libraries linked into C++ program

<u50s85$13g9m$1@redfloyd.dont-email.me>

  copy mid

https://www.novabbs.com/devel/article-flat.php?id=272&group=comp.lang.c%2B%2B#272

  copy link   Newsgroups: comp.lang.c++
Path: i2pn2.org!i2pn.org!eternal-september.org!news.eternal-september.org!redfloyd.dont-email.me!.POSTED!not-for-mail
From: no.spam....@its.invalid (red floyd)
Newsgroups: comp.lang.c++
Subject: Re: Memory leaks in C libraries linked into C++ program
Date: Sun, 28 May 2023 17:39:32 -0700
Organization: A noiseless patient Spider
Lines: 67
Message-ID: <u50s85$13g9m$1@redfloyd.dont-email.me>
References: <0a39da69-c5c7-4583-93eb-27aa01bd2554n@googlegroups.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 7bit
Injection-Date: Mon, 29 May 2023 00:39:33 -0000 (UTC)
Injection-Info: redfloyd.dont-email.me; posting-host="671611c799737443d8d4f89df648d7ec";
logging-data="1163574"; mail-complaints-to="abuse@eternal-september.org"; posting-account="U2FsdGVkX1+f7x+1wh96wtqMfyk+VPIF12H3N3tmjWk="
User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:102.0) Gecko/20100101
Thunderbird/102.11.0
Cancel-Lock: sha1:VPjCElvqQkJ0D3HSmTtu4vIYnNw=
In-Reply-To: <0a39da69-c5c7-4583-93eb-27aa01bd2554n@googlegroups.com>
Content-Language: en-US
 by: red floyd - Mon, 29 May 2023 00:39 UTC

On 5/28/2023 2:49 PM, Frederick Virchanza Gotham wrote:

>
> #include <stdlib.h> // malloc, free
>
> extern void ReleaseAtExit(void (*const funcptr)(void*), void *const handle);
>
> void Some_Library_Function(void)
> {
> void *p = malloc(64);
> ReleaseAtExit(free, p);
> }
>
> And then inside my main program, I would put:
>
> #include <cassert> // assert
> #include <cstdlib> // atexit
> #include <vector> // vector
> #include <utility> // pair
> #include <mutex> // mutex, lock_guard
>
> namespace {
>
> std::vector< std::pair<void (*)(void*), void*> > to_be_released;
>
> void Releaser(void)
> {
> for ( auto &e : to_be_released )
> {
> assert( nullptr != e.first );
> assert( nullptr != e.second );
> e.first(e.second);
> }
> }
> }
>
> extern "C" void ReleaseAtExit(void (*const funcptr)(void*), void *const handle)
> {
> static int const retval_from_atexit = std::atexit(Releaser);
>
> static std::mutex mtx;
> std::lock_guard mylock(mtx);
> to_be_released.emplace_back(funcptr,handle);
> }
>
> So using this little subsystem, I can then for example edit C source files inside libfontconfig, and where I see it allocate a new list, I can do:
>
> FcValueListPtr p = FcValueListCreate();
> ReleaseAtExit( FcValueListDestroy, p );
>
> So then I can run my program and see if it 'fixes' the memory leak. Of course this isn't a real solution, because if it's an accumulative memory leak then it will just get worse and worse until the program ends, but it will at least let me know what tree to bark up.
>
> Anyone got any pointers for me here?

First of all, your Releaser() function won't work as you think.

Your Releaser function will attempt to free the memory, even if
its already been freed, as you are NOT storing a NULL pointer in
ReleaseAtExit, instead it will attempt to free the pointer that was
malloc'ed even if it was already freed elsewhere in the code.

Second, when malloc'ed memory is released, the pointer doesn't get
nulled out, but this is mooted by the first issue above.

You're better off running under valgrind to find the memory leak.

Re: Memory leaks in C libraries linked into C++ program

<u51bn7$19s6m$1@dont-email.me>

  copy mid

https://www.novabbs.com/devel/article-flat.php?id=274&group=comp.lang.c%2B%2B#274

  copy link   Newsgroups: comp.lang.c++
Path: i2pn2.org!i2pn.org!eternal-september.org!news.eternal-september.org!.POSTED!not-for-mail
From: eesn...@osa.pri.ee (Paavo Helde)
Newsgroups: comp.lang.c++
Subject: Re: Memory leaks in C libraries linked into C++ program
Date: Mon, 29 May 2023 08:03:34 +0300
Organization: A noiseless patient Spider
Lines: 22
Message-ID: <u51bn7$19s6m$1@dont-email.me>
References: <0a39da69-c5c7-4583-93eb-27aa01bd2554n@googlegroups.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 7bit
Injection-Date: Mon, 29 May 2023 05:03:35 -0000 (UTC)
Injection-Info: dont-email.me; posting-host="4d7b3f968c205bac9251d0fb182d0c55";
logging-data="1372374"; mail-complaints-to="abuse@eternal-september.org"; posting-account="U2FsdGVkX19djQcaQM0qhzGonnkC7qYSWqHjLEZBLHA="
User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:102.0) Gecko/20100101
Thunderbird/102.11.1
Cancel-Lock: sha1:lmWA9xDcY1zFQ/9b18nuZ5PYafA=
Content-Language: en-US
In-Reply-To: <0a39da69-c5c7-4583-93eb-27aa01bd2554n@googlegroups.com>
 by: Paavo Helde - Mon, 29 May 2023 05:03 UTC

29.05.2023 00:49 Frederick Virchanza Gotham kirjutas:
>
> But first I need to fix something. When building my program for Linux, it links with the GTK3 port of wxWidgets, which in turn links with libpango and libfontconfig. When my program ends, AddressSanitiser reports memory leaks for allocations that took place inside libfontconfig. I have identified three such leaks.

The first thing you should be concerned about is if these leaks are
one-time or cumulative. There is not much point to free one-time
allocations at the end of the program because the OS will do the same,
only faster and more reliably (unless your program needs to run without
proper OS, which I doubt).

For finding out if the leak is cumulative, you can just run the program
in a tight loop and monitor the process size over time. If the program
is massively multithreaded, one can expect some increase over time
because of fragmentation, but it should stabilize asymptotically.

If the leaks are cumulative, then these should be fixed. Note this means
fixing, not developing too-clever schemas to work around them. If you
discover a cumulative leak in fontconfig, the community will be all
thankful if you identify it and submit patches to fix it.

Re: Memory leaks in C libraries linked into C++ program

<a0265c41-e0da-4052-8f61-19b235906ba7n@googlegroups.com>

  copy mid

https://www.novabbs.com/devel/article-flat.php?id=276&group=comp.lang.c%2B%2B#276

  copy link   Newsgroups: comp.lang.c++
X-Received: by 2002:a05:620a:3727:b0:75b:271b:8d1a with SMTP id de39-20020a05620a372700b0075b271b8d1amr1833207qkb.3.1685342653592;
Sun, 28 May 2023 23:44:13 -0700 (PDT)
X-Received: by 2002:a05:622a:198b:b0:3f6:b556:7c9a with SMTP id
u11-20020a05622a198b00b003f6b5567c9amr2148571qtc.7.1685342653352; Sun, 28 May
2023 23:44:13 -0700 (PDT)
Path: i2pn2.org!i2pn.org!usenet.blueworldhosting.com!diablo1.usenet.blueworldhosting.com!peer01.iad!feed-me.highwinds-media.com!news.highwinds-media.com!news-out.google.com!nntp.google.com!postnews.google.com!google-groups.googlegroups.com!not-for-mail
Newsgroups: comp.lang.c++
Date: Sun, 28 May 2023 23:44:13 -0700 (PDT)
In-Reply-To: <u50s85$13g9m$1@redfloyd.dont-email.me>
Injection-Info: google-groups.googlegroups.com; posting-host=194.168.183.164; posting-account=w4UqJAoAAAAYC-PItfDbDoVGcg0yISyA
NNTP-Posting-Host: 194.168.183.164
References: <0a39da69-c5c7-4583-93eb-27aa01bd2554n@googlegroups.com> <u50s85$13g9m$1@redfloyd.dont-email.me>
User-Agent: G2/1.0
MIME-Version: 1.0
Message-ID: <a0265c41-e0da-4052-8f61-19b235906ba7n@googlegroups.com>
Subject: Re: Memory leaks in C libraries linked into C++ program
From: cauldwel...@gmail.com (Frederick Virchanza Gotham)
Injection-Date: Mon, 29 May 2023 06:44:13 +0000
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
X-Received-Bytes: 2257
 by: Frederick Virchanza - Mon, 29 May 2023 06:44 UTC

On Monday, May 29, 2023 at 1:41:26 AM UTC+1, red floyd wrote:
>
> First of all, your Releaser() function won't work as you think.
>
> Your Releaser function will attempt to free the memory, even if
> its already been freed, as you are NOT storing a NULL pointer in
> ReleaseAtExit, instead it will attempt to free the pointer that was
> malloc'ed even if it was already freed elsewhere in the code.

Yeah that can happen, but the AddressSanitiser will also be able to tell me about 'double freed' memory. If I can manipulate the C code so that it:
(a) No longer has a memory leak
(b) Doesn't double-deallocate any resources
then I will at least have a better understanding of the leak. Then I can try fix it.


> You're better off running under valgrind to find the memory leak.

I already have the exact line numbers from AddressSanitiser. I've had got a quick fix though because I don't know exactly when the memory in question should be deallocated.

Re: Memory leaks in C libraries linked into C++ program

<b0bc2cb3-ebed-48d5-9ab3-0a167cc01c3dn@googlegroups.com>

  copy mid

https://www.novabbs.com/devel/article-flat.php?id=277&group=comp.lang.c%2B%2B#277

  copy link   Newsgroups: comp.lang.c++
X-Received: by 2002:a05:620a:24c3:b0:759:5d54:ee69 with SMTP id m3-20020a05620a24c300b007595d54ee69mr1322783qkn.1.1685342914857;
Sun, 28 May 2023 23:48:34 -0700 (PDT)
X-Received: by 2002:a05:622a:1a29:b0:3f7:fc71:f3ad with SMTP id
f41-20020a05622a1a2900b003f7fc71f3admr2089533qtb.9.1685342914679; Sun, 28 May
2023 23:48:34 -0700 (PDT)
Path: i2pn2.org!i2pn.org!usenet.blueworldhosting.com!diablo1.usenet.blueworldhosting.com!peer01.iad!feed-me.highwinds-media.com!news.highwinds-media.com!news-out.google.com!nntp.google.com!postnews.google.com!google-groups.googlegroups.com!not-for-mail
Newsgroups: comp.lang.c++
Date: Sun, 28 May 2023 23:48:34 -0700 (PDT)
In-Reply-To: <u51bn7$19s6m$1@dont-email.me>
Injection-Info: google-groups.googlegroups.com; posting-host=194.168.183.164; posting-account=w4UqJAoAAAAYC-PItfDbDoVGcg0yISyA
NNTP-Posting-Host: 194.168.183.164
References: <0a39da69-c5c7-4583-93eb-27aa01bd2554n@googlegroups.com> <u51bn7$19s6m$1@dont-email.me>
User-Agent: G2/1.0
MIME-Version: 1.0
Message-ID: <b0bc2cb3-ebed-48d5-9ab3-0a167cc01c3dn@googlegroups.com>
Subject: Re: Memory leaks in C libraries linked into C++ program
From: cauldwel...@gmail.com (Frederick Virchanza Gotham)
Injection-Date: Mon, 29 May 2023 06:48:34 +0000
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
X-Received-Bytes: 2688
 by: Frederick Virchanza - Mon, 29 May 2023 06:48 UTC

On Monday, May 29, 2023 at 6:05:57 AM UTC+1, Paavo Helde wrote:
> There is not much point to free one-time
> allocations at the end of the program because the OS will do the same,
> only faster and more reliably (unless your program needs to run without
> proper OS, which I doubt).

For the release build of a program, I just let the OS clean things up.

For the debug build though, I keep track of the one-time allocations so
that I can de-allocate them all at the end of the program -- in order to get
a less-cluttered report from AddressSanitiser.

> For finding out if the leak is cumulative, you can just run the program
> in a tight loop and monitor the process size over time. If the program
> is massively multithreaded, one can expect some increase over time
> because of fragmentation, but it should stabilize asymptotically.
>
> If the leaks are cumulative, then these should be fixed. Note this means
> fixing, not developing too-clever schemas to work around them. If you
> discover a cumulative leak in fontconfig, the community will be all
> thankful if you identify it and submit patches to fix it.

You'd be surprised. I raised an issue on the GitLab website belonging to Gnome (who write libpango), and I copy-pasted the report from AddressSanitiser. They deleted my issue and blocked my account. I've emailed them to try rectify things but nothing back yet.

Re: Memory leaks in C libraries linked into C++ program

<u51une$1cauk$1@dont-email.me>

  copy mid

https://www.novabbs.com/devel/article-flat.php?id=278&group=comp.lang.c%2B%2B#278

  copy link   Newsgroups: comp.lang.c++
Path: i2pn2.org!i2pn.org!eternal-september.org!news.eternal-september.org!.POSTED!not-for-mail
From: vir.camp...@invalid.invalid (Vir Campestris)
Newsgroups: comp.lang.c++
Subject: Re: Memory leaks in C libraries linked into C++ program
Date: Mon, 29 May 2023 11:27:58 +0100
Organization: A noiseless patient Spider
Lines: 40
Message-ID: <u51une$1cauk$1@dont-email.me>
References: <0a39da69-c5c7-4583-93eb-27aa01bd2554n@googlegroups.com>
<u51bn7$19s6m$1@dont-email.me>
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 7bit
Injection-Date: Mon, 29 May 2023 10:27:58 -0000 (UTC)
Injection-Info: dont-email.me; posting-host="b923060c98b19f8a1a5b06a9c323cd97";
logging-data="1453012"; mail-complaints-to="abuse@eternal-september.org"; posting-account="U2FsdGVkX197ShIfuStunMFc8t+fc05Tg1Tvd/1JTtw="
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:102.0) Gecko/20100101
Thunderbird/102.11.0
Cancel-Lock: sha1:VdM/pCcCs6RSiIOQCN/XamEg/aE=
Content-Language: en-GB
In-Reply-To: <u51bn7$19s6m$1@dont-email.me>
 by: Vir Campestris - Mon, 29 May 2023 10:27 UTC

On 29/05/2023 06:03, Paavo Helde wrote:
> 29.05.2023 00:49 Frederick Virchanza Gotham kirjutas:
>>
>> But first I need to fix something. When building my program for Linux,
>> it links with the GTK3 port of wxWidgets, which in turn links with
>> libpango and libfontconfig. When my program ends, AddressSanitiser
>> reports memory leaks for allocations that took place inside
>> libfontconfig. I have identified three such leaks.
>
> The first thing you should be concerned about is if these leaks are
> one-time or cumulative. There is not much point to free one-time
> allocations at the end of the program because the OS will do the same,
> only faster and more reliably (unless your program needs to run without
> proper OS, which I doubt).
>
> For finding out if the leak is cumulative, you can just run the program
> in a tight loop and monitor the process size over time. If the program
> is massively multithreaded, one can expect some increase over time
> because of fragmentation, but it should stabilize asymptotically.
>
> If the leaks are cumulative, then these should be fixed. Note this means
> fixing, not developing too-clever schemas to work around them. If you
> discover a cumulative leak in fontconfig, the community will be all
> thankful if you identify it and submit patches to fix it.
>
>
>

I agree 110%. At least.

It doesn't matter if your program leaks a page or two thousand if it
only does it once. It'll keep running forever, which is what you need.

Checking the ASAN reports on a short run and a long run should give you
a clue on this.

I don't know libfontconfig, but I wouldn't be surprised if something is
loading some data for a font it never frees. But only once.

Andy

Re: Memory leaks in C libraries linked into C++ program

<1h2dM.3732660$vBI8.22571@fx15.iad>

  copy mid

https://www.novabbs.com/devel/article-flat.php?id=279&group=comp.lang.c%2B%2B#279

  copy link   Newsgroups: comp.lang.c++
Path: i2pn2.org!i2pn.org!usenet.blueworldhosting.com!diablo1.usenet.blueworldhosting.com!peer03.iad!feed-me.highwinds-media.com!news.highwinds-media.com!fx15.iad.POSTED!not-for-mail
X-newsreader: xrn 9.03-beta-14-64bit
Sender: scott@dragon.sl.home (Scott Lurndal)
From: sco...@slp53.sl.home (Scott Lurndal)
Reply-To: slp53@pacbell.net
Subject: Re: Memory leaks in C libraries linked into C++ program
Newsgroups: comp.lang.c++
References: <0a39da69-c5c7-4583-93eb-27aa01bd2554n@googlegroups.com>
Lines: 16
Message-ID: <1h2dM.3732660$vBI8.22571@fx15.iad>
X-Complaints-To: abuse@usenetserver.com
NNTP-Posting-Date: Mon, 29 May 2023 14:03:41 UTC
Organization: UsenetServer - www.usenetserver.com
Date: Mon, 29 May 2023 14:03:41 GMT
X-Received-Bytes: 1472
 by: Scott Lurndal - Mon, 29 May 2023 14:03 UTC

Frederick Virchanza Gotham <cauldwell.thomas@gmail.com> writes:

>But first I need to fix something. When building my program for Linux, it l=
>inks with the GTK3 port of wxWidgets, which in turn links with libpango and=
> libfontconfig. When my program ends, AddressSanitiser reports memory leaks=
> for allocations that took place inside libfontconfig. I have identified th=
>ree such leaks. The first one is actually the fault of libpango, and there'=
>s a solution to it in an issue raised on GitLab:

Address sanitizer tells you that _at exit_, there was allocated memory
that hadn't been released. That's not necessarily a leak, just code
that never deallocates data with a process lifetime. Process exit
will deallocate everything anyway.

If the real memory use grows constantly during the application
runtime, then you have a leak.

Re: Memory leaks in C libraries linked into C++ program

<a741096f-cae6-4c65-beae-aa5571335a4en@googlegroups.com>

  copy mid

https://www.novabbs.com/devel/article-flat.php?id=286&group=comp.lang.c%2B%2B#286

  copy link   Newsgroups: comp.lang.c++
X-Received: by 2002:a05:620a:2956:b0:74d:f7d0:6a5f with SMTP id n22-20020a05620a295600b0074df7d06a5fmr183782qkp.0.1685401461831;
Mon, 29 May 2023 16:04:21 -0700 (PDT)
X-Received: by 2002:a05:620a:424f:b0:75b:744:3f51 with SMTP id
w15-20020a05620a424f00b0075b07443f51mr72983qko.13.1685401461623; Mon, 29 May
2023 16:04:21 -0700 (PDT)
Path: i2pn2.org!i2pn.org!weretis.net!feeder8.news.weretis.net!newsreader4.netcologne.de!news.netcologne.de!peer01.ams1!peer.ams1.xlned.com!news.xlned.com!peer03.iad!feed-me.highwinds-media.com!news.highwinds-media.com!news-out.google.com!nntp.google.com!postnews.google.com!google-groups.googlegroups.com!not-for-mail
Newsgroups: comp.lang.c++
Date: Mon, 29 May 2023 16:04:21 -0700 (PDT)
In-Reply-To: <0a39da69-c5c7-4583-93eb-27aa01bd2554n@googlegroups.com>
Injection-Info: google-groups.googlegroups.com; posting-host=92.40.182.41; posting-account=w4UqJAoAAAAYC-PItfDbDoVGcg0yISyA
NNTP-Posting-Host: 92.40.182.41
References: <0a39da69-c5c7-4583-93eb-27aa01bd2554n@googlegroups.com>
User-Agent: G2/1.0
MIME-Version: 1.0
Message-ID: <a741096f-cae6-4c65-beae-aa5571335a4en@googlegroups.com>
Subject: Re: Memory leaks in C libraries linked into C++ program
From: cauldwel...@gmail.com (Frederick Virchanza Gotham)
Injection-Date: Mon, 29 May 2023 23:04:21 +0000
Content-Type: text/plain; charset="UTF-8"
X-Received-Bytes: 1704
 by: Frederick Virchanza - Mon, 29 May 2023 23:04 UTC

Yesterday I wrote:
> When my program ends, AddressSanitiser reports memory leaks
> for allocations that took place inside libfontconfig

I've created a patch for libpango that eradicates all of the memory leaks reported by AddressSanitizer:

https://github.com/healytpk/libpango/commit/629b67918d7d2de6060e3bfc6246c3d6e76c15a6

This isn't intended as a final solution, but rather just as a stepping stone toward solving the problem properly.

Re: Memory leaks in C libraries linked into C++ program

<u542ik$1sp4o$1@dont-email.me>

  copy mid

https://www.novabbs.com/devel/article-flat.php?id=288&group=comp.lang.c%2B%2B#288

  copy link   Newsgroups: comp.lang.c++
Path: i2pn2.org!i2pn.org!eternal-september.org!news.eternal-september.org!.POSTED!not-for-mail
From: eesn...@osa.pri.ee (Paavo Helde)
Newsgroups: comp.lang.c++
Subject: Re: Memory leaks in C libraries linked into C++ program
Date: Tue, 30 May 2023 08:45:55 +0300
Organization: A noiseless patient Spider
Lines: 26
Message-ID: <u542ik$1sp4o$1@dont-email.me>
References: <0a39da69-c5c7-4583-93eb-27aa01bd2554n@googlegroups.com>
<a741096f-cae6-4c65-beae-aa5571335a4en@googlegroups.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 7bit
Injection-Date: Tue, 30 May 2023 05:45:56 -0000 (UTC)
Injection-Info: dont-email.me; posting-host="669598733b96a28b59ec4d5689ae9460";
logging-data="1991832"; mail-complaints-to="abuse@eternal-september.org"; posting-account="U2FsdGVkX19HyBFO2fqdRJmC5xYaAWKFLoQZDOqH1vU="
User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:102.0) Gecko/20100101
Thunderbird/102.11.1
Cancel-Lock: sha1:iqARIc6mDtpCeSrPxktNt97q+vs=
In-Reply-To: <a741096f-cae6-4c65-beae-aa5571335a4en@googlegroups.com>
Content-Language: en-US
 by: Paavo Helde - Tue, 30 May 2023 05:45 UTC

30.05.2023 02:04 Frederick Virchanza Gotham kirjutas:
> Yesterday I wrote:
>> When my program ends, AddressSanitiser reports memory leaks
>> for allocations that took place inside libfontconfig
>
> I've created a patch for libpango that eradicates all of the memory leaks reported by AddressSanitizer:
>
> https://github.com/healytpk/libpango/commit/629b67918d7d2de6060e3bfc6246c3d6e76c15a6
>
> This isn't intended as a final solution, but rather just as a stepping stone toward solving the problem properly.

This patch meant for helping to find the leaks does not diagnose the
leaks, but instead hides them by releasing the leaked memory just before
the program exit.

Why don't you record the allocation sequence number in your elaborate
leak registry? Then you could print out the leaked fonts at the program
exit to stderr, e.g.

LEAK: font allocation 17 is leaked.

If the program logic is single-threaded or at least somewhat repeatable,
you could then rerun the program, put a breakpoint on the 17-th
allocation, figure out why it gets leaked, and fix it properly.

Re: Memory leaks in C libraries linked into C++ program

<ade67029-4dcb-4c12-8dd8-3511e8d298bcn@googlegroups.com>

  copy mid

https://www.novabbs.com/devel/article-flat.php?id=289&group=comp.lang.c%2B%2B#289

  copy link   Newsgroups: comp.lang.c++
X-Received: by 2002:a05:622a:1a24:b0:3f6:b052:3431 with SMTP id f36-20020a05622a1a2400b003f6b0523431mr306418qtb.5.1685429360659;
Mon, 29 May 2023 23:49:20 -0700 (PDT)
X-Received: by 2002:a05:622a:413:b0:3f6:aacf:5835 with SMTP id
n19-20020a05622a041300b003f6aacf5835mr268834qtx.1.1685429360444; Mon, 29 May
2023 23:49:20 -0700 (PDT)
Path: i2pn2.org!i2pn.org!weretis.net!feeder6.news.weretis.net!1.us.feeder.erje.net!feeder.erje.net!usenet.blueworldhosting.com!diablo1.usenet.blueworldhosting.com!peer02.iad!feed-me.highwinds-media.com!news.highwinds-media.com!news-out.google.com!nntp.google.com!postnews.google.com!google-groups.googlegroups.com!not-for-mail
Newsgroups: comp.lang.c++
Date: Mon, 29 May 2023 23:49:20 -0700 (PDT)
In-Reply-To: <u542ik$1sp4o$1@dont-email.me>
Injection-Info: google-groups.googlegroups.com; posting-host=92.40.182.195; posting-account=w4UqJAoAAAAYC-PItfDbDoVGcg0yISyA
NNTP-Posting-Host: 92.40.182.195
References: <0a39da69-c5c7-4583-93eb-27aa01bd2554n@googlegroups.com>
<a741096f-cae6-4c65-beae-aa5571335a4en@googlegroups.com> <u542ik$1sp4o$1@dont-email.me>
User-Agent: G2/1.0
MIME-Version: 1.0
Message-ID: <ade67029-4dcb-4c12-8dd8-3511e8d298bcn@googlegroups.com>
Subject: Re: Memory leaks in C libraries linked into C++ program
From: cauldwel...@gmail.com (Frederick Virchanza Gotham)
Injection-Date: Tue, 30 May 2023 06:49:20 +0000
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
X-Received-Bytes: 3130
 by: Frederick Virchanza - Tue, 30 May 2023 06:49 UTC

On Tuesday, May 30, 2023 at 6:48:22 AM UTC+1, Paavo Helde wrote:
>
> This patch meant for helping to find the leaks does not diagnose the
> leaks, but instead hides them by releasing the leaked memory just before
> the program exit.

But at least I have a correct, finite list of the leaks. If I hadn't coded the patch properly, then AddressSanitizer might have complained about me 'double-freeing' memory. Now that I have the patch working and everything gets deallocated, I have a better understanding of the entire situation.

> Why don't you record the allocation sequence number in your elaborate
> leak registry? Then you could print out the leaked fonts at the program
> exit to stderr, e.g.
>
> LEAK: font allocation 17 is leaked.

Yeah I can do that. Also I can keep a realtime count of how many leaks there are in the registry, and update the figure on screen twice a second. So then if I run my program for 3 days, I can just glance at the GUI to check whether that number is increasing.

> If the program logic is single-threaded or at least somewhat repeatable,
> you could then rerun the program, put a breakpoint on the 17-th
> allocation, figure out why it gets leaked, and fix it properly.

It's not entirely that simple. I've looked through the functions where the memory gets allocated, but I'm not sure how long the font (or 'font map', or 'font class') is intended to live. I'll do more testing today but so far I think that they're supposed to live until the program ends. To give an example, let's say you have a wxTextBox, and then at runtime you set the font to Algerian, but then later in the program you set the font to Calibri. I don't know if the former font is just supposed to stay loaded until the program ends.


devel / comp.lang.c++ / Re: Memory leaks in C libraries linked into C++ program

1
server_pubkey.txt

rocksolid light 0.9.81
clearnet tor