martes, marzo 21, 2006

¿Por qué se cuelgan los ordenadores? (I)

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.

10 Comentarios:

A las 11:41 p. m., Anonymous Treiral_ escribió... (¡Gracias, Anonymous Treiral_!)

A menudo he pensado en rodar un corto tipo House, escribiendo los sintomas de un ordenador en una pizarra y hacer un diferencial entre varios tecnicos a ver cual es la causa XDDD

 
A las 11:58 p. m., Blogger Pau escribió... (¡Gracias, Blogger Pau!)

Estás enfermo XDD tu sí que necesitas un médico :-P
¡Saludos!

 
A las 12:11 a. m., Blogger Sxim escribió... (¡Gracias, Blogger Sxim!)

Wow!! No pensé que una pregunta tan simple diera para tanta explicación, pero soy consciente de lo complicada que es la informática. Explicación muy buena, además.

Por cierto, Pau, permíteme que te dé un coonsejo: si algún día te falla la informática busca a Kike Santander y dale un par de clases sobre metáforas, símiles, comparaciones y similares. Además, si cantas bien igual te sale algo interesante (para ti y tu bolsillo, qué más se puede pedir xD).

Gracias por la explicación, ya espero la segunda parte!!

 
A las 12:16 a. m., Blogger Misslucifer escribió... (¡Gracias, Blogger Misslucifer!)

Mmmm, interesante.

 
A las 12:26 a. m., Blogger Patxi escribió... (¡Gracias, Blogger Patxi!)

¡Contigo sí que aprendo informática! Muchas gracias por explicarnos tan bien y tan sencillito todo lo relacionado con los cuelgues...

¿para cuando la parte de Hardware?

Y ahora que veo la imagen del avión con las pantallas colgadas...

¿Qué hace el piloto si en medio del vuelo se te cuelga el MS-Plane management XP?

Saludos,

Patxi

 
A las 2:05 a. m., Anonymous Treiral_ escribió... (¡Gracias, Anonymous Treiral_!)

No le hará falta tirar por la ventana el equipo, ya cae solo XDD

 
A las 1:23 p. m., Anonymous Dante escribió... (¡Gracias, Anonymous Dante!)

Interesante el articulo.
Teniendo en cuenta mis casi constante cuelgues hasta hace dos dias gracias a unos maravillosos amigos llamados drivers te exigo, por el poder que me confieren las practicas pendientes, un articulo hablando solo de ellos: sus virtudes, sus fallos, y por supuesto, su mision.

(ale, por si t faltan ideas :P)

 
A las 2:23 p. m., Blogger Pau escribió... (¡Gracias, Blogger Pau!)

En primer lugar muchas gracias a todos por los comentarios, me he divertido mucho leyéndolos :-)

Sxim: Muy bueno lo de Kike Santander xD y gracias por tu consejo, pero cantanto definitivamente mal :-P Antes de que se me ocurriera lo de las taquillas había una paranoia con ovillos y cuerdecitas... horrible.

Patxi: Muchas gracias por tu valoración. Lo de los fallos informáticos daría para otro blog entero, pero no sé qué harán en los aviones... supongo que usarán Unix y eso no les pasa jiji

Dante: Pensé en mencionar los drivers, pero a última hora se me olvidó. No se si ponerlo en el siguiente post o dedicarle uno al tema como bien dices... ya veremos.

Por cierto, que una de las principales razones para que los procesos fallen consiste en DLL's actualizadas incorrectamente por otros programas, tampoco lo he mencionado... estoy mayor.

¡Gracias a todos y un saludo!

 
A las 10:07 p. m., Anonymous Treiral_ escribió... (¡Gracias, Anonymous Treiral_!)

Las bibliotecas dan por si mismas para uno o por lo menos dos artículos XD
Incluso daría para una asignatura... XD

 
A las 10:44 a. m., Anonymous osiris escribió... (¡Gracias, Anonymous osiris!)

Oh! el infierno de las DLL's... estoy abonado al regsvr32! jaja!

Lo de Segmentation Fault me recuerda a las prácticas en C de la uni, junto al Override Error, o el Stack Overflow...

Otro de los errores más comunes por lo que se cuelgan los windows es debido a los drivers de hardware barriobajero, no sé si lo incluirás en la siguiente entrada (que por cierto tengo pendiente por leer).

Me gusta mucho como lo has explicado.
Saludos.

 

Recuerda que nos hemos mudado a nosololinux.com

<< Home