|
From: Rehrmann, R. <rob...@sa...> - 2013-02-04 16:26:30
|
Hello folks, we run a database on valgrind and tests on that database, to find memory leaks. The tests are written in Python, the database is written in C++. A test contains many testcases and configurations, so that a test may run more than 12 hours and has all in all (with all combinations of testcases and configurations) more than 10000 testruns (i.e. a testrun is a combination of a testcase with a configuration). If a memory leak was detected, it was helpful, to know, to which testrun this leak belongs. The testrun-name itself is not printed out in the stack (because the stack only contains the C++-stack - of course - and the testrun-name is visible in Python, only), therefore, we need to map the time, when the test was started and the time, when the memory leak occurred. We use the time-stamp parameter, to detect the latter. The timestamp printed out by valgrind is now not the timestamp of allocation, but of printing the result. Since memory leaks can only be detected at the end of a program, these are printed out at the end of the program, so that a match between testrun and memory leak is impossible. Now I would like to modify the sources of valgrind, so that the time of allocation is also stored internally and printed out in the summary. Could you please kindly give me a hint, which structure was to change and where there timestamp then needs to be inserted? I am fine with the relative time-stamp; I do not need an absolute one! Kind regards and thank you, Robin Rehrmann |
|
From: Philippe W. <phi...@sk...> - 2013-02-04 19:54:17
|
On Mon, 2013-02-04 at 16:26 +0000, Rehrmann, Robin wrote: > printing the result. Since memory leaks can only be detected at the > end of a program, these are printed out at the end of the program, so If you want to find which test specifically leaks some memory (i.e. loses the last pointer to a piece of memory), you can launch a leak search between each test. This can be done either from your program (by calling a client request) or from an external program (e.g. a shell, or the python test driver), using vgdb. The leak report can be incremental (i.e. showing the "delta" compared with the previous leak search). > I am fine with the relative time-stamp; I do not need an absolute one! Otherwise, as explained in another mail, MC_Chunk is one data structure to modify. The time stamp however will be per allocated block, while the leak check results are regrouping the leaked blocks in loss records. A single error is produced for each loss record. So, there will be (potentially) several leaked blocks mapped to one single loss record (and to one reported error). At my work, we use the "incremental leak report" between each test. Philippe |
|
From: Rehrmann, R. <rob...@sa...> - 2013-02-05 13:34:56
|
Thank you, that fixed it! Robin |
|
From: willpz <zie...@gm...> - 2013-07-24 20:15:12
|
> > Thank you, > that fixed it! > > Robin > > ------------------------------------------------------------------------------ > Free Next-Gen Firewall Hardware Offer > Buy your Sophos next-gen firewall before the end March 2013 > and get the hardware for free! Learn more. > http://p.sf.net/sfu/sophos-d2d-feb > Hi, Could you please tell how did you solve this issue (and eventually post the patch here)? Willian Rehrmann, Robin <robin.rehrmann <at> sap.com> writes: |
|
From: Robin R. <rob...@sa...> - 2013-07-26 17:25:17
|
willpz <zielonca <at> gmail.com> writes: > > > > > Thank you, > > that fixed it! > > > > Robin > > > > ---------------------------------------------------------------------------- -- > > Free Next-Gen Firewall Hardware Offer > > Buy your Sophos next-gen firewall before the end March 2013 > > and get the hardware for free! Learn more. > > http://p.sf.net/sfu/sophos-d2d-feb > > > > Hi, > > Could you please tell how did you solve this issue (and eventually post the > patch here)? > > Willian > > Rehrmann, Robin <robin.rehrmann <at> sap.com> writes: > > ---------------------------------------------------------------------------- -- > See everything from the browser to the database with AppDynamics > Get end-to-end visibility with application monitoring from AppDynamics > Isolate bottlenecks and diagnose root cause in seconds. > Start your free trial of AppDynamics Pro today! > http://pubads.g.doubleclick.net/gampad/clk?id=48808831&iu=/4140/ ostg.clktrk > Hi, I have not done it via patch. I just used vgdb: VALGRIND=`which valgrind` OPT="-v --tool=memcheck --leak-check=full --error-limit=no --log-file= $LOG_FILE --undef-value-errors=no --num-callers=32 --fullpath-after=src/ -- vgdb=yes --gen-suppressions=all" $VALGRIND $OPT <prog> & back_pid=$! vgdb --pid=$back_pid leak_check full definiteleak >> $log_file Regards, Robin |
|
From: willpz <zie...@gm...> - 2013-07-26 18:31:14
|
Hi Robin, Thank you for your answer. Instead of using a timestamp to compare logs, I put a client request (VALGRIND_DO_LEAK_CHECK or VALGRIND_DO_CHANGED_LEAK_CHECK) in my code as Philippe suggested, so I can run the test and then call the leak check. Best Regards, Willian |