|
From: Ivan I. <bar...@gm...> - 2009-07-22 15:28:01
|
Hi, I wonder whether it is possible to rack the memory allocation/deallocation in my application and all linked libraries by using Valgrind ? What do I mean by that: I'd like to turn on some log that would write a memory allocation in the following form: address, source file, source line of where the allocation occurred (using C++ "new" operator, malloc, etc.). The same is for deallocation (when using C++ "delete" operator, free, etc.). Just in case: the purpose why I need that is that I'd like to quickly find the source line where the allocation (and possible deallocation if this is a dangling pointer) of memory for some problematic object occurred. The point is when there are a lot of unfamiliar code and you quickly need to find a problem (the point where the object was created could really help), that would be really good thing. So is that (or at least anything close to what I need) possible using Valgrind ? Thanks |
|
From: Alexander P. <gl...@go...> - 2009-07-22 15:42:56
|
Isn't wrapping *alloc/free and new/delete enough for that (i.e. can you recompile all the allocators you need)? If yes, it's possible not to use Valgrind at all. You can also edit memcheck/mc_malloc_wrappers.c to add the necessary functionality to Memcheck, I think. Alex On Wed, Jul 22, 2009 at 7:27 PM, Ivan Ivanov<bar...@gm...> wrote: > Hi, > > I wonder whether it is possible to rack the memory allocation/deallocation > in my application and all linked libraries by using Valgrind ? What do I > mean by that: I'd like to turn on some log that would write a memory > allocation in the following form: address, source file, source line of where > the allocation occurred (using C++ "new" operator, malloc, etc.). The same > is for deallocation (when using C++ "delete" operator, free, etc.). > Just in case: the purpose why I need that is that I'd like to quickly find > the source line where the allocation (and possible deallocation if this is a > dangling pointer) of memory for some problematic object occurred. The point > is when there are a lot of unfamiliar code and you quickly need to find a > problem (the point where the object was created could really help), that > would be really good thing. > So is that (or at least anything close to what I need) possible using > Valgrind ? > Thanks > ------------------------------------------------------------------------------ > > _______________________________________________ > Valgrind-users mailing list > Val...@li... > https://lists.sourceforge.net/lists/listinfo/valgrind-users > > -- WBR, Alexander Potapenko Software Engineer Google Moscow |
|
From: Ivan I. <bar...@gm...> - 2009-07-22 16:04:09
|
Isn't wrapping *alloc/free and new/delete enough for that (i.e. can > you recompile all the allocators you need)? If yes, it's possible not > to use Valgrind at all. That's might be a solution, but what do you mean by "wrapping" ? Can you provide an example and generally the way how to do that ? If your solution supposes to somehow change the source code (for example by something like #define new debug_new) that can be hard taking into account that I link my application with a HUGE Qt library and that will need to make those changes throughout the whole Qt library source code and further recompilation that is not guarantee it will be successfully built then. Or there is come features in clib/libstdc++ that I don't know ? Can you hint me then ? I thought using Valgrind could help me to do that without any additional work as I believe it is not a problem for Valgrind to track the memory allocation/deallocation sources and for example turn on the log by some option. > > > You can also edit memcheck/mc_malloc_wrappers.c to add the necessary > functionality to Memcheck, I think. Thanks. I'll have a look > > > Alex > > > > Hi, > > > > I wonder whether it is possible to rack the memory > allocation/deallocation > > in my application and all linked libraries by using Valgrind ? What do I > > mean by that: I'd like to turn on some log that would write a memory > > allocation in the following form: address, source file, source line of > where > > the allocation occurred (using C++ "new" operator, malloc, etc.). The > same > > is for deallocation (when using C++ "delete" operator, free, etc.). > > Just in case: the purpose why I need that is that I'd like to quickly > find > > the source line where the allocation (and possible deallocation if this > is a > > dangling pointer) of memory for some problematic object occurred. The > point > > is when there are a lot of unfamiliar code and you quickly need to find a > > problem (the point where the object was created could really help), that > > would be really good thing. > > So is that (or at least anything close to what I need) possible using > > Valgrind ? > > Thanks > |
|
From: tom f. <tf...@al...> - 2009-07-22 17:01:35
|
Ivan Ivanov <bar...@gm...> writes: > Just in case: the purpose why I need that is that I'd like to quickly > find the source line where the allocation (and possible deallocation > if this is a dangling pointer) of memory for some problematic object > occurred. The point is when there are a lot of unfamiliar code and > you quickly need to find a problem (the point where the object was > created could really help), that would be really good thing. You probably just want to use the new-ish --track-origins feature. I think it was introduced in 3.4, but don't quote me on that. -tom |
|
From: Christophe-Marie D. <chm...@gm...> - 2009-07-22 17:15:21
|
> You probably just want to use the new-ish --track-origins feature. I > think it was introduced in 3.4, but don't quote me on that. isn't --track-origin for tracking the origin of uninitialized values? This is different from telling when the allocation/deallocation of an object was done, although this is indeed _very_ usefull for finding bugs in problematic objects. -- Christophe-Marie Duquesne |
|
From: Ivan I. <bar...@gm...> - 2009-07-22 18:05:59
|
I just found a very interesting feature of libc that allows to do exactly what I've been looking. Have a look at http://www.gnu.org/software/libc/manual/html_node/Allocation-Debugging.html#Allocation-Debugging Nevertheless I'm still curious is it possible to do the same using Valgrind ? Or if anybody knows the other way to do that, please share your experience. I hope the information I've found will be useful to all other people and maybe Valgrind team will consider that useful to implement such a feature. > > You probably just want to use the new-ish --track-origins feature. I > > think it was introduced in 3.4, but don't quote me on that. > > isn't --track-origin for tracking the origin of uninitialized values? > This is different from telling when the allocation/deallocation of an > object was done, although this is indeed _very_ usefull for finding > bugs in problematic objects. > > -- > Christophe-Marie Duquesne > |
|
From: Samuel B. <na...@gm...> - 2009-07-27 01:14:40
|
At Wed, 22 Jul 2009 18:27:58 +0300, Ivan Ivanov wrote: > Hi, > > I wonder whether it is possible to rack the memory allocation/deallocation > in my application and all linked libraries by using Valgrind ? What do I > mean by that: I'd like to turn on some log that would write a memory > allocation in the following form: address, source file, source line of where > the allocation occurred (using C++ "new" operator, malloc, etc.). The same > is for deallocation (when using C++ "delete" operator, free, etc.). > > Just in case: the purpose why I need that is that I'd like to quickly find > the source line where the allocation (and possible deallocation if this is a > dangling pointer) of memory for some problematic object occurred. The point > is when there are a lot of unfamiliar code and you quickly need to find a > problem (the point where the object was created could really help), that > would be really good thing. You tried just running valgrind on it yet, or perhaps running valgrind with --leak-check=full? Valgrind's default "memcheck" skin is supposed to track all of the info you want, tracks all the information you want, except it doesn't avoid re-using deallocated blocks forever, so your dangling pointers might be an issue if they dangle to long before they get used again. To control how long these dangling pointers will be catchable, you could use the --freelist-vol flag. |