Re: valgrind a background worker - Mailing list pgsql-general

From Jon Erdman
Subject Re: valgrind a background worker
Date
Msg-id 010101863c80f496-4bebe323-cb8a-4ac6-b1ae-b197a7fc70ba-000000@us-west-2.amazonses.com
Whole thread Raw
In response to Re: valgrind a background worker  (Tom Lane <tgl@sss.pgh.pa.us>)
Responses Re: valgrind a background worker  (Tom Lane <tgl@sss.pgh.pa.us>)
List pgsql-general
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





pgsql-general by date:

Previous
From: "Lawrence, Mike (DTST)"
Date:
Subject: RE: PostgreSQL 13.9.3 Uninstall fails with "Unable to initialize any installation mode"
Next
From: Adrian Klaver
Date:
Subject: Re: PostgreSQL 13.9.3 Uninstall fails with "Unable to initialize any installation mode"