Memory leaks detection - Part II

In this post we will see how to relate the memory addresses with our source code to see in which line the memory leak is occurring. In the previous post, we saw some methods to detect memory leaks, of which we will take as a basis method 3 (which uses a program that fulfills the function of testnap and also leaves us a core file to analyze with mdb).

To develop this example, I used a file (fm_inv_pol_demo_leaks.c) with functions that cause memory leaks when using the macros and functions of the BRM API. This file is part of the fm_inv_pol.so library for testing purposes.

Memory leaks detection - Part I

Hello, today I am going to write how to detect memory leaks in our C / C ++ code of our BRM's fm libraries.

Many would have heard about Valgrind to detect memory leaks (among other functions it has), but unfortunately Valgrind does not work in Solaris SPARC, so we will have to use other tools when we work on a Solaris SPARC. In Oracle BRM documentation, Purify is mentioned, but since we have to pay a license, we are going to use something our OS already has so we don't have to pay for it.

To detect memory leaks (referred to * poid_t and * pin_flist_t) in the CM, the first thing we have to do is modify the CM's pin.conf adding this line:

- - disable_pcm_mempool 1

By adding that line in the CM's pin.conf we have disabled the memory pool that the CMs handle to process flist and poids, now the memory is allocated from the heap.