Si se ha preguntado alguna cuál es el origen del extraño nombre de este blog, Segmentation Fault, hoy está de enhorabuena (tal vez no…): lea este post entero y lo entenderá todo… Antes de nada quiero decir que no soy muy partidario de dividir las entradas, pero en esta ocasión no veo otra posibilidad… Sxim me dejó éste nuevo post en bandeja, cuando a raíz del post sobre el reparto de CPU, preguntaba:

¿Qué decimos técnicamente cuando decimos que «un programa / el ordenador se ha trabado»?

Seguro que al menos una vez se le ha colgado el ordenador. Y casi seguro que habrán sido más de una (y más de dos… :-P) Pero voy a empezar con una mala noticia… por desgracia, los cuelgues son algo propio e inseparable de la informática. Ayer existieron, existen hoy, y con toda probabilidad, seguirán existiendo mañana.

¿A qué nos referimos cuando decimos que el ordenador «se cuelga»? Hay muchas formas en que un equipo puede dejar de responder: puede ser que los programas fallen en cadena. También puede ser que el Sistema Operativo deje de funcionar por algún motivo. Puede ocurrir que sencillamente el equipo deje de responder y haya que reiniciarlo… cualquier cosa.

¿Y qué produce un cuelgue? Bien, no podemos señalar a nada ni nadie como causante de la catástrofe: los motivos tenemos que buscarlos en un montón de factores. Pero como todo en la informática, vamos a dividirlos en dos partes: hardware (el cuerpo del ordenador) y software (el alma del ordenador). Hoy vamos a empezar con éste último:

El software

Tenemos que ver al ordenador como una máquina muy compleja, con un montón de cables y circuitos complicadísimos. Para regir todo esto, necesitamos al Sistema Operativo (SO). Bien, los SO son programas gigantescos y muy enrevesados, así que podemos considerar normal que se equivoquen al gestionar esa enorme complejidad electrónica. Los SO tienen que tener lo que llamamos mecanismos de protección del sistema, que impiden que los programas se influyan unos sobre otros (de forma no deseada, se entiende).

Los programas guardan muchos datos que necesitan para funcionar, y mantienen éstos datos en memoria (podemos verlo como una consigna de un supermercado o de un aeropuerto), y para acordarse se quedan con la llave, en la que viene el número de taquilla en que dejaron una información. Por ejemplo: «el nombre del usuario está en el armarito número 9». Cuando el programa quiere recordar cómo se llamaba el usuario (para saludarle), toma la llave de la consigna 9 y la abre. A éstas llaves se les suele denominar punteros en informática.

Hemos dicho que debemos evitar que los programas se molesten unos a otros, y para ello, es necesario que mantengan separados sus armaritos y que no confundan sus llaves (a nadie le gustaría que le robaran la mochila en el híper, por ejemplo…). Bien, pues tenemos nuestro programita con sus datos identificados señalados en un enorme manojo de llaves. Ahora imagine que otro programa abre por error una taquilla y modifica el contenido, o que nuestra aplicación pierde una llave, o el número de la llave se altera… cualquier catásfrofe que se le ocurra. En la cruda realidad, éstos desarreglos significan generalmente errores críticos de ejecucion: el programa esperaba encontrarse otra cosa en su taquilla, y simplemente, falla.

¿Por qué se colgaban más los sistemas Windows? La explicación es que los Windows antiguos (95, 98…) no sabían hacer frente a un programa que trataba de abrir otra taquilla. Sencillamente se lo permitían, como si no fuera su problema… pero sí lo era. Los procesos empezaban entonces a fallar en cadena, por lo que tarde o temprano ocurrían dos cosas: o bien los armarios del SO eran alterados (pantalla azul), o bien el ordenador se quedaba sin recursos para atender las excepciones devueltas por los programas (bloqueo del sistema). Lo estoy contando a muy grandes rasgos, la realidad es generalmente mucho más complicada y menos novelesca…

Sin embargo, a partir de los Windows serios (NT, 2000, XP…) ésto se solucionó. De hecho, si usó W98 y ahora usa WXP, verá que el segundo es mucho más estable que el primero. En el caso de los Unix y los Linux, cuando un programa intenta acceder a una taquilla ajena, es fulminado inmediatamente y se produce un error. Unix tiene unas bases muy modulares, y por norma general, un fallo local no suele afectar al resto del sistema. Así, cuando un programa ejecuta una operación no válida, se produce un error denominado (agárrese) Segmentation Fault. En español, viene a ser «violación de segmento», que quiere decir que un proceso ha intentado acceder a memoria fuera de la que tiene reservada (fuera de su segmento, para entendernos…)

Sin embargo, es injusto decir que los errores o los cuelgues se produzcan exclusivamente a causa del software. Muchas veces, la culpa la tienen los dispositivos físicos: procesadores que no funcionan, fuentes de alimentación que no dan más de sí… todas estas cosas las vamos a analizar en la siguiente entrega. ¡Hasta entonces!

Actualización: Ya puedes leer la segunda parte del post.