Thread: valgrind a background worker
Hi,
I've got a background worker that has a slow memory leak in it
somewhere. How can I get it to start under valgrind to get a memcheck
output from it?
--
Jon Erdman (aka StuckMojo)
PostgreSQL Zealot
=?UTF-8?Q?Jon_Erdman?= <jon@thewickedtribe.net> writes:
> I've got a background worker that has a slow memory leak in it
> somewhere. How can I get it to start under valgrind to get a memcheck
> output from it?
You have to valgrind the whole cluster AFAIK. Basically, start
the postmaster under valgrind with --trace-children=yes.
For leak tracking you probably also want
--leak-check=full --track-origins=yes --read-var-info=yes
regards, tom lane
Aha! Thanks Tom! This will be my first time using valgrind, so I was unaware of trace-children, and getting it to attachto forked stuff was exactly where I thought the difficulty would lie. This is great, much appreciated! I’m suspecting that the leak might be coming from initStringInfo(), as I see a palloc() in there and no associated pfree()in my background worker’s code, but looking at the elog backend code, it looks like maybe you only have to explicitlyfree buf if you relocate it larger? -- Jon Erdman > On Feb 10, 2023, at 9:03 AM, Tom Lane <tgl@sss.pgh.pa.us> wrote: > > =?UTF-8?Q?Jon_Erdman?= <jon@thewickedtribe.net> writes: >> I've got a background worker that has a slow memory leak in it >> somewhere. How can I get it to start under valgrind to get a memcheck >> output from it? > > You have to valgrind the whole cluster AFAIK. Basically, start > the postmaster under valgrind with --trace-children=yes. > For leak tracking you probably also want > --leak-check=full --track-origins=yes --read-var-info=yes > > regards, tom lane
=?UTF-8?Q?Jon_Erdman?= <jon@thewickedtribe.net> writes:
> I’m suspecting that the leak might be coming from initStringInfo(), as I see a palloc() in there and no associated
pfree()in my background worker’s code, but looking at the elog backend code, it looks like maybe you only have to
explicitlyfree buf if you relocate it larger?
Usually it's more like "you need to pfree if you allocated in a long-lived
memory context". elog is working in ErrorContext which it expects will
be reset when the dust settles.
regards, tom lane
On Fri, Feb 10, 2023 at 10:04 AM Tom Lane <tgl@sss.pgh.pa.us> wrote: > > =?UTF-8?Q?Jon_Erdman?= <jon@thewickedtribe.net> writes: > > I've got a background worker that has a slow memory leak in it > > somewhere. How can I get it to start under valgrind to get a memcheck > > output from it? > > You have to valgrind the whole cluster AFAIK. Basically, start > the postmaster under valgrind with --trace-children=yes. > For leak tracking you probably also want > --leak-check=full --track-origins=yes --read-var-info=yes One additional comment... the program in question and PostgreSQL should also be built with -g -O1 per https://valgrind.org/docs/manual/quick-start.html . Otherwise, there's a risk the line information will not be accurate or usable. Jeff
Jeffrey Walton <noloader@gmail.com> writes: > On Fri, Feb 10, 2023 at 10:04 AM Tom Lane <tgl@sss.pgh.pa.us> wrote: >> You have to valgrind the whole cluster AFAIK. Basically, start >> the postmaster under valgrind with --trace-children=yes. >> For leak tracking you probably also want >> --leak-check=full --track-origins=yes --read-var-info=yes > One additional comment... the program in question and PostgreSQL > should also be built with -g -O1 per > https://valgrind.org/docs/manual/quick-start.html . Otherwise, there's > a risk the line information will not be accurate or usable. Yeah. Also, you need to compile Postgres with -DUSE_VALGRIND if you want valgrind to have any idea about palloc/pfree. regards, tom lane
On 2/10/23 3:05 PM, Tom Lane wrote: > Jeffrey Walton <noloader@gmail.com> writes: >> On Fri, Feb 10, 2023 at 10:04 AM Tom Lane <tgl@sss.pgh.pa.us> wrote: >>> You have to valgrind the whole cluster AFAIK. Basically, start >>> the postmaster under valgrind with --trace-children=yes. >>> For leak tracking you probably also want >>> --leak-check=full --track-origins=yes --read-var-info=yes > >> One additional comment... the program in question and PostgreSQL >> should also be built with -g -O1 per >> https://valgrind.org/docs/manual/quick-start.html . Otherwise, there's >> a risk the line information will not be accurate or usable. > > Yeah. Also, you need to compile Postgres with -DUSE_VALGRIND > if you want valgrind to have any idea about palloc/pfree. Thanks much both of you! I'll report back how it goes ;) -- Jon Erdman (aka StuckMojo) PostgreSQL Zealot
On 2/10/23 9:08 PM, Jon Erdman wrote: > On 2/10/23 3:05 PM, Tom Lane wrote: >> Jeffrey Walton <noloader@gmail.com> writes: >>> On Fri, Feb 10, 2023 at 10:04 AM Tom Lane <tgl@sss.pgh.pa.us> wrote: >>>> You have to valgrind the whole cluster AFAIK. Basically, start >>>> the postmaster under valgrind with --trace-children=yes. >>>> For leak tracking you probably also want >>>> --leak-check=full --track-origins=yes --read-var-info=yes >> >>> One additional comment... the program in question and PostgreSQL >>> should also be built with -g -O1 per >>> https://valgrind.org/docs/manual/quick-start.html . Otherwise, there's >>> a risk the line information will not be accurate or usable. >> >> Yeah. Also, you need to compile Postgres with -DUSE_VALGRIND >> if you want valgrind to have any idea about palloc/pfree. > > Thanks much both of you! I'll report back how it goes ;) FYI folks: once I got the build done properly (valgrind brew wouldn't install on OSX) on linux, I was able to find and fix my leaks. They were from not calling pfree on StringInfo.data. -- Jon Erdman (aka StuckMojo) PostgreSQL Zealot