Re: valgrind a background worker

From: Jon Erdman <jon(at)thewickedtribe(dot)net>
To: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
Cc: pgsql-general(at)postgresql(dot)org <pgsql-general(at)postgresql(dot)org>
Subject: Re: valgrind a background worker
Date: 2023-02-10 18:05:29
Message-ID: 010101863c80f496-4bebe323-cb8a-4ac6-b1ae-b197a7fc70ba-000000@us-west-2.amazonses.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-general


Aha! Thanks Tom! This will be my first time using valgrind, so I was unaware of trace-children, and getting it to attach to 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 explicitly free buf if you relocate it larger?
--
Jon Erdman

> On Feb 10, 2023, at 9:03 AM, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:
>
> =?UTF-8?Q?Jon_Erdman?= <jon(at)thewickedtribe(dot)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

In response to

Responses

Browse pgsql-general by date

  From Date Subject
Next Message Adrian Klaver 2023-02-10 18:08:26 Re: PostgreSQL 13.9.3 Uninstall fails with "Unable to initialize any installation mode"
Previous Message Lawrence, Mike (DTST) 2023-02-10 17:56:14 RE: PostgreSQL 13.9.3 Uninstall fails with "Unable to initialize any installation mode"