Le 17/01/2014 20:41, Orchid Win7 v1 nous fit lire :
> On 17/01/2014 07:35 PM, Le_Forgeron wrote:
>> Le 17/01/2014 19:54, Orchid Win7 v1 nous fit lire :
>>> I wonder if valgrind would be any help... (But then of course, I'd have
>>> to figure out how to build the application by hand!)
>>
>> for using valgrind, both at home&  work, yes it is useful (but you need
>> to allow a few options). Very usefull.
>>
>> valgrind only need a -g (and possibly -O0) to run your program.
>> Nothing like purify which requires a special compilation.
> 
> The problem is the difficulty of building the program on Linux. Provided
> I can persuade our regular build server to do this for me, it shouldn't
> be too bad.
> 
> The rest question is, will I be able to understand what the hell the
> program is trying to tell me? From the documentation I've seen, it looks
> reasonably intelligible. (Not like the raw hex dump that VS gives me...)

If valgrind/memcheck can find the symbols of your code (-g), with option
like -leak-check=full and -track-origin=yes, it will show you where the
leak was allocated (hint: with deep program, you might want to use
--num-callers=100 (default = 12))
The first line is about the allocating line... further, the hierarchy of
the functions up to the top function.

Also fancy: --malloc-fill=A5 --free-fill=8A (or other hex value), to
kill uninitialised variables happily at 0 on normal run.

--log-file is a must have too (--log-file=whateverfile.txt )

The only downside: runtime is multiplied by 50 to 200.
(and multicore/threads get serialised)

Also intersecting: --show-reachable=yes (block referenced by lost blocks...)

Post a reply to this message