.png)
Escenario (Ubuntu 16.04):
Compilo y ejecuto un programa en C (con -g
, obtengo el tradicional Segmentation Fault (core dumped)
, y luego (por supuesto) no se encuentra ningún archivo "central" mítico. Algunas investigaciones dicen que hay que modificar /proc/sys/kernel/core_pattern
con un comando en el sentido de: echo '|tee /home/me/my_core_folder/my_core_file' | sudo tee /proc/sys/kernel/core_pattern
, y después de hacerlo esto, dejo de obtenerlo (core dumped)
y empiezo a obtener solo el Plain Segmentation Fault
. Intento cosas gdb ./program_object_file.out core.pid
que obviamente no existen (me estaba desesperando) y, por supuesto, intento el Plain gdb ./a.out
seguido de (gdb) core core.pid
variantes de los comandos en los que envío spam a la tab
clave tratando desesperadamente de hacerlo. obtenga la función de autocompletar para llevarme a donde necesito estar.
Pregunta:
¿Existe alguna forma generalizada de acceder a los volcados de núcleo? Reconozco que cada máquina que toco parece tener unTransformadores de Michael Bay-Esque capacidad para reconfigurar hardware y software de modo que no se pueda esperar que ningún dispositivo de mi propiedad funcione normalmente desde el primer momento. ¿Existe algún algoritmo/receta simple que pueda seguir para localizar volcados de núcleo en mi propia máquina y en las máquinas de otras personas? Siempre me encuentro dando clases particulares a mis amigos sobre cosas como esta después de una cantidad no pequeña de trabajo para que todo funcione por mí mismo y sería bueno poder ejecutar un comando o algo para descargar los archivos principales al directorio desde donde se ejecutó el ejecutable. ... ¿hay alguna forma de hacer esto que debería funcionar en la mayoría de las máquinas Linux/Unix (me conformaría con "algunas")?
Respuesta1
Elcore(5)
La página de manual describe en detalle los parámetros que afectan los volcados de memoria, incluidos sus nombres, etc.
Para responder a la pregunta formulada, no existe una forma generalizable de encontrar un volcado de memoria. De forma predeterminada, el núcleo se descarga en elprocesoel directorio de trabajo actual, si el proceso puede escribir allí, si hay suficiente espacio en el sistema de archivos que lo contiene, si no existe un volcado de núcleo (bajo algunas circunstancias) y si el tamaño del archivo y los límites de tamaño del archivo principal (según lo establecido por ulimit
o mecanismos similares) lo permitan. Pero /proc/sys/kernel/core_pattern
proporciona muchas formas diferentes de procesar volcados de núcleo, por lo que también es necesario analizar eso y descubrir qué está pasando.
En su caso, no sé por qué no se pudo encontrar el núcleo inicialmente, pero sí sé por qué dejó de obtener núcleos después de configurar la redirección: cuando usa una tubería en core_pattern
, el programa de procesamientodebeespecificarse utilizando una ruta de acceso absoluta. tee
por sí solo no se utilizará; necesitas especificar /usr/bin/tee
. Tenga en cuenta que debe tener especial cuidado con este tipo de configuración en sistemas multiusuario, porque el programa que se ejecuta para procesar el volcado del núcleo se ejecuta como archivo root
.
En derivados de Debian instalocorekeeper
, que escribe volcados de núcleo de una manera fácilmente utilizable en directorios por usuario en /var/crash
.
Respuesta2
(Mover una respuesta de OP en la pregunta a una respuesta)
Marqué la respuesta a continuación como la respuesta correcta ya que me ayudó a identificar lo que realmente estaba saliendo mal, y me gustaría volver en el futuro para desarrollar esto un poco más, pero mi solución actual (que sospecho que funcionaría en la mayoría máquinas Linux) es utilizar los siguientes comandos:
cat /proc/sys/kernel/core_pattern > ~/.core_pattern.bak
echo '|/usr/bin/tee ~/path_you_wish_to_dump_to/core/dump' | sudo tee /proc/sys/kernel/core_pattern
Esto hará una copia de seguridad de su método de volcado de núcleo anterior en un archivo oculto ( .core_pattern.bak
) en su carpeta de inicio que se puede restaurar con
sudo cp ~/.core_pattern.bak /proc/sys/kernel/core_pattern
y el segundo comando hará que los volcados de núcleo se vuelquen a una carpeta denominada core
archivo denominado dump
. Obviamente puedes modificar este formato para conseguir un patrón más de tu agrado. Sin embargo, cabe señalar que, hasta donde puedo decir, esto sólo almacenará un volcado de núcleo a la vez (cada uno nuevo superará a los antiguos), pero dado que, si alguna vez reviso personalmente un volcado de núcleo, es para el programa que se acaba de ejecutar, y como no necesito conservar volcados antiguos, esta es una buena solución para mí y para la mayoría de las aplicaciones que mis amigos crearán y depurarán. Me encantaría modificar esta respuesta un poco más en el futuro para incluir cosas como el PID que causó la falla de segmentación (principalmente solo azúcar encima, ya que, nuevamente, normalmente sé qué programa causó la falla de segmentación, ya que acabo de ejecutarlo) pero esto Sin duda será suficiente para mí y para mucha gente, imagino.
Por último, pero no menos importante, para ver el volcado, simplemente ejecute el comando:
gdb ./executable_that_crashed ~/path_you_wish_to_dump_to/core/dump
Suponiendo que se encuentra en la carpeta donde compiló/ejecutó el ejecutable que obtiene el error de segmentación.