🚀 go-pugleaf

Santiago Romero dijo sobre Re: Problemillas con los sockets,
en fecha: Fri, 24 Mar 2000 22:38:33 +0100

|El Mon, 20 Mar 2000 23:01:09 +0100, *puntero_loko escribi�:
|>Paco Orts dijo sobre Re: Problemillas con los sockets,
|>en fecha: Mon, 20 Mar 2000 13:36:31 +0100
|
|>El electric-fence  es muy  sencillo, simplementes  al enlaces  a�ades el
|>par�metro  -lefence y  ejecutas. Normalmente  si te  da un  segmentation
|>fault es justo donde est� el error y no 300 l�neas m�s abajo.
|
| �Que tal puntero_loco un cursilo de gdb, xxgdb y electricfence para
| la FAQ y postearlo aqui cuando se pregunte sobre el tema? ALgo corto
| de referencia. Va, espero tu post XDDDDDDD

Pues al gdb ultimamente le estoy cogiendo mucha ma�a con esto de los bugs del
jfpop, el xxgdb no lo he visto mucho, tengo m�s contacto con el DDD, el
electricfence no tiene mucho misterio (y la p�gina man es explicativa 100%),
y adem�s el s�bado que viene tengo un examen, pero prometo que esta semana
escribo un post aqu�, de todos modos para los impacientes explico como va el
electric-fence en dos palabras:


[Bah, iba a hacer un resumen en dos l�neas pero...]

El electric fence no es m�s que una librer�a que sustituye a malloc, free y
compa��a, por otras funciones que marcan las zonas de memoria por encima (y
por debajo, si as� lo hemos configurado), como no accesibles, de modo que si
por ejemplo al leer de una cadena (o peor, al escribir), o un array nos
pasamos, por poquito que sea, el programa dar� un Segmentation Fault. Pues
vaya m.... pensar� alguno. Pues no se�or. Cuando enlazamos con el
electric-fence el fallo nos lo dar� justo donde nos hayamos ido, no 500
instrucciones m�s tarde (por algo lo usan en Pixar). 

De este modo, s�lo tenemos que lanzar el gdb, ir ejecutando, y cuando nos de
el segmentation fault, pues ya sabemos que ah� esta el fallo. 

Como utilizarlo: M�s f�cil imposible, simplemente enlazar con la librer�a
est�tica con -lefence en los par�metros del gcc. Esto har� que el programa sea
muuuuuuuuuuuuuuucho m�s lento y ocupe muuuuuuuuuuuuuuuuuucha m�s memoria, pero
para depurar eso no importa. Esto nos da una configuraci�n por defecto de que
detecte los accesos m�s all� del l�mite, pero no antes. Todo lo dem�s se
configura con variables de entorno, la m�s util es la opci�n EF_PROTECT_BELOW
que nos detectar� tambi�n los accesos por debajo de la memoria asignada. En
realidad no tiene muchas m�s opciones, pero la p�gina man no tiene
desperdicio: Hay que leerla (no es muy larga).

Ahora un poquito (muy poquito) del gdb:

Gdb es un gran depurador con multitud de opciones interesantes. Pero la mayor
parte del tiempo vamos a usar muy pocas de ellas. Para poder depurar un
programa es necesario haberlo compilado con la opci�n -g del gcc y por
supuesto no stripearlo. Despu�s simplemente:

gdb programa

Nos saldr� un fea pantalla como:

GNU gdb 19990928
Copyright 1998 Free Software Foundation, Inc.
GDB is free software, covered by the GNU General Public License, and you are
welcome to change it and/or distribute copies of it under certain conditions.
Type "show copying" to see the conditions.
There is absolutely no warranty for GDB.  Type "show warranty" for details.
This GDB was configured as "i686-pc-linux-gnu"...
(gdb)

El (gdb) es el prompt. Podemos obtener ayuda con 'help' y 'help secci�n' (las
secciones posibles salen poniendo help sin nada).

Al grano: Para establecer los argumentos que le pasar�amos al programa:
set args argumento1 argumento2 etc

Para establecer breakpoints:
break funcion

Por ejemplo, la primera vez har�amos:
break main

Para depurar el programa desde el principio. Una vez hemos puesto los
breakpoints y los argumentos empezamos a ejecutar con:
run

Esto nos sacar� la primera l�nea de nuestro programa. Para obtener un listado
de las l�neas cercanas:
list

que puede abreviarse como 'l'. En general casi todos los comandos tienen una
abreviatura como primera letra salvo cuando puede producirse ambiguedad.

Para pasar a la siguiente l�nea:

next (abreviado como n)

El next puede aceptar un argumento que es el n�mero de l�neas que queremos
ejecutar. Si pulsamos intro se repite el �ltimo comando introducido (�til para
ejecutar r�pidamente varios next).

next si encuentra una llamada a funci�n no se introduce en ella. Esto es �til
para detectar r�pidamente donde nos peta el programa recorriendo las llamadas
a funci�n del programa y ver en cual de ellas falla. Despu�s podemos volver a
ejecutar pero al llegar a la funci�n que falla (si no nos hemos dado cuenta ya
de cual es el fallo) con:

step (abreviado como s)

exactamente igual que next, pero introduci�ndose en las funciones. Si est�
funci�n llama a su vez a varias otras funciones es recomendable repetir el
proceso anterior (next, localizar, meternos con step, next, localizar...)
hasta que demos con la l�nea que falla.

Por supuesto tambi�n podemos (y debemos) imprimir los valores de las variables
y estructuras que consideremos 'sospechosos'. Esto se hace con:

print variable (abreviado como p).

En el caso de cadenas tenemos printf:

printf "cadena con un formato %d muy bonito"

que admite los mismos especificadores de formato que el printf de C (sin los
par�ntesis). Si estamos utilizando el DDD (gr�fico) podemos poner una
ventanita donde nos sale continuamente el valor que tienen ciertos datos.
Adem�s con print tambi�n podemos cambiar el valor de los datos:

print dato=loquequeramos (comillas si es una cadena).

Con esto ya hay para ir tirando (para m�s ayuda, el info).

Una �ltima  cosa: Los archivos core,  esas molestos archivos de  6 megas
que nos deja  siempre el netscape como recuerdo de  su inoperancia. Pues
son extremadamente �tiles para depurar  los programas. Podemos pensar en
el core  como en  el cadaver  del programa que  podemos examinar,  si el
programa fue compilado  con -g y no stripeado. Para  utilizarlos se hace
con:

gdb programa -c core

(importante que 'programa' y el proceso que gener� el core sean la misma
versi�n). Esto (con suerte) nos dir� en que l�nea fallo el programa (si las
fuentes est�n en el mismo directorio), y con m�s suerte a�n nos permitir� ver
los valores de variables y dem�s. Que el core sea realmente informativo
depende de muchos factores como la fase lunar, si nos hemos afeitado (tiendo a
pensar que cuando estoy reci�n afeitado y limpio los cores son m�s amigables)
y dem�s.

Un �ltimo consejo. El gcc es un compilador algo peculiar porque nos deja
compilar con s�mbolos de depuraci�n y optimizar. Mi consejo es que para
depurar paseis de las optimizaciones sino quereis ver cosas raras cuando
estemos ejecutando paso a paso (l�neas que se saltan, while que empiezan a
ejecutarse por debajo, etc.)

Fin del mensaje: man efence, info gdb son vuestros amigos.

El pr�ximo post: DDD y como evitar perder la cordura ante los Heisenbugs (1).

(1):  D�cese  del bug  que  provoca  un  fallo  en nuestro  programa  en
cualquier circunstancia menos cuando lo  ejecutamos con el depurador, en
cuyo caso  el programa funciona a  la perfecci�n. Puedo asegurar  que no
son una historia de miedo que corra  de maestros a alumnos, como el coco
y dem�s: Existen. Rezo por vosotros por que no encontreis ninguno.


-- 
P�gina personal: http://personal1.iddeo.es/ferkys
----------------
Para obtener mi clave PGP env�ame un correo con el subject "send key pub"
----------------