Re: Valgrind mem-check for postgres extension
От | Andrew Dunstan |
---|---|
Тема | Re: Valgrind mem-check for postgres extension |
Дата | |
Msg-id | f2c8d399-9106-b9e6-d12e-d485d2a8aa6e@dunslane.net обсуждение исходный текст |
Ответ на | Re: Valgrind mem-check for postgres extension (Tom Lane <tgl@sss.pgh.pa.us>) |
Ответы |
Re: Valgrind mem-check for postgres extension
|
Список | pgsql-hackers |
On 2022-05-18 We 01:12, Tom Lane wrote: > Natarajan R <nataraj3098@gmail.com> writes: >> I have few doubts in here, >> 1. When I run with *--leak-check=full*, I get memory leaks for postgres >> functions under possibly or definitely lost categories.. Is this expected? > Maybe ... you did not show your test case, so it's hard to say. But it > could well be that this is an artifact of failing to define USE_VALGRIND. > >> 2. Is there any other way to test my extension memory leaks alone, because >> combining with postgres leaks is making instrumentation complex?.. > No, not really. > >> 3. I have seen some macros for valgrind support within postgres source code >> under utils/memdebug.h, but couldn't get complete idea of using it from the >> comments in pg_config_manual.h under *USE_VALGRIND *macro, pls provide some >> guidance here.. > If you didn't build the core code with USE_VALGRIND defined, then none of > this stuff is going to work ideally. > > The way I like to do it is to run configure, and then manually add > "#define USE_VALGRIND" to the generated src/include/pg_config.h > file before invoking "make". Probably other people have different > habits. The standard buildfarm config uses these for valgrind builds: CFLAGS => "-fno-omit-frame-pointer -O0 -fPIC", CPPFLAGS => "-DUSE_VALGRIND -DRELCACHE_FORCE_RELEASE", cheers andrew -- Andrew Dunstan EDB: https://www.enterprisedb.com
В списке pgsql-hackers по дате отправления: