After we have gathered the results the Intel Inspector gives us a summary page showing the memory related problems with our demo app. We discuss what these problem messages mean and how to interpret them. We discuss right clicking and viewing the exact line in the source code where a memory issue resides. We then see how the Intel Inspector even offers suggestions on how to fix the issues at hand.
- [Instructor] Once the results are done being finalized, in the Collection Log, we can see the memory consumption continuously increasing in a staircase-like manner. This points towards memory leak errors. If we click on the Summary tab, we are taken to the results, which shows memory leak errors. Let's discuss this window a bit. One is the starting point for looking at the results. It groups problems into different sets and then prioritizes the sets by severity and size. Two is the Problems pane to-do list.
Here is where Intel Inspector tells us the memory issues plaguing our demo application, and where we will see memory leak errors. Three will show us the exact source code line where a memory leak error is occurring. Now, switching back to the Intel Inspector results inside Visual Studio, we can see memory leak issues being reported. Let's click on this memory leak issue, and we can see the exact source code line by clicking on this plus button to the left. It shows that this memory leak is occurring at line 84 in main.cpp, and we can see the exact source code line here, in the bottom window.
And it seems to be occurring at this cvLoadImage function call. From what we discussed previously, this code line is loading a bitmap image into memory and returning a pointer. What is happening here is that this cvLoadImage function tries to load a bitmap file into memory, but there's no more memory available. This line right here is causing a memory leak because the memory being allocated by this function is not being released once it is done being used. Since the application cycles through many images and blends each image with the train tracks image, once an image has been blended with the train tracks, the image is no longer needed for any further operations, which means we can release the memory that is being consumed to hold that image.
If we only need to consume memory to hold a bitmap image for the time we are doing operations with it, such as blending, then we can release the memory it is using once it is done being blended. Wherever we see an image being loaded into memory through this cvLoadImage call, we need to see a corresponding release call to release the memory that is no longer being used by an image. We can get to the source code by right-clicking on the memory leak and selecting Edit Source. This will take us to the source code in Visual Studio.
If I scroll up, we can see this SAFE_RELEASE. This SAFE_RELEASE will make a call to cvReleaseImage only if that image still exists in memory, and then it resets the pointer. So, we need to match this SAFE_RELEASE so that it corresponds with the cvLoadImage function call. This is how we release memory that is no longer needed, and how we fix the memory leak issues.
- Installing Intel Inspector XE
- Setting up OpenCV
- Detecting memory leaks
- Visualizing memory usage growth
- Conducting memory leak analysis
- Fixing memory leaks in source code