¿Qué sucede cuando se genera un archivo central desde una distribución de Linux que no sea la que estamos ejecutando en Dev? ¿El seguimiento de la pila es significativo?
Si el ejecutable está enlazado dinámicamente, como el suyo, la pila que produce GDB (muy probablemente) no ser significativo.
La razón:GDB sabe que su ejecutable falló al llamar a algo en libc.so.6 en la dirección 0x00454ff1 , pero no sabe qué código había en esa dirección. Así que busca en su copia de libc.so.6 y descubre que esto está en select , por lo que imprime eso.
Pero las posibilidades de que 0x00454ff1 también está seleccionado en sus clientes copia de libc.so.6 son bastante pequeños. Lo más probable es que el cliente haya tenido algún otro trámite en esa dirección, quizás abort .
Puedes usar disas select , y observa que 0x00454ff1 está en medio de la instrucción o que la instrucción anterior no es un CALL . Si cualquiera de estos se mantiene, su seguimiento de pila no tiene sentido.
Tu puedes sin embargo, ayúdese:solo necesita obtener una copia de todas las bibliotecas que se enumeran en (gdb) info shared del sistema del cliente. Pídele al cliente que los alquitran con, por ejemplo,
cd /
tar cvzf to-you.tar.gz lib/libc.so.6 lib/ld-linux.so.2 ...
Luego, en su sistema:
mkdir /tmp/from-customer
tar xzf to-you.tar.gz -C /tmp/from-customer
gdb /path/to/binary
(gdb) set solib-absolute-prefix /tmp/from-customer
(gdb) core core # Note: very important to set solib-... before loading core
(gdb) where # Get meaningful stack trace!
Luego le recomendamos al Cliente que ejecute un binario -g para que sea más fácil de depurar.
mucho mejor enfoque es:
- construir con
-g -O2 -o myexe.dbg strip -g myexe.dbg -o myexe- distribuir
myexea los clientes - cuando un cliente obtiene un
core, usamyexe.dbgpara depurarlo
Tendrá información simbólica completa (archivo/línea, variables locales), sin tener que enviar un binario especial al cliente y sin revelar demasiados detalles sobre sus fuentes.
De hecho, puede obtener información útil de un volcado de memoria, incluso uno de una compilación optimizada (aunque es lo que se llama, técnicamente, "un gran dolor de cabeza") a -g compilar es mejor, y sí, puede hacerlo incluso cuando la máquina en la que ocurrió el volcado es otra distribución. Básicamente, con una salvedad, toda la información importante está contenida en el ejecutable y termina en el volcado.
Cuando haga coincidir el archivo principal con el ejecutable, el depurador podrá decirle dónde ocurrió el bloqueo y mostrarle la pila. Eso en sí mismo debería ayudar mucho. También debe averiguar todo lo que pueda sobre la situación en la que sucede:¿pueden reproducirla de manera confiable? Si es así, ¿puedes reproducirlo?
Ahora, aquí está la advertencia:el lugar donde la noción de "todo está ahí" se rompe es con los archivos de objetos compartidos, .so archivos Si falla debido a un problema con ellos, no tendrá las tablas de símbolos que necesita; es posible que solo pueda ver qué biblioteca .so sucede en.
Hay varios libros sobre depuración, pero no puedo pensar en uno que recomendaría.