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.

Detección de memory leaks - Parte IV (MTA)

En la entrada anterior (III) vimos como detectar memory leaks utilizando discover en una aplicación que ha sido desarrollada utilizando el framework MTA de BRM. Ahora veremos como hacerlo con otra herramienta: dbx (ésto también sirve para apliaciones que no han sido desarrolladas utilizando MTA, pero el post está orientado a este tipo de aplicaciones).

Detección de memory leaks - Parte III (MTA)

En las entradas anteriores (I y II) vimos como detectar memory leaks en una librería fm, ahora veremos como detectarlas dentro de una aplicación que ha sido desarrollada utilizando el framework MTA de BRM (ésto también sirve para apliaciones que no han sido desarrolladas utilizando MTA, pero el post está orientado a este tipo de aplicaciones).

Para ello utilizaremos otra herramienta: discover.

Detección de memory leaks - Parte II

En este post vamos a ver como relacionar las direcciones de memoria con nuestro código fuente para ver en qué línea se está produciendo el memory leak. En el post anterior se mostraron algunos métodos para detectar memory leaks, de los cuales vamos a tomar como base el método 3 (el que usa un programa que cumpliría la función del testnap y además nos deja un archivo core para analizar con mdb).

Read this post in english.

Para desarrollar este ejemplo se utilizará un archivo (fm_inv_pol_demo_leaks.c) con funciones que produzcan memory leaks al utilizar las macros y funciones del api de BRM. Este archivo fomará parte de la librería fm_inv_pol.so para poder realizar las pruebas.

Detección de memory leaks - Parte I

Hola, hoy voy a escribir como detectar memory leaks (fugas de memoria) en nuestro codigo C/C++ de nuestras librerias fm de BRM.

Read this post in english.

Muchos habrán oido sobre Valgrind para detectar memory leaks (entre otras funciones que posee), pero lamentablemente Valgrind aún no funciona en Solaris SPARC, por lo cual vamos a tener que usar otras herramientas cuando estemos trabajando en un Solaris SPARC. En la documentación de Oracle BRM se menciona Purify pero como hay que pagar licencia vamos a utilizar algo que ya poseea nuestro SO y no tengamos que pagar.

Para detectar memory leaks (referidos a *poid_t y *pin_flist_t) en el CM, lo primero que tenemos que hacer es modificar el pin.conf del CM agregando esta línea:

- - disable_pcm_mempool 1

Al agregar esa linea en el pin.conf del CM hemos deshabilitado el pool de memoria que manejan los CMs para procesar flist y poids, ahora la memoria se asigna desde el heap del sistema.