Re: Debugging de errores

LDC - Carmen Brando escribió:

Hola,

Primero que nada dejame comentarte que es mejor que publiques siempre en
la lista, porque

1. yo los voy a ver igual,
2. eso te da oportunidad de recibir respuesta si yo no estoy en casa.

Con respecto a esta pregunta, te puedo contar que

> Ademas, para que generara los core dump agregamos los
> flags -dH -ggdb -g en CFLAGS en el configure, genero un
> monton colocandole como sufijo .NUM, el NUM parece un PID.
> Ahora usando gdb es medio complicado ver cual es el binario
> correspondiente a cada core. Alguna sugerencia?

No tengo idea de lo que hace -dH ni -ggdb, pero lo que yo hago es
configurar con --enable-debug y eso pone los flags apropiados, no
modifico modificar CFLAGS a mano porque no es necesario.

Cuando un programa se cae, guarda el "core dump" en alguna parte, lo
cual es configurable. En Linux, puedes definir el lugar donde se guarda
modificando /proc/sys/kernel/core_pattern. Entre otras cosas puedes
poner el nombre del ejecutable, el PID, el directorio donde se guardara,
etc.

Del manual core(5):

By default, a core dump file is named core, but the /proc/sys/ker-
nel/core_pattern file (new in Linux 2.5) can be set to define a tem-
plate that is used to name core dump files. The template can contain %
specifiers which are substituted by the following values when a core
file is created:

%% A single % character
%p PID of dumped process
%u real UID of dumped process
%g real GID of dumped process
%s number of signal causing dump
%t time of dump (seconds since 0:00h, 1 Jan 1970)
%h hostname (same as 'nodename' returned by uname(2))
%e executable filename

Ahora, lo cierto es que puedes hacer

file /donde/esta/el/core.NUM

y te va a decir que ejecutable lo genero. Lo mas probable es que sea
"postmaster". Luego haces

gdb /path/al/postmaster /donde/esta/el/core.NUM

y dentro de eso, el comando "bt" te mostrara el stack de ejecucion.
Puedes cambiarte a cada frame usando el comando "frame NUM" donde NUM es
el numero de frame. Ahi puedes hacer "info locals" para desplegar las
variables locales, e "info args" para ver los argumentos. Con el
comando "print" puedes pedir mas detalles, por ej. print *arg para
desplegar una estructura apuntada por la variable arg.

Una recomendacion es usar -O0 en CFLAGS (al menos para archivos
especificos) para que las optimizaciones no estropeen la "depurabilidad"
(por ej. a veces te dice que ciertas variables no existen porque fueron
optimizadas). Pero en general, ya con poder ver cual es el stack de
llamadas a funciones puedes saber lo que esta pasando.

Te recomiendo no perder el tiempo buscando las llamadas a SO1_printf ni
nada por el estilo ... una vez que estas con GDB no necesitas eso,
puedes examinar exactamente donde va la ejecucion en cada momento.

Si necesitas examinar que paso _antes_ de que se caiga, lo que puedes
hacer es

1. echar a andar el postmaster
2. conectarte, y no hacer nada en la sesion
3. obtener el PID de la sesion que tienes abierta, ya sea con
pg_get_backend_pid() o con el comando ps
4. pegarte a ese PID con gdb, usando
gdb -p PID
5. definir un "breakpoint"
6. ejecutar "cont" en GDB
7. volver a la sesion, ejecutar tu comando
8. GDB se detiene cuando alcanza el breakpoint; aca puedes examinar el
estado del programa, etc etc. Puedes avanzar usando "step" o "next"
(son distintos) o bien continuar con "cont"
9. eventualmente el programa se cae y puedes volver a examinar el estado
con GDB

--
Alvaro Herrera http://www.CommandPrompt.com/
The PostgreSQL Company - Command Prompt, Inc.