¿Qué significa el mensaje de rastreo de GDB “0x0000000000000000 en ??()" ¿significar?

Question

¿Qué significa cuando da un seguimiento con el siguiente resultado?

#0  0x00000008009c991c in pthread_testcancel () from /lib/libpthread.so.2
#1  0x00000008009b8120 in sigaction () from /lib/libpthread.so.2
#2  0x00000008009c211a in pthread_mutexattr_init () from /lib/libpthread.so.2
#3  0x0000000000000000 in ?? ()

El programa falló con una señal estándar 11, falla de segmentación.Mi aplicación es un programa FastCGI C++ multiproceso que se ejecuta en FreeBSD 6.3 y utiliza pthread como biblioteca de subprocesos.

Se ha compilado con -g y todas las tablas de símbolos de mi fuente están cargadas, según las fuentes de información.

Como está claro, nada de mi código real aparece en el seguimiento, sino que el error parece originarse en bibliotecas pthread estándar.En particular, ¿qué es?() ????

EDITAR:Finalmente rastreé el bloqueo hasta un acceso a memoria no válido estándar en mi código principal.No explica por qué se corrompió el seguimiento de la pila, pero esa es una pregunta para otro día :)

Answer 1

gdb no pudo extraer la dirección de retorno adecuada de pthread_mutexattr_init;obtuvo una dirección de 0.El "??" es el resultado de buscar la dirección 0 en la tabla de símbolos.No puede encontrar un nombre simbólico, por lo que imprime un valor predeterminado "??"

Desafortunadamente, de inmediato no sé por qué no pudo extraer la dirección de devolución correcta.

Answer 2

Algo que hiciste provocó que la biblioteca de subprocesos fallara.Dado que la biblioteca de subprocesos en sí no está compilada con símbolos de depuración (-g), no puede mostrar el archivo de código fuente o el número de línea en el que ocurrió el bloqueo.Además, dado que se trata de subprocesos, la pila de llamadas no apunta a su archivo.Desafortunadamente, este será un error difícil de rastrear, necesitarás revisar tu código e intentar determinar cuándo ocurre exactamente el bloqueo.

Answer 3

Asegúrese de compilar con símbolos de depuración.(Para gcc creo que esa es la opción -g).Entonces debería poder obtener información más interesante de GDB.No olvides desactivarlo cuando compiles la versión de producción.

Answer 4

Podría faltarme algo, pero ¿no es esto indicativo de que alguien está usando NULL como puntero de función?

#include <stdio.h>

typedef int (*funcptr)(void);

int
func_caller(funcptr f)
{
    return (*f)();
}

int
main()
{
    return func_caller(NULL);
}

Esto produce el mismo estilo de seguimiento inverso si lo ejecuta en gdb:

rivendell$ gcc -g -O0 foo.c -o foo
rivendell$ gdb --quiet foo
Reading symbols for shared libraries .. done
(gdb) r
Starting program: ...
Reading symbols for shared libraries . done

Program received signal EXC_BAD_ACCESS, Could not access memory.
Reason: KERN_PROTECTION_FAILURE at address: 0x00000000
0x00000000 in ?? ()
(gdb) bt
#0    0x00000000 in ?? ()
#1    0x00001f9d in func_caller (f=0) at foo.c:8
#2    0x00001fb1 in main () at foo.c:14

Aunque este es un accidente bastante extraño... pthread_mutexattr_init rara vez hace algo más que asignar una estructura de datos y memset él.Buscaría algo más.¿Existe la posibilidad de que las bibliotecas de subprocesos no coincidan o algo así?Mis conocimientos de BSD están un poco anticuados, pero solía haber problemas al respecto.

Answer 5

¿Quizás el error que causó el bloqueo rompió la pila (sobrescribió partes de la pila)?En ese caso, el rastreo podría resultar inútil;No tengo idea de qué hacer en ese caso...