{"id":3742,"date":"2018-03-07T11:50:57","date_gmt":"2018-03-07T19:50:57","guid":{"rendered":"https:\/\/visualgdb.com\/w\/?p=3742"},"modified":"2018-03-07T11:50:57","modified_gmt":"2018-03-07T19:50:57","slug":"finding-memory-leaks-in-linux-programs-with-visualgdb","status":"publish","type":"post","link":"https:\/\/visualgdb.com\/tutorials\/profiler\/linux\/leaks\/","title":{"rendered":"Finding Memory Leaks in Linux Programs with VisualGDB"},"content":{"rendered":"

This tutorial shows how to find memory leaks in Linux programs using the VisualGDB integration with valgrind. Before you begin, install VisualGDB 5.3 or later.<\/p>\n

We will create a basic projectthat will randomly leak memory and will then use the\u00a0Dynamic Analysis feature of VisualGDB to\u00a0automatically run the program under Valgrind and produce a detailed report on memory leaks.<\/p>\n

    \n
  1. Start Visual Studio and open the VisualGDB Linux Project Wizard:\"01-prj\"<\/a><\/li>\n
  2. Select “Create a new project” -> “Application” -> “MSBuild”:\"02-app\"<\/a><\/li>\n
  3. Select the Linux computer you would like to target. VisualGDB will automatically check that it has all necessary tools and will install the missing ones:\"03-target\"<\/a><\/li>\n
  4. Proceed with the default option of keeping all source files on the Windows machine and uploading them during builds:
    \n    \"04-disp\"<\/a><\/li>\n
  5. Press “Finish” to create your project.\u00a0Replace the contents of\u00a0the main source file with the following code\u00a0demonstrating memory leaks:\n
    #include <iostream>\r\n#include <stdlib.h>\r\n#include <string>\r\n\r\ntemplate <int X> void AllocAndMaybeFree()\r\n{\r\n    char *pTest = new char[X];\r\n    if (rand() % 5)\r\n        delete[] pTest;\r\n}\r\n\r\nint main(int argc, char *argv[])\r\n{\r\n    AllocAndMaybeFree<1>();\r\n    AllocAndMaybeFree<2>();\r\n    AllocAndMaybeFree<3>();\r\n    AllocAndMaybeFree<4>();\r\n    AllocAndMaybeFree<5>();\r\n    AllocAndMaybeFree<6>();\r\n    AllocAndMaybeFree<7>();\r\n    AllocAndMaybeFree<8>();\r\n    AllocAndMaybeFree<9>();\r\n    AllocAndMaybeFree<10>();\r\n    return 0;\r\n}<\/pre>\n
    In real-world scenarios the memory is allocated in multiple different\u00a0parts\u00a0of\u00a0the program, and if some of those allocations are not released, the memory leaks. We\u00a0are simulating this with the\u00a0AllocAndMaybeFree()<\/strong> function that will “forget” to free the allocated memory block with a 20% probability. We use the template argument to make different invocations\u00a0of the function appear differently\u00a0in the call stack, as if we had 10 distinct functions potentially leaking memory. Build the project\u00a0and ensure\u00a0is results in no errors:\"05-code\"<\/a><\/li>\n
  6. Now we will show how to run the program under Valgrind. Open VisualGDB Project Properties, go to the Dynamic Analysis page and enable the “Analyze program behavior during runtime” checkbox:
    \n    \"06-analyze\"<\/a><\/li>\n
  7. Press OK and start debugging your program.\u00a0VisualGDB will automatically launch valgrind\u00a0and attach gdb to it. You will see the diagnostic output in the Valgrind Diagnostics window, but the rest of the\u00a0debugging experience will be the same as if you were debugging your program regularly:\"07-debug\"<\/a><\/li>\n
  8. Once the program exits, Valgrind will display the summary of the\u00a0discovered memory leaks:
    \n    \"08-summary\"<\/a><\/li>\n
  9. Open VisualGDB Project Properties again and switch the “Memory leaks” setting to “Full list”:
    \n    \"09-full\"<\/a><\/li>\n
  10. Run the program again. Valgrind will now report full call stacks of the allocations that were never freed, showing how calls #4 and #6 resulted in memory leaks:\"10-stacks\"<\/a><\/li>\n
  11. You can also\u00a0analyze the leaks\u00a0in real time using the GDB Session window in VisualGDB. Simply run the “mon leak_check” command while debugging under valgrind:\"11-check\"<\/a><\/li>\n
  12. Valgrind will output the summary of the current allocations:
    \n    \"12-initial\"<\/a><\/li>\n
  13. If you re-run the command after\u00a0a memory block is allocated, not freed and not pointed by any other block, the “mon leak_check” command will report it as “definitely lost” showing the allocation stack:\"13-new\"<\/a><\/li>\n
  14. Valgrind will also automatically handle references between the blocks. We will demonstrate this by\u00a0allocating an instance of a class that includes an STL string. Replace the main file contents with the following code:\n
    #include <iostream>\r\n#include <stdlib.h>\r\n#include <string>\r\n\r\nusing namespace std;\r\n\r\nclass DemoClass\r\n{\r\npublic:\r\n    std::string Test = \"xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx\";\r\n};\r\n\r\nvoid func()\r\n{\r\n    DemoClass *p = new DemoClass();\r\n}\r\n \r\nint main(int argc, char *argv[])\r\n{\r\n    func();\r\n    return 0;\r\n}<\/pre>\n
    \"14-class\"<\/a><\/li>\n
  15. Set\u00a0a breakpoint in the func() function and start debugging. Once the breakpoint is hit, run the “mon leak_check” command (use the ‘up’ button in the GDB Session window to repeat the previous\u00a0command instead of re-typing it):
    \n    \"15-reach\"<\/a><\/li>\n
  16. Step over the allocation line and re-run the “mon leak_check” command: \"16-reach2\"<\/a>Note how the “still reachable” blocks have grown by 2 and no leak is reported yet. This happens because the ‘p’ variable still points to the newly allocated memory and valgrind assumes it might be freed later.<\/li>\n
  17. Step out of the func() function and re-run “mon leak_check”. Now valgrind will\u00a0report a memory leak. Note how the memory block allocated by the STL string is\u00a0not reported separately (it is\u00a0 shown as +1) as it is only referenced by the already reported block:
    \n    \"17-leak\"<\/a><\/li>\n<\/ol>\n
    VisualGDB also provides a convenient way to analyze your program performance using Valgrind.\u00a0See our Linux\u00a0Profiling Tutorial<\/a> for a detailed step-by-step guide.<\/p>\n","protected":false},"excerpt":{"rendered":"
    This tutorial shows how to find memory leaks in Linux programs using the VisualGDB integration with valgrind. Before you begin,<\/p>\n","protected":false},"author":1,"featured_media":0,"comment_status":"closed","ping_status":"closed","sticky":false,"template":"","format":"standard","meta":{"footnotes":""},"categories":[152],"tags":[33,109,153],"_links":{"self":[{"href":"https:\/\/visualgdb.com\/w\/wp-json\/wp\/v2\/posts\/3742"}],"collection":[{"href":"https:\/\/visualgdb.com\/w\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/visualgdb.com\/w\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/visualgdb.com\/w\/wp-json\/wp\/v2\/users\/1"}],"replies":[{"embeddable":true,"href":"https:\/\/visualgdb.com\/w\/wp-json\/wp\/v2\/comments?post=3742"}],"version-history":[{"count":1,"href":"https:\/\/visualgdb.com\/w\/wp-json\/wp\/v2\/posts\/3742\/revisions"}],"predecessor-version":[{"id":3760,"href":"https:\/\/visualgdb.com\/w\/wp-json\/wp\/v2\/posts\/3742\/revisions\/3760"}],"wp:attachment":[{"href":"https:\/\/visualgdb.com\/w\/wp-json\/wp\/v2\/media?parent=3742"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/visualgdb.com\/w\/wp-json\/wp\/v2\/categories?post=3742"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/visualgdb.com\/w\/wp-json\/wp\/v2\/tags?post=3742"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}