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).

Reutilizando código, linkeo de librerías

He visto en muchos proyectos que se hace copy/paste de código y se lo va desparramando a lo largo de distintas librerias/apps en vez de tener una función en una sola librería e invocar esa función desde otras librerías/apps en vez de andar copiándola y pegándola por todos lados.

Por ejemplo: una función para obtener el poid de la /account dado el PIN_FLD_ACCOUNT_NO, eso se usa mucho en casi todas las librerías custom del proyecto y por lo general se la ve la misma función en todos los módulos, entonces, por qué tenerla por todos lados y no solo en uno e invocarla desde el resto de las librerías?

Ésto a veces se hace porque los desarrolladores no se ponen de acuerdo al principio para tener una librería con funciones que se utilizarán en casi todos los módulos o porque a veces  no saben como invocar una función que está en otra librería.

IEL: primeros pasos. Parte 1

En este post vamos a ver como dar nuestros primeros pasos con el IEL - BRM Event Loader.

Para configurar el IEL tenemos 2 archivos:

1. iel.cfg:aquí se configura el IEL en sí.
2. pin.conf: aquí se configuran los parametrós de conexión a BRM.

El archivo iel.cfg tiene la siguiente estructura (familiar con la estructura de un XML):

Aplicación MTA utilizando un archivo como entrada

Generalmente cuando desarrollamos una aplicación en la cual utilizacmos el framework MTA de BRM lo hacemos definiendo un template de búsqueda (en la base de datos) en la función pin_mta_init_search.

También existe la posibilidad de que nuestra aplicación MTA tome como entrada un archivo de texto que contiene un flist y procese los objetos que están en dentro del archivo (tal como se puede hacer en el pin_bill_accts y/o pin_inv_accts).

Para procesar los objetos que están en el archivo, en el pin_mta_init_search solamente debemos indicar el nombre del archivo y la cantidad de campos que tiene cada PIN_FLD_RESULTS del flist.

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.

Secuencia de base de datos desde un opcode

A veces se necesita generar números consecutivos (por ejemplo números de factura electrónica) dentro de un opcode, para lo cual se pueden utilizar las secuencias de base de datos. Para esto solamente de debe utilizar el opcode PCM_OP_SEARCH y el resultado del search será en valor devuelto por la secuencia.

Sentencias SQL ejecutadas en BRM

A veces necesitamos ver las sentencias SQL que se generan cuando ejecutamos un opcode. El proceso para lograr esto es muy sencillo. En el ambiente donde se incia el dm_oracle hay que setear la variable de ambiente DM_DEBUG3 con el valor 0xFFFF003F, iniciar el dm_oracle y listo. Una vez seteada la variable e iniciado el dm_oracle en el archivo $PIN_HOME/var/dm_oracle/dm_oracle.log se pueden encontrar las sentencias SQL generadas por BRM.

CM y DM_ORACLE separados

A veces necesitamos probar una librería, ejecutar procesos o cambiar el nivel de log del CM y/o DM pero no podemos reiniciar BRM por alguna razón (puede ser un ambiente productivo o alguien mas está utilizando el ambiente), entonces lo que podemos hacer es tener un set de CMs/DMs con otra configuracion (ya sea q utilice otras librerias o solamente cambie el nivel de log). También podemos implementar esto mismo pero para que esos CMs solo sean utilizados por un proceso en particular, por ejemplo, el billing.

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.

Introducción al blog y presentación

El conocimiento es una de las pocas cosas que al compartirse se multiplica y en este pequeño blog voy a tratar de compartir mi conocimiento sobre Oracle BRM. Algunos de los temas que tengo en mente para ir subiendo al blog son:

• Detección de memory leaks.
• Ambiente de desarrollo.
• Tips de programación.
• Tips de BRM.
• Detección de core dumps.
• Herramientas útiles a la hora de desarrollar.
• Scripts para automatizar procesos.

Mi nombre es Martín Falconi, tengo 6 años de experiencia en BRM (para más información sobre mi carrera laboral pueden visitar mi perfil en Linkedin)

#include <stdio.h>

int main()
{
    printf("Bienvenidos al blog");
    return 0;
}

Buen viajeeeeeeeeeee