Обсуждение: Detecting memory leaks with libpq?

Hi all,

I'm building a small C application that uses libpq and I was wondering
if there's an easy way to detect memory leaks in my code.

I think I'm calling PQclear and friends correctly, but I'd like to
double-check it. I was wondering if there's a function in libpq to
check memory-use usage/internals, or something like that.

Thanks in advance,
Antonio

P.S.: I assume this is the proper list for these sort of questions, right?

Wrap your main logic in a loop that runs it 100,000 or more times.  However, the process itself should never exit (eg, only ever exist as one pid).  As the process runs, monitor it with top, htop (really nice util for Linux), vmstat, etc...  Does the memory usage go up and up, generally linearly with time?

Run the same process using "electronic fence" [1] or "valgrind" [2].

[1] http://linux.die.net/man/3/efence  (not for finding memory leaks per se, but useful for finding memory mis-usage.
[2] http://valgrind.org/

On 19/07/2011 6:41 PM, Antonio Vieiro wrote:
> Hi all,
>
> I'm building a small C application that uses libpq and I was wondering
> if there's an easy way to detect memory leaks in my code.
>
> I think I'm calling PQclear and friends correctly, but I'd like to
> double-check it. I was wondering if there's a function in libpq to
> check memory-use usage/internals, or something like that.
>
If I genuinely suspected a leak and running the code in a loop showed
continually increasing memory use, I'd use valgrind to try to track it
down. Just like for any other kind of leak checking.

Note that some "leaks" that are reported are _normal_ in most software.
There is absolutely no harm in not free()ing a structure that's
allocated only once during init and never messed with afterwards. The OS
clears the memory anyway, so free()ing it is just a waste of CPU cycles.

What you need to look for is patterns where memory is _repeatedly_
allocated and not free()'d . For that, you need to run quite a few
repetitions within one process so you can tell the difference between
the one-offs and genuine leaks.

--
Craig Ringer

POST Newspapers
276 Onslow Rd, Shenton Park
Ph: 08 9381 3088     Fax: 08 9388 2258
ABN: 50 008 917 717
http://www.postnewspapers.com.au/

On Jul 19, 2011, at 6:28 AM, Craig Ringer wrote:

> Note that some "leaks" that are reported are _normal_ in most software. There is absolutely no harm in not free()ing
astructure that's allocated only once during init and never messed with afterwards. The OS clears the memory anyway, so
free()ingit is just a waste of CPU cycles. 

Getting off topic here but "normal" isn't always "desirable." Some might say that allocating singletons and never
freeingthem - even after they're no longer valid - is just sloppy code. By the same logic, dangling pointers are A-OK,
solong as you never use them. So yes, it might be an extra cycle or two to free it now, but that's a cycle or two the
OSwon't have to do later, and it's almost certainly better to have a cleaner codebase that's 0.000001% slower. 

Or so some might argue. :)

Hi all,

Well, thanks for the ideas. I also prefer cleaning things up myself
before exiting.

I was expecting some small statistics from the library (connections
opened/closed, PGresults returned/freed, etc.) but I can do it myself,
before trying out  more heavyweight tools such as valgrind.

Cheers,
Antonio

2011/7/19 Ben Chobot <bench@silentmedia.com>:
> On Jul 19, 2011, at 6:28 AM, Craig Ringer wrote:
>
>> Note that some "leaks" that are reported are _normal_ in most software. There is absolutely no harm in not free()ing
astructure that's allocated only once during init and never messed with afterwards. The OS clears the memory anyway, so
free()ingit is just a waste of CPU cycles. 
>
> Getting off topic here but "normal" isn't always "desirable." Some might say that allocating singletons and never
freeingthem - even after they're no longer valid - is just sloppy code. By the same logic, dangling pointers are A-OK,
solong as you never use them. So yes, it might be an extra cycle or two to free it now, but that's a cycle or two the
OSwon't have to do later, and it's almost certainly better to have a cleaner codebase that's 0.000001% slower. 
>
> Or so some might argue. :)