|
From: richa <ri...@te...> - 2008-02-06 09:58:18
|
Hi Ashley, Thanks for your reply, I want to mention few points: a) I have checked again, am compiling the entire source code with "-g" option. So I think the debug info will not be any problem. b) Ashley, i am using the PCRE library as well as NTLM functionality for authentication purpose. These libraries are using dlopen/dlsym, dlclose() call is disabled in the code. It means dlclose() is not getting use. Even I have tried with the option for not using these libraries just to analyze memory leak. But still am getting the same output as before. Please let me know for any way to proceed. Leak is there (as getting "Definitely lost") but am not getting my application files to resolve the issue. Thanks, Richa -----Original Message----- From: Ashley Pittman [mailto:api...@co...] Sent: Tuesday, February 05, 2008 3:23 PM To: richa Subject: Re: [Valgrind-users] memcheck tool related query for multithreadedapplication On Tue, 2008-02-05 at 14:39 +0530, richa wrote: > > 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. Richa, This is because valgrind cannot decipher the filenames and line numbers for your application, this can happen for three reasons. 1) Valgrind is unable to parse the debug info. I've seen this when using esoteric compilers, it's quite rare. 2) Use are using dlopen/dlsym to call your code. If this is the case and you want to see filenames/line numbers you have to remove the call to doclose() 3) Your code isn't compiled with -g. This is by far the most common reason, you should double check this. Ashley, |
|
From: Dan K. <da...@ke...> - 2008-02-06 10:02:18
|
On Feb 6, 2008 1:59 AM, richa <ri...@te...> wrote: > a) I have checked again, am compiling the entire source code with "-g" > option. So I think the debug info will not be any problem. Time to show us your code. If you can't show the real app, show a toy app that has the same problem. In the course of writing the toy app, you may come across the problem. - Dan |
|
From: richa <ri...@te...> - 2008-02-06 12:40:18
|
Hi Dan, The source code level application is very huge and using lots of library functions. I do not know where exactly the application causing the memory leak, this is the reason I am using the valgrind memecheck tool. Dan, as I explain in my previous mailing list I have written the single file to allocate memory in main as well as in thread control without using the library as using in my application. As I do not know where exactly the memory leak is occurring, writing the toy application is tedious. Can you please suggest me any other alternate to identify my application level memory leak using valgrind memcheck tool. Thanks, Richa -----Original Message----- From: dan...@gm... [mailto:dan...@gm...] On Behalf Of Dan Kegel Sent: Wednesday, February 06, 2008 3:32 PM To: richa Cc: val...@li...; val...@li... Subject: Re: [Valgrind-users] memcheck tool related query for multithreadedapplication On Feb 6, 2008 1:59 AM, richa <ri...@te...> wrote: > a) I have checked again, am compiling the entire source code with "-g" > option. So I think the debug info will not be any problem. Time to show us your code. If you can't show the real app, show a toy app that has the same problem. In the course of writing the toy app, you may come across the problem. - Dan |
|
From: Dan K. <da...@ke...> - 2008-02-06 15:30:53
|
On Feb 6, 2008 4:41 AM, richa <ri...@te...> wrote:
> As I do not know where exactly the memory leak is occurring, writing the toy
> application is tedious.
Don't look for the real memory leak. Look instead for where Valgrind stops
giving good stack dumps.
Here's an untested idea: hook malloc to call a function that
deliberately refers to
uninitialized memory, and see if any of the stack dumps you get back
are bad. If any are, you have stumbled upon the valgrind problem.
e.g.
void *mymallochook (size_t size, const void *caller) {
int x;
printf("mallochook(%d, %p): uninit value is %d\n", size, caller, x);
}
main()
{
__malloc_hook = mymallochook;
...
See http://www.gnu.org/software/libc/manual/html_node/Hooks-for-Malloc.html
You'll have to convince valgrind to not give up after a thousand
errors, probably.
You might be able to tighten it up if you know the size of the leaked
allocation,
make mymallochook only do anything if the size matches.
- Dan
|