This is the mail archive of the
libc-alpha@sourceware.org
mailing list for the glibc project.
Re: memory leak in res_nsend()
On 24.10.2005 22:33, Daniel Jacobowitz wrote:
On Mon, Oct 24, 2005 at 10:22:37PM +0400, Antony Dovgal wrote:
On 24.10.2005 22:08, Daniel Jacobowitz wrote:
>On Mon, Oct 24, 2005 at 10:04:04PM +0400, Antony Dovgal wrote:
>>__libc_thread_freeres(void) frees global _res, while I need to free
>>resources associated with my local __res_state struct.
>>I honestly do not understand how can valgrind help me with that calling
>>__libc_thread_freeres().
>
>By calling it in the context of any thread that hasn't exited, to free
>that thread's resources?
Ok, stop.
So you want to tell me that the leak is caused by valgrind itself and
doesn't exist without it, right ?
No. It's not a leak.
Ok, let me try to explain it:
wrap the code from the first message in some function and call it 100 000 times.
You'll get 83*100 000 bytes *memory leak*.
It's easy to check it: memory usage grows slowly, but it does grow.
It will be cleaned up when the program exits.
Cool.
I don't need to cleanup it when the program exits.
That basically means that I can't write a daemon using those functions, as such a daemon will effectively consume all the memory available.
Glibc knows this. It won't bother to free it, if there's no real leak.
Valgrind has a mechanism to handle this but it isn't adequate for you,
apparently.
Apparently, you're wrong here.
--
Wbr,
Antony Dovgal