Traza do erro con número de liña e motivo incluído, cousa fina |
Nembargantes se optamos por un entorno compilado coma C, as cousas complicanse.
A primeira e máis mítica e o debugger (si, non so serve para fozar en programas alleos ;) ), coma isto vai de software libre ímos tirar do gdb que cumpre ben (instalalo non ten ciencia ningúnha, so teredes que utilizar o xestor de pacotes de turno, así que xa non me paro niso).
Para lanzar un executable co debugger faremos:
gdb <executable>
Facendo iso levaranos á shell do gdb, onde poderemos lanza-lo programa con `run [<parámetro>]` (opcionalmente poderíamos dar uns parámetros por defecto cando iniciaramos o depurador usando a opción `--args`).
Pois ben (entre outras moitísimas cousas), se da un erro podemos saca-la traza usando o comando `backtrace` (ou `bt`).
Xa é algo, temos a traza, pero podemos sacar máis, imos compilar o programa con `-g` e voltar tentar.
Isto é outra cousa, non é?
Pero esperade, quero aproveitar a ocasión para amosarvos unha ferramenta máis que é xenial para probar programas, valgrind.
Valgrind é unha ferramenta que engancha, se programas en C e a probas vas ter moi dificil o deixala, por que? todos sabemos que C carece de comprobación de bordos nos arrays é xestión automática da memoria, valgrind apunta eses problemas para que podamos solucionalos é non pasen desapercibidos.
A primeira posición dun array baleiro? Se non hai inventase! |
Pedimos memoria e non a liberamos, neste caso non ten consecuencias, pero nun programa que non acabe no momento estaríamoslle negando a memoria o sistema. |
Valgrind avísanos destas cousas, so hai que usalo para lanza-los programas, por exemplo, para buscar problemas con variables non inicializadas (por exemplo cousas foras do bordo do array).
Neste caso podemos saber de onde ven o erro engadindo `--track-origins=yes` coma indica o programa... por certo, tamen o valgrind pode sacar partido do `-g`,
No caso das fugas de memoria tamén indica a súa existencia:
E de novo, tamén se pode beneficiar dun `-g` o compilar e un `--leak-check=full` na execución:
E con iso xa podemos atopar a orixe de moitos problemas, por suposto estas dúas ferramentas dan para moito máis (sen ir máis lonxe gdb podese usar para aprender C, e valgrind para proba-lo uso da caché) pero se nos poñemos nese plan non acabamos nin mañá :).
Saúdos.
No hay comentarios:
Publicar un comentario