Re: valgrind a background worker
От | Jon Erdman |
---|---|
Тема | Re: valgrind a background worker |
Дата | |
Msg-id | 010101863c80f496-4bebe323-cb8a-4ac6-b1ae-b197a7fc70ba-000000@us-west-2.amazonses.com обсуждение исходный текст |
Ответ на | Re: valgrind a background worker (Tom Lane <tgl@sss.pgh.pa.us>) |
Ответы |
Re: valgrind a background worker
|
Список | 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 по дате отправления: