A linguagem utilizada é simples, e apesar de manter certa ordem de apresentação do conteúdo, você não precisa ler na ordem apresentada. Alguns artigos, que foram escritos na década de 90, estão um pouco defasados, mas no geral é um livro que vale a pena pelo menos dar uma olhada em alguns capítulos, que são bem interessantes.

O capítulo 1 apresenta uma introdução à sistemas embarcados e sua evolução durante os últimos 30 anos, falando sobre memória, arquitetura de CPUs e seu processo de seleção, além de dois artigos bem interessantes sobre a interface USB. O capítulo 2 é sobre design de sistemas embarcados, abrangendo tópicos como UML e Eclipse. 

Os capítulos 3, 4 e 5 são inteiramente voltados ao desenvolvimento de software embarcado em C e C++, com algumas dicas valiosas principalmente para quem está começando na área. Os capítulos 6 e 7 também são bem interessantes, discutindo tópicos relacionados à sistemas de tempo real. Os dois últimos capítulos falam sobre protocolos de rede e FPGAs.

O site do livro é este aqui, e quem se interessar pode dar uma folheada no Google Books. Vale a pena também acompanhar o The Colin Walls Blog.

Um abraço!

Sergio Prado

Posts relacionados:

1. Misra-C — Padrão para software em C
2. Como se tornar um desenvolvedor de software embarcado

Vamos agora colocar a mão na massa. Nosso objetivo aqui é carregar na flash NAND o bootloader U-Boot, bastante usado em sistemas embarcados, e depois fazê-lo carregar uma imagem do Emdebian, uma versão do Debian mais leve.

O único pré-requisito é um kit FriendlyARM mini2440 conectado à uma máquina Linux pela serial (para acessar a console), pela USB (para transferir a imagem do U-boot) e por um cabo de rede (para carregar as imagens do kernel e do rootfs do Emdebian).

Usei o binário do U-boot deste link aqui. O kernel eu baixei daqui, mas precisei customizá-lo para habilitar o suporte à sistema de arquivos JFFS2 e corrigir o mapeamento das partições da MTD no driver da Flash. O rootfs eu peguei aqui, mas também precisei “dar um tapa”, e corrigir um problema que impedia de subir o terminal pela console RS232.

Para facilitar o trabalho daqueles que irão executar este passo-a-passo, criei um “pacote especial” com todas as ferramentas e imagens necessárias para dar vida ao Emdebian no mini2440. Este pacote pode ser baixado aqui. Descompacte-o para sua máquina e mãos à obra!

Bootloader U-Boot

O bootloader é uma aplicação que é carregada e executada assim que o hardware é ligado. No universo desktop, estamos familiarizados com o LILO ou o GRUB para carregar sistemas Unix-like, mas no universo embedded as coisas são um pouco mais complicadas. Um bootloader para sistemas embarcados possui 3 principais responsabilidades:

1. Inicializar o hardware.
2. Possibilitar a carga e gravação da aplicação na flash via alguma interface de I/O, como porta serial, USB ou interface de rede.
3. Carregar e executar aplicações da RAM.

Um bootloader bem conhecido no universo embedded é o Das U-Boot, também conhecido apenas como U-Boot, um bootloader multi-plataforma e open-source, com suporte à diversas arquiteturas como PowerPC, ARM, MIPS, Coldfire e x86. A página do projeto pode ser acessada aqui.

O U-Boot será o bootloader que utilizaremos para carregar o Emdebian pela NAND. O processo para carregar e gravar o U-Boot na flash é simples.

Primeiro iremos carregar a imagem do U-Boot na RAM. Para isso precisaremos da imagem do U-Boot (“u-boot-256M.bin” ou “u-boot-128M.bin”, dependendo do seu kit), e da ferramenta “usbpush”. Todos os arquivos encontram-se no link que passei no início deste post. Não esqueça também que a serial e a USB devem estar conectadas.

Inicie o kit pela NOR, no menu do supervivi selecione a opção “q” e prepare-o para receber a imagem do U-Boot e salvar em RAM:

[q] Goto shell of vivi
Enter your selection: q
Supervivi> load ram 0x31000000 242360 u

Obs: O parâmetro “242360” deve ser o tamanho em bytes da imagem do U-Boot (“u-boot-256M.bin” para a flash de 256M no meu caso).

Então, em um shell do Linux, digite o comando abaixo:

$ sudo ./usbpush u-boot-256M.bin

A console irá exibir uma mensagem indicando que a transferência foi realizada com sucesso.

Agora iremos executar o U-Boot da RAM mesmo, assim podemos formatar a NAND e depois copiar o U-Boot para lá.

Digite então na console do mini2440:

Supervivi> go 0x31000000

Após algumas mensagens, irá aparecer o shell do U-Boot. Agora vamos formatar a flash. A execução dos comandos abaixo podem demorar um pouco, portanto tenha paciência :)

MINI2440 # nand scrub
....
MINI2440 # nand createbbt
....

Depois é só escrever o U-Boot na flash Nand.

MINI2440 # nand write.e 0x31000000 0 242360

Obs: Não se esqueça de que novamente o parâmetro “242360” deve ser o tamanho em bytes da imagem do U-Boot.

Muito bem. Você acabou de instalar o U-Boot na sua flash NAND. Desligue a placa, mude a chave para bootar pela NAND para a console cair no shell do U-Boot.

Este bootloader tem bastante recursos. O comando “help” vai exibir uma lista. Podemos por exemplo listar informações da placa ou das partições da flash, conforme abaixo:

MINI2440 # bdinfo
arch_number = 0x000007CF
env_t       = 0x00000000
boot_params = 0x30000100
DRAM bank   = 0x00000000
-> start    = 0x30000000
-> size     = 0x04000000
ethaddr     = 08:08:11:18:12:27
ip_addr     = 10.0.0.111
baudrate    = 115200 bps
 
MINI2440 # mtdparts 
device nand0 <mini2440-nand>, # parts = 4
 #: name                size            offset          mask_flags
 0: u-boot              0x00040000      0x00000000      0
 1: env                 0x00020000      0x00040000      0
 2: kernel              0x00500000      0x00060000      0
 3: root                0x0faa0000      0x00560000      0
active partition: nand0,0 - (u-boot) 0x00040000 @ 0x00000000
</mini2440-nand>

Podemos carregar uma aplicação via serial com os comandos “loadb”, “loads” e “loady”, via NFS com o comando “nfs”, via TFTP com o comando “tftpboot” ou via USB com o comando “usbboot”. Podemos também testar a RAM com os comandos “mtest” e “mw”.

Carregando o Emdebian

O Emdebian é uma versão do Debian para sistemas embarcados. Mantém as principais características do Debian, como sistema de gerenciamento de pacotes, sistema de licenças e portabilidade entre diversas plataformas. O sistema de build é customizado para trabalhar com pacotes pequenos e gerar distribuições bem mais leves. A página do projeto pode ser acessada aqui.

A carga do kernel (“uImage”) e do rootfs (“emdebian-jffs2.img”) é feita através de uma conexão de rede. Ligue seu PC com o mini2440 através de um cabo de rede, configure o endereço IP do seu PC com 10.0.0.1, e o do kit com 10.0.0.2. Configure o mini2440 através dos comandos abaixo na console do U-Boot:

MINI2440 # dynenv set 40000
MINI2440 # setenv ipaddr 10.0.0.2
MINI2440 # setenv serverip 10.0.0.1
MINI2440 # saveenv

Use o comando “ping 10.0.0.1″ na console do U-Boot para verificar se a conexão com o PC está funcionando corretamente.

Vamos agora gravar o kernel. O processo consiste em carregar a imagem do kernel para a RAM, e então de lá gravar na flash:

MINI2440 # tftp 0x31000000 uImage
MINI2440 # nand erase kernel
MINI2440 # nand write.e 0x31000000 kernel 0x205f58

Para o rootfs, o processo é idêntico:

MINI2440 # tftp 0x31000000 emdebian-jffs2.img
MINI2440 # nand erase root 
MINI2440 # nand write.e 0x31000000 root 0x23e0000

Agora só falta setar as variáveis de ambiente do U-Boot para iniciar o kernel do Linux corretamente:

MINI2440 # setenv bootcmd nboot.e kernel ; bootm
MINI2440 # setenv bootargs root=/dev/mtdblock3 rootfstype=jffs2 console=ttySAC0,115200
MINI2440 # saveenv
MINI2440 # boot

Pronto! O Emdebian já está rodando no nosso kit mini2440:

Posts relacionados:

1. Mini2440 — Memory layout e bootloader
2. Kit de desenvolvimento FriendlyARM mini2440
3. Vídeo: Introdução ao Linux Embarcado

Minhas impressões iniciais são muito boas. Ele é possivelmente um dos melhores kits existentes (que conheço) para se aprender sobre Linux embarcado, por ser um hardware robusto, pelas ferramentas existentes e pela relação custo/benefício.

Vamos ver então com um pouco mais de detalhes a arquitetura da CPU, o layout de memória e o bootloader que vem instalado de fábrica.

CPU E O LAYOUT DE MEMÓRIA

O kit, com todas as suas interfaces de I/O e memória, pode ser visto na figura abaixo:

A CPU é um Samsung S3C2440 baseado no core ARM920T, RISC, arquitetura Harvard e voltado para aplicações de baixo consumo. O datasheet pode ser baixado aqui.

Tem capacidade de endereçamento de até 1GB, sendo 8 bancos de memória de 128M selecionáveis através de 8 chip select's (nGCS0...nGCS7).

A memória RAM de 64MB (2 x 32MB) está mapeada para o endereço físico 0x30000000 através do nGCS6.

Existem duas memórias de programa neste kit, o que acaba sendo um diferencial perante outros kits ARM voltados para aprendizado. O kit possui 2MB de memória flash do tipo NOR e 64MB de memória flash do tipo NAND.

Para quem não conhece, vale aqui uma explicação sobre as diferenças entre estes dois tipos de memória.

Ambas foram inventadas na década de 80 pela Toshiba. As primeiras memórias NOR foram vendidas pela Intel em 88. Com tempo de resposta para apagar e escrever muito grande, mas com a possibilidade de acesso à leitura em qualquer posição de memória, foi uma aplicação ideal para memórias do tipo ROM, para armazenar programas que dificilmente são alterados, como a BIOS de PCs  e firmware de equipamentos eletrônicos.

Já as memórias do tipo NAND possui um tempo de escrita bem menor, e uma maior densidade, ou seja, mais MB de dados pelo mesmo espaço se comparados com as memórias NOR. Por outro lado, não é possível acesso de leitura à qualquer posição de memória. A leitura e gravação é feita por blocos de memória (4kB por exemplo). Isso dá a ela a aplicação ideal para armazenamento de dados. Quando usada como memória de programa, é necessário ter um bootloader que carrega seu conteúdo em memória RAM para ser executado.

O kit mini2440 consegue fazer o boot pelas duas memórias através de uma chave (NAND <-> NOR) no canto inferior direito da imagem acima.

Ao fazer o boot pela NAND, a CPU possui uma região especial chamada de "Boot internal SRAM", onde são carregados e executados os primeiros 4KB da NAND. Estes primeiros 4K de programa serão os responsáveis por carregar o resto do programa da NAND para a RAM, e rodar a aplicação a partir de lá.

Ao fazer o boot pela NOR, é carregado o bootloader Supervivi, que vêm instalado de fábrica. Ele é baseado no bootloader open source vivi da Samsung. Vamos dar uma olhada nele com mais detalhes.

BOOTLOADER SUPERVIVI

Para acessar o bootloader ligue os cabos RS323 e USB e deixe a chave de seleção de memória na posição NOR. Você pode usar qualquer aplicação para consoles como o HyperTerminal para Windows ou o minicom para Linux. Este é o menu inicial do bootloader Supervivi:

A opção "q" oferece um shell para o bootloader e as outras opções automatizam determinada tarefa.

Apesar da manipulação do bootloader ser pela console (porta serial), a transferência de arquivos é pela USB. Você vai precisar de uma aplicação adicional para transferir arquivos e imagens: DNW for Windows ou Usb-push for Linux. Nos nossos exemplos usaremos um PC com Linux, mas os procedimentos com Windows são similares, e mais informações podem ser encontradas no manual de usuário do kit aqui.

CARREGANDO UMA APLICAÇÃO STANDALONE

Para carregar uma aplicação standalone na flash NAND, basta usar a opção "a". Esta aplicação standalone pode ser qualquer binário pronto para execução. Pode ser uma simples aplicação para piscar leds ou uma aplicação mais completa com RTOS. Vamos carregar aqui o binário "myled.bin" na flash, que vem como exemplo junto com o kit:

Primeiro devemos preparar o bootloader para carregar o arquivo com a opção "a":

[a] Absolute User Application
Enter your selection: a
USB host is connected. Waiting a download.

Depois devemos disparar a transferência com a aplicação usb-push:

$ sudo ./usbpush /media/cdrom0/sample\ code\ without\ OS/myled.bin
csum = 0x83c6
send_file: addr = 0x30000000, len = 0x0000084c

O bootloader vai exibir o status da transferência:

Now, Downloading [ADDRESS:30000000h,TOTAL:2134]
RECEIVED FILE SIZE:    2134 (2KB/S, 1S)
Downloaded file at 0x30000000, size = 2124 bytes
Write to flash ok: skipped size = 0x0, size = 0x84c

Supervivi> part show
Number of partitions: 4
name            :       offset          size            flag
------------------------------------------------------------
vivi            :       0x00000000      0x00040000      0
param           :       0x00040000      0x00020000      0
kernel          :       0x00060000      0x00500000      0
root            :       0x00560000      0x3fa80000      0

Posts relacionados:

1. Kit de desenvolvimento FriendlyARM mini2440
2. Mini2440 — Linux com U-Boot e Emdebian
3. Memory leak em linguagem C

Muita coisa aconteceu por lá, em áreas tão diversas como mobile, servidores e sistemas embarcados.

A Linux Foundation divulgou um programa, chamado de “Open Compliance Program”, cujo intuito é ajudar as empresas a disponibilizar os códigos-fonte utilizados sob licenças open-source, como a GPL. Segundo a Linux Foundation, muitas empresas não divulgam seu código-fonte por falta de conhecimento dos aspectos legais ou operacionais. A Linux Foundation irá disponibilizar ferramentas, manuais, cursos e modelos de documento para que as empresas evitem o desrespeito às licenças de software livre.

Sabendo da importância que o Linux vem assumindo nos últimos anos em sistemas embarcados e dispositivos móveis, a Qualcomm Inovation Center, uma subsidiária da Qualcomm, fabricante de chips para celulares, tornou-se um membro Platinum da Linux Foundation. Isso significa um melhor suporte e avanço do Linux no mercado mobile.

No keynote da Novell, no segundo dia do evento, falou-se bastante sobre a evolução da computação em nuvem, balanceamento de carga em servidores Linux e virtualização. 

Foi divulgada também uma pesquisa realizada Forrester Research, sobre a utilização do Linux como host entre desenvolvedores de software, e o resultado mostrou um crescimento do Linux nos últimos 3 anos:

Falou-se também da plataforma Meego, junção dos projetos Moblin da Intel e Maemo da Nokia, baseado na arquitetura Atom da Intel.

Pelo que li em sites e blogs de tecnologia, o grande foco este ano foi a importância do software livre e aberto, e do crescimento da plataforma Linux no mercado mobile.

Nos dias 31/08 e 01/09, em São Paulo, vai acontecer a Linuxcon Brasil. Palestrantes de nome estarão por lá, como Linus Torvalds (criador do Linux), Jim Zelim (diretor da Linux Foundation) e Jane Silber (CEO da Canonical), além do inusitado Jon “maddog” Hall, que sempre esta em todos os eventos de Linux.

Eu estarei lá para ouvir o que o pessoal tem a dizer sobre o futuro do Linux, principalmente no mercado embedded. Se você quiser participar, a página do evento pode ser acessada aqui, e o ingresso para o evento pode ser comprado no site da Linux Magazine.

Um abraço,

Sergio Prado

Posts relacionados:

1. Kernel Linux 2.6.35
2. Seminário Programação C/C++ para Sistemas Embarcados 2009
3. Meld 2.0 para desenvolvedores de linux embarcado

A primeira versão havia sido lançada em 2009, e sofreu várias alterações, principalmente na interface.

Apesar de ser patrocinado pela MontaVista, o site é voltado para qualquer tópico relacionado à sistemas embarcados com Linux, incluindo desenvolvimento com Android, customização do Linux, gerenciamento de memória e I/O, multi-core, etc.

Muito bom para solucionar problemas, ajudar outros desenvolvedores e fazer networking.

O novo site pode ser acessado em meld.org.

Um abraço,

Sergio Prado

Posts relacionados:

1. Vídeo: Introdução ao Linux Embarcado
2. Kernel Linux 2.6.35
3. Como se tornar um desenvolvedor de software embarcado

O kit tem uma CPU de 32bits rodando a 100MHz, 2MB de Flash e 128KB de RAM, gravação e debugging pela USB, matriz de leds, potenciômetro, joystick de quatro direções, etc. A Renesas criou uma página no site de sua comunidade online para este kit com bastante documentação e software de exemplos para a utilização do kit, além de um vídeo demonstrando seu funcionamento:

Se você quiser participar e receber um kit gratuitamente, basta fazer um cadastro no site da Renesas aqui.

Atualização: Infelizmente a Renesas não pode atender toda a demanda, e a promoção está cancelada.

Um abraço,

Sergio Prado

Posts relacionados:

1. Mini2440 — Memory layout e bootloader
2. Kit de desenvolvimento FriendlyARM mini2440
3. Nova ferramenta para debug de consumo de energia

No total (valor do kit + frete + impostos) o kit saiu em torno de R$360,00. Valor bem mais barato do que se adquirisse por aqui, ou se comprasse um kit ARM similar.

E realmente este kit tem algumas caracteristicas interessantes. A começar pelo tamanho, de 10cm x 10cm. Veja uma foto com a placa do lado do meu Nokia E71:

Além da placa o kit acompanha um display touch screen de 3,5 polegadas e alguns cabos (serial, JTAG, USB, Ethernet), e vem pre-carregado com uma imagem rodando Linux e Qtopia. Veja abaixo o kit montado e rodando:

Suas configurações são impressionantes: CPU ARM9 da Samsung de 400MHz (S3C2440A), 64M de SDRAM, 64M de Nand Flash e 2M de NOR Flash, além de várias interfaces incluindo serial RS232, USB, Ethernet, Cartão SD e JTAG.

Já vem com um bootloader que possibilita carregar a aplicação via USB, e é compatível com os sistemas operacionais Windows CE, GNU/Linux e Android.

Este kit será, durante as próximas semanas, a plataforma que utilizarei para me aprofundar em ARM e linux embarcado, e especialmente no sistema operacional Android do Google.

Alguns posts interessantes sobre este kit estão por vir. Aguardem!

Um abraço,

Sergio Prado

Posts relacionados:

1. Mini2440 — Memory layout e bootloader
2. Mini2440 — Linux com U-Boot e Emdebian
3. Wind River apostando na plataforma Android

Uma das principais alterações é uma tecnologia desenvolvida pelo Google para o tratamento de pacotes de rede entre várias CPUs. Essa tecnologia é dividida em duas técnicas chamadas de RPS (Receive Packet Steering) e RFS (Receive Flow Steering), e consegue quase triplicar a performance da rede. Uma explicação sobre seu funcionamento pode ser lida aqui.

Esta nova versão também tem melhorias no sistema de arquivos Btrfs, considerado como o sucessor do Ext4, um frontend para o KDB (debugger do Kernel), um novo mecanismo de desfragmentação de memória e muitas outras alterações em drivers e correções de bugs.

Uma descrição mais completa das alterações pode ser lida aqui.

Um abraço,

Sergio Prado

Posts relacionados:

1. Meld 2.0 para desenvolvedores de linux embarcado
2. Mini2440 — Linux com U-Boot e Emdebian
3. Vídeo: Introdução ao Linux Embarcado

A biblioteca C padrão fornece as funções malloc() para alocar memória dinamicamente e free() para desalocar uma região de memória previamente alocada.

1
2

void *malloc(size_t size);
void free(void *ptr);

Estas rotinas usam uma região de memória chamada de heap. É no heap que os bytes são alocados com malloc() e liberados com free(). O tamanho do heap é variável, dependendo de vários fatores como o tamanho da memória, capacidade de endereçamento da CPU, etc. Mas claramente é uma região de memória finita. A cada chamada a malloc(), uma pequena parte desta região de memória é consumida. E se não for liberada, corremos o risco de ficar sem memória.

O uso de malloc() e free() de maneira descontrolada pode causar dois principais problemas:

1. Fragmentação de memória: A cada malloc(), um pedaço de memória é alocado, e fica indisponível para a aplicação. Se o software abusar das chamadas a malloc(), a memória poderá ficar fragmentada em pequenos pedaços alocados para a aplicação. Depois as rotinas de alocação terão dificuldades de encontrar "pedaços" de memória que atendem às novas chamadas à malloc(). A forma como ocorre esta fragmentação é dependente da biblioteca ou do sistema operacional responsável pela alocação de memória.
2. Memory leak: Se você alocar regiões de memória com malloc(), mas depois do uso não liberar estas regiões com o free(), temos caracterizado o memory leak, um dos principais pesadelos do desenvolvedor de software embarcado. É um pesadelo porque a memoria começa a ser consumida aos poucos, e a aplicação pode ficar dias sem apresentar algum problema. Mas então num belo dia, quando toda a memória é consumida, coisas estranhas começam a acontecer. A performance da aplicação começa a se degradar, e travamentos ou reboot automaticos irão invariavelmente acontecer.

Nosso foco neste artigo é o memory leak. Vamos analisar então algumas técnicas para tratar e identificar este problema.

Técnica 0: Não usar malloc()

Usar alocação dinamica de memória em sistemas embarcados deve ser seu ultimo recurso. Padrões como o MISRA-C, que tratei em um artigo passado, proibem categoricamente seu uso. Portanto pensem bastante na solução. Depois pensem de novo. E de novo. Até ter certeza de que alocação dinâmica de memória é a única solução para seu problema.

Técnica 1: Code review

Então você usou alocação dinâmica de memória em seu código, e agora precisa garantir a ausência de memory leak na aplicação. E uma das primeiras técnicas a serem aplicadas é o Code Review, ou revisão de código.

A técnica de revisão de código deveria ser aplicada independentemente do uso de malloc(). Nós devemos revisar nossos códigos. E então devemos pedir para outras pessoas revisá-los. E depois revisar o código de outras pessoas. Uma boa parte dos bugs podem ser encontrados com esta técnica.

A idéia aqui é ler o código, identificar todas as chamadas à malloc(), e verificar se existe o free() correspondente. Dê uma olhada na função abaixo:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28

int txData(char *data)
{
    unsigned char *ptr = NULL, *buf = NULL;
    int size = strlen(data);
 
    /* allocate buffer */
    if ((ptr = buf = (unsigned char*)malloc(size + 3)) == NULL)
        return(-1);
 
    /* STX */
    *ptr++ = STX;
 
    /* data */
    strncpy(ptr, data, size);
    ptr += size;
 
    /* ETX */
    *ptr++ = ETX;
 
    /* send data */
    if (txSerial(buf, size + 3) == -1)
        return(-2);
 
    /* free buffer */
    free(buf);
 
    return 0;
}

Temos aqui um exemplo clássico de memory leak. Esta função recebe uma string, formata em um buffer, e envia pela serial. Como o tamanho da string é variável, o buffer de comunicação é alocado dinamicamente. Veja que na linha 7 o buffer é alocado, e na linha 25 o buffer é liberado. Porém, quando ocorre um erro ao enviar os dados (linha 21), a função retorna sem desalocar o buffer, caracterizando o memory leak. Este erro é muito comum. Quando usamos malloc() devemos nos certificar de que todos os pontos de retorno da função possuem uma chamada a free().

Esta técnica pode ser muito custosa para aplicações com milhares de linhas de código, e isso nos leva ao uso de ferramentas para automatizar esta verificação.

Técnica 2: Uso de ferramentas

Ferramentas são uma parte essencial do processo de desenvolvimento, e não será diferente quando nosso objetivo é analisar um problema de memory leak. Existem vários tipos de ferramentas, algumas que fazem análise estática de código (analisa diretamente o código-fonte) e outras que fazem verificação dinâmica (em tempo de execução).

Para testar algumas ferramentas, vamos complementar a função txData() com uma função main(), e forçar um memory leak. Nosso código final ficou assim:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52

/* leak.c */
#include "stdio.h"
#include "string.h"
#include "malloc.h"
 
#define STX 0x02
#define ETX 0x03
 
int txSerial(unsigned char *buffer, int size)
{
    return -1;
}
 
 
int txData(char *data)
{
    unsigned char *ptr = NULL, *buf = NULL;
    int size = strlen(data);
 
    /* allocate buffer */
    if ((ptr = buf = (unsigned char*)malloc(size + 3)) == NULL)
        return(-1);
 
    /* STX */
    *ptr++ = STX;
 
    /* data */
    strncpy(ptr, data, size);
    ptr += size;
 
    /* ETX */
    *ptr++ = ETX;
 
    /* send data */
    if (txSerial(buf, size + 3) == -1)
        return(-2);
 
    /* free buffer */
    free(buf);
 
    return 0;
}
 
void main()
{
    char *msg = "MemoryLeak";
 
    if (!txData(msg))
        printf("Mensagem enviada com sucesso!\n");
    else
        printf("Erro ao enviar mensagem!\n");
}

Primeiro vamos testar com uma ferramenta de analise estática de código, o SPLINT, já tratado anteriormente no meu artigo aqui.

$ splint leak.c
Splint 3.1.2 --- 03 May 2009
....
leak.c:37:20: Owned storage ptr not released before return
  A memory leak has been detected. Only-qualified storage is not released
  before the last reference to it is lost. (Use -mustfreeonly to inhibit
  warning)
   leak.c:22:10: Storage ptr becomes owned
....

Voilá! A ferramenta encontrou facilmente o memory leak que inserimos no código. O interessante de uma ferramenta de análise estática é que, como a analisa é feita nos fontes da aplicação, ela pode ser usada em qualquer código-fonte, independente da arquitetura ou do sistema operacional que estamos usando, desde que esteja no padrão ANSI C.

Já o uso de ferramentas de análise dinâmica podem pegar casos específicos que passariam despercebidos quando usamos ferramentas de análise estática. Por outro lado, estas ferramentas são dependentes de determinado sistema operacional, ou então exigem que você compile seu código com uma biblioteca específica. Isso porque estas ferramentas adicionam uma camada extra na sua aplicação, monitorando cada chamada a malloc() e free(), para depois gerar um relatório que pode indicar um memory leak quando a quantidade de chamadas a malloc() for diferente da quantidade de chamadas a free() por exemplo.

Uma destas ferramentas, muito utilizada para detectar memory leak em aplicações para sistemas Unix, é o Valgring. Esta ferramenta de debug, dentre outras funcionalidades, monitora o uso de memória pela aplicação em tempo de execução. Vamos testar o comportamento desta ferramenta com a nossa aplicação.

$ valgrind ./leak
==3811== Memcheck, a memory error detector
==3811== Copyright (C) 2002-2009, and GNU GPL, by Julian Seward et al.
==3811== Using Valgrind-3.6.0.SVN-Debian and LibVEX; rerun with -h for copyright info
==3811== Command: ./leak
==3811== 
Erro ao enviar mensagem!
==3811== 
==3811== HEAP SUMMARY:
==3811==     in use at exit: 13 bytes in 1 blocks
==3811==   total heap usage: 1 allocs, 0 frees, 13 bytes allocated
==3811== 
==3811== LEAK SUMMARY:
==3811==    definitely lost: 13 bytes in 1 blocks
==3811==    indirectly lost: 0 bytes in 0 blocks
==3811==      possibly lost: 0 bytes in 0 blocks
==3811==    still reachable: 0 bytes in 0 blocks
==3811==         suppressed: 0 bytes in 0 blocks
==3811== Rerun with --leak-check=full to see details of leaked memory
==3811== 
==3811== For counts of detected and suppressed errors, rerun with: -v
==3811== ERROR SUMMARY: 0 errors from 0 contexts (suppressed: 13 from 8)

Veja que após executar a aplicação ela imprime um relatório do uso de memória, indicando a ocorrencia do memory leak.

Se você quiser, dê uma olhada também na biblioteca dmalloc. Ela adiciona uma camada adicional na sua aplicação, possibilitando o debug de alocação de memória em tempo de execução. Esta biblioteca foi escrita em ANSI C e pode ser facilmente portada para qualquer arquitetura.

Técnica 3: Desenvolva sua própria biblioteca

Se nenhuma solução disponível lhe servir, sempre existe a possibilidade de você colocar a mão na massa e desenvolver suas próprias rotinas de alocação de memória. Reinventar a roda é sempre mais trabalhoso e custoso, mas se você se sentir aventureiro, pode analisar esta possibilidade. Dê uma olhada neste artigo aqui.

Normalmente, só damos atenção a um problema quando o vivenciamos. Sempre achamos que não vai acontecer conosco. E quando acontece, temos que lidar com as consequencias e aprender com os erros. Mas melhor do que aprender com seus próprios erros, é aprender com os erros dos outros. Portanto, seja mais proativo. memory leak é igual a pressão alta, uma doença silenciosa, mas que quando apresenta os sintomas, estes provavelmente serão fatais!

Um abraço,

Sergio Prado

Posts relacionados:

1. Tratamento de erros em Linguagem C
2. Otimização de código em Linguagem C — Parte 2
3. Otimização de código em Linguagem C — Parte 1

A Microsoft segue o mesmo caminho da Apple, que licenciou a arquitetura ARM para produzir seus chips A4 para o iPad e o iPhone4.

Muito têm-se especulado sobre qual o objetivo da Microsoft ao licenciar a arquitetura ARM. Podem ser produtos voltados ao mercado de consumo como smartphones, netbooks e tablets, usando aí seu novo SO, o Windows Phone 7.

Ou então especula-se também a utilização de chips ARM nos servidores que rodam o sistema de buscas da Microsoft, o Bing, principalmente porque ela divulgou recentemente uma posição aberta para um engenheiro de software com experiencia em ARM para atuar em seus Data Centers.

É esperar para ver.

O press release do acordo pode ser lido aqui.

Um abraço,

Sergio Prado

Posts relacionados:

1. Linuxcon 2010
2. Open Source Hardware
3. Seminário Programação C/C++ para Sistemas Embarcados 2009