dos erros nesse modulo era gerar um erro de read ao tentar acessar memoria um byte alem do tamanho do buffer passado como parametro, o classico off-by-one. Por sorte, o modulo utilizava N chars, embora tentasse acessar o N+1, por esse acaso o resultado do calculo que ele realizava retornava correto. Por preguica, todos os pontos do sistema que utilizavam essa biblioteca sempre alocavam um byte a mais do que o necessario, evitando que o debugger reclamasse. Mas, IMHO, independente de o erro ser algo serio e que acontece sempre ou so uma anotacao na lista de bugs do debugger que aparentemente nunca causou nenhum problema, voce nao deve ser barato e se contentar com codigo mal escrito. Tem erro? conserte! Mas, como? Bem, vamos analisar o mesmo problema usando o seguinte programa exemplo (Neste caso o codigo falha praticamente sempre, pois quero um erro que ninguem diria: ah, mas o resultado volta correto, deixa como esta!):#include <stdio.h>#include <stdlib.h>#include "broken_lib.h"int main(){ int value; int * data; data = (int *) malloc(sizeof(int) * 10); data[0] = 1; data[1] = 2; data[2] = 3; data[3] = 4; data[4] = 5; data[5] = 6; data[6] = 7; data[7] = 8; data[8] = 9; data[9] = 0; value = compute_some_stuff(data, 10); printf("[%d]\n",value); free(data); return 0;}#############################################################################O header broken_lib.h:$ cat broken_lib.h#pragma once /* essa funcao deve somar todos os valores do buffer input_data que tem tamanho data_len e retornar o resultado, se algum dos valores do buffer for impar, antes de somar ela zera o bit 0, tornando este valor par */int compute_some_stuff(int * input_data, int data_len);#############################################################################O fonte correspondente broken_lib.c, como ja foi informado, esta perdido no limbo. tudo o que temos e uma lib estatica:$ ls *.alibbroken.aQuando executado, essa e a saida do programa:$ ./main_prog [135160]Ops... Levando em conta a documentacao da funcao, deveriamos esperar o valor 40:BUFFER ORIGINAL EM DECIMAL: 1+2+3+4+5+6+7+8+9+0EM BINARIO: 0001 + 0010 + 0011 + 0100 + 0101 + 0110 + 0111 + 1000 + 1001 + 0000REMOVENDO O BIT 0: 0000 + 0010 + 0010 + 0100 + 0100 + 0110 + 0110 + 1000 + 1000 + 0000BUFFER FINAL EM DECIMAL: 0+2+2+4+4+6+6+8+8+0 = 40Algo esta muito errado! Vamos rodar no valgrind para ver se ele nos fornece alguma luz sobre o problema:$ valgrind ./main_prog==5035== Memcheck, a memory error detector==5035== Copyright (C) 2002-2013, and GNU GPL'd, by Julian Seward et al.==5035== Using Valgrind-3.10.0.SVN and LibVEX; rerun with -h for copyright info==5035== Command: ./main_prog==5035== ==5035== Invalid read of size 4==5035== at 0x4006A6: compute_some_stuff (in /home/killocan/tuthack1/main_prog)==5035== by 0x400650: main (in /home/killocan/tuthack1/main_prog)==5035== Address 0x51fc068 is 0 bytes after a block of size 40 alloc'd==5035== at 0x4C2AB80: malloc (in /usr/lib/valgrind/vgpreload_memcheck-amd64-linux.so)==5035== by 0x4005B3: main (in /home/killocan/tuthack1/main_prog)==5035== [40]==5035== ==5035== HEAP SUMMARY:==5035== in use at exit: 0 bytes in 0 blocks==5035== total heap usage: 1 allocs, 1 frees, 40 bytes allocated==5035== ==5035== All heap blocks were freed -- no leaks are possible==5035== ==5035== For counts of detected and suppressed errors, rerun with: -v==5035== ERROR SUMMARY: 1 errors from 1 contexts (suppressed: 0 from 0)Vale notar que a saida (em azul) e correta quando o valgrind esta rodando, isso se