|
From: richa <ri...@te...> - 2008-02-05 09:09:39
|
Hi Dan / Paul,
Thanks for the reply.
>> Dan,
I am reusing the thread in case getting the client next request within the
timeout period.
Else terminating the thread for the next request.
>> Please find the few lines from the log below:
18 bytes in 6 blocks are definitely lost in loss record 103 of 441
==2081== at 0x401A905: malloc (vg_replace_malloc.c:207)
==2081== by 0x8077CB0: (within /home/richa/application)
==2081== by 0x8077DCA: (within /home/richa/application)
==2081== by 0x80A247C: (within /home/richa/application)
==2081== by 0x80A199B: (within /home/richa/application)
==2081== by 0x807BA06: (within /home/richa/application)
==2081== by 0x805C698: (within /home/richa/application)
==2081== by 0x40EFADF: pthread_start_thread (in /lib/libpthread-0.10.so)
==2081== by 0x421D926: clone (in /lib/libc-2.3.2.so)
Where "application" is the compiled binary name.
Please see the Red colored marked line, my query is why I am getting the
valgrind application file name vg_replace_malloc.c:207.
The outcome should show my written application name.
Same lines I am getting multiple times in the logs under "Definitely lost"
error, so I need to care of it.
Paul,
according to your reply, I agree valgrind replaces calls to glibc memory
management functions with it own instrumented version.
Just to recheck my application, I have written one signal file named leak.c,
where I am allocating memory but not freeing it intentionally,
And then creating the thread and allocating memory there and not freeing it
again intentionally to see how the valgrin memcheck tool will give the
output..
After performing the valgrind memory check the output I got is:
==2216== 10 bytes in 1 blocks are indirectly lost in loss record 1 of 3
==2216== at 0x401A905: malloc (vg_replace_malloc.c:207)
==2216== by 0x8048564: main (leak.c:17) // here I am getting leak.c file
name and line number where I am allocating memory
==2216==
==2216==
==2216== 120 bytes in 1 blocks are still reachable in loss record 2 of 3
==2216== at 0x401A905: malloc (vg_replace_malloc.c:207)
==2216== by 0x804861E: start_routine() (leak.c:36) // here I am getting
leak.c file name and line number where I am allocating memory in thread
control
==2216== by 0x4042ADF: pthread_start_thread (in /lib/libpthread-0.10.so)
==2216== by 0x424E926: clone (in /lib/libc-2.3.2.so)
How come this behavior is different.
According to my understanding, I should get my application file name and
line number ( as I got with leak.c exp)
Please tell me where I am going wrong while using the tool.
Thanks
Richa
_____
From: richa [mailto:ri...@te...]
Sent: Monday, February 04, 2008 3:48 PM
To: 'val...@li...'
Subject: memcheck tool related query for multithreaded application
Hi All,
I have written the multithreaded server application, a thread will get spawn
to process the client request.
The thread will get terminated once processed the request.
I am using g++ compiler for compiling my application of version
libc-2.2.4-13 in linux 7.2
The code is compiled with "-g" option as well as with pthread and other
relevant libraries.
Load test result is the memory leak.
I am using the valgrind-3.3.0 memcheck tool to analyze the memory leak, the
option for using memcheck tool is:
valgrind --tool=memcheck -v --trace-children=yes --num-callers=20
--leak-check=yes --leak-resolution=high --show-reachable=yes
--workaround-gcc296-bugs=yes <binary name with full path> 2> MemoryLeak.log
&
once I execute the command mentioned above, I will send the client request
to the server and once the server processed the request, I am doing:
pkill memcheck
and Valgrind will dump the output into the MemoryLeak.log file.
I am not able to identify the leak in my application files else I am getting
the output as valgrind application file as:
malloc (vg_replace_malloc.c:207).
The memory leak output should indicate my application file name instead of
valgrind application file name.
Please help me in solving the problem.
Thanks in advance,
Richa
|
|
From: Julian S. <js...@ac...> - 2008-02-05 09:49:11
|
> 18 bytes in 6 blocks are definitely lost in loss record 103 of 441 > ==2081== at 0x401A905: malloc (vg_replace_malloc.c:207) That's supposed to happen. The calls your application makes to malloc are rerouted to Memcheck's own version, in vg_replace_malloc.c. > ==2081== by 0x8077CB0: (within /home/richa/application) > ==2081== by 0x8077DCA: (within /home/richa/application) > ==2081== by 0x80A247C: (within /home/richa/application) > ==2081== by 0x80A199B: (within /home/richa/application) > ==2081== by 0x807BA06: (within /home/richa/application) > ==2081== by 0x805C698: (within /home/richa/application) This probably happened because you compiled your application without debug information, or stripped it off afterwards. Make sure you have a debug build (with -g in all the compilation commands). J |
|
From: Paul F. <pa...@fr...> - 2008-02-05 10:49:32
|
Hi Quoting richa <ri...@te...>: > I am reusing the thread in case getting the client next request within the > timeout period. > Else terminating the thread for the next request. > > >> Please find the few lines from the log below: > > 18 bytes in 6 blocks are definitely lost in loss record 103 of 441 > ==2081== at 0x401A905: malloc (vg_replace_malloc.c:207) > ==2081== by 0x8077CB0: (within /home/richa/application) This looks like 'application' does not have debug info (that is, compiled with -g), and/or it is stripped. > ==2216== 10 bytes in 1 blocks are indirectly lost in loss record 1 of 3 > ==2216== at 0x401A905: malloc (vg_replace_malloc.c:207) > ==2216== by 0x8048564: main (leak.c:17) // here I am getting leak.c file > name and line number where I am allocating memory This time it looks like leak.c was compiled with -g. A+ Paul |