This is the mail archive of the mailing list for the glibc project.

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

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.
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, you're wrong here.

Wbr, Antony Dovgal

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]