Al ejecutar un programa C, dice "(núcleo volcado)" pero no puedo ver ningún archivo en la ruta actual.núcleo volcado, pero el archivo principal no está en el directorio actual?
he puesto y verificado el ulimit:
ulimit -c unlimited
ulimit -a
También traté de encontrar el archivo llamado "núcleo", pero no consiguió el núcleo de archivos objeto de dumping?
Cualquier ayuda, ¿dónde está mi archivo principal?
Leer /usr/src/linux/Documentation/sysctl/kernel.txt.
[/ proc/sys/kernel /] core_pattern se utiliza para especificar un nombre de patrón de dumpfile de núcleo.
- Si el primer carácter del patrón es un '|', el kernel tratará el resto del patrón como un comando a ejecutar. El volcado del núcleo será escrito en la entrada estándar de ese programa en lugar de en un archivo.
En lugar de escribir el volcado de memoria en el disco, el sistema está configurado para enviar al programa abrt lugar. Automated Bug Reporting Tool no es, posiblemente, tal como se documenta ya que should sea ...
En cualquier caso, la respuesta rápida es que debe ser capaz de encontrar su archivo central en /var/cache/abrt, donde abrt almacena después de haber sido invocado. De manera similar, otros sistemas que usan Apport pueden arrancar núcleos en /var/crash, y así sucesivamente.
sí, he editado core_pattern con el siguiente contenido echo "core.% E.% P ">/proc/sys/kernel/core_pattern ... ahora crea el archivo de volcado del núcleo en el directorio actual. con el nombre "core.giis.12344" etc. Gracias a todos por sus respuestas/comentarios/sugerencias. –
Solo para tener en cuenta que el programa fedora 18 abrt está almacenando volcados del núcleo en '/ var/spool/abrt /' en lugar de '/ var/cache/abrt' – Nelson
¿Hay alguna manera de permitir que los usuarios configuren esto por sí mismos, en lugar de todos tener que usar la configuración del sistema? – allyourcode
que podría pensar en dos posibilidades siguientes:
Como otros ya han señalado, el programa podría chdir(). ¿El usuario que ejecuta el programa tiene permiso para escribir en el directorio en el que está chdir() 'ed to? Si no, no puede crear el volcado del núcleo.
Por alguna extraña razón, el volcado del núcleo no se llama core.* Puede consultar /proc/sys/kernel/core_pattern para eso. Además, el comando de búsqueda que has nombrado no encontrará un volcado de núcleo típico. Debe utilizar find/-name "*core.*", como el nombre propio de la coredump es core.$PID
aquí está mi patrón: ¿esto significa que el archivo central se llama algo así como "PID.signal.userid" en lugar de core.pid ??? $ cat/proc/sys/kernel/core_pattern /usr/lib/hookCCpp/var/char/abrt% p% s% u –
Con el lanzamiento de systemd, también hay otro escenario. Por defecto systemd almacenará los volcados del núcleo en su diario, siendo accesible con el comando systemd-coredumpctl. Definido en el core_pattern-archivo:
$ cat /proc/sys/kernel/core_pattern
|/usr/lib/systemd/systemd-coredump %p %u %g %s %t %e
Este comportamiento se puede desactivar con un simple "piratear":
$ ln -s /dev/null /etc/sysctl.d/50-coredump.conf
$ sysctl -w kernel.core_pattern=core # or just reboot
Como siempre, el tamaño de los volcados de memoria tiene que ser igual o mayor que el tamaño del núcleo que se está volcando, como se hace por ejemplo ulimit -c unlimited.
Ese "truco" no funcionó para mí (incluso después de un reinicio). Estoy ejecutando Arch Linux y ya he ejecutado 'ulimit -c unlimited'. – gsingh2011
@ gsingh2011 Podría estar desactualizado. Ya no corro Arch, así que no puedo decir si debería funcionar en estos días. Si lo resuelves, no dudes en actualizarme/enviarnos un nuevo comentario. – timss
@ gsingh2011 Pruebe '50-coredump.conf' en lugar de' coredump.conf'. Esto debería anular '/ lib/sysctl.d/50-coredump.conf'. El valor predeterminado se puede restaurar con 'sysctl -w kernel.core_pattern = core' – Lekensteyn
En Ubuntu reciente (12.04 en mi caso), es posible que se imprima "Error de segmentación (núcleo objeto de dumping)", pero no se generó ningún archivo central donde podría esperar uno (por ejemplo, para un programa compilado localmente).
Esto puede suceder si tiene un tamaño de archivo central ulimit de 0 (no lo ha hecho ulimit -c unlimited); este es el valor predeterminado en Ubuntu. Normalmente eso suprimiría el "(núcleo objeto de dumping)", lo percibe en su error, pero en Ubuntu, los archivos core son canalizados a Apport (sistema de informes de fallas de Ubuntu) a través del /proc/sys/kernel/core_pattern, y esto parece causar el mensaje engañoso.
Si Apport descubre que el programa en cuestión no es uno por el que debería informar bloqueos (que se puede ver en /var/log/apport.log), se vuelve a simular el comportamiento predeterminado del kernel de poner un archivo core en el cwd (se hace en el script /usr/share/apport/apport). Esto incluye honrar a ulimit, en cuyo caso no hace nada. Pero (supongo) en lo que se refiere al kernel, se generó un archivo core (y se canalizó para su incorporación), de ahí el mensaje "Fallo de segmentación (núcleo volcado)".
En última instancia, PEBKAC por olvidarme de establecer ulimit, pero el mensaje engañoso me hizo pensar que me estaba volviendo loco por un tiempo, preguntándome qué se estaba comiendo mis archivos principales.
(También, en general, el núcleo (5) en el manual - man 5 core - es una buena referencia para su archivo en el núcleo y termina por razones que no se podría escribir.)
Muchas gracias - me encontré con el mismo el mismo problema. Por cierto, Ubuntu 14.04 exhibe exactamente el mismo comportamiento que el que describió. –
En mi instalación de Ubuntu (modificado 14.04), hay una solución temporal fácil para esto ejecutando 'sudo service apport stop' --- después de ejecutar eso, cambió'/proc/sys/kernel/core_pattern' de la tubería de acceso a solo 'core'. Apport es lo suficientemente inteligente como para arreglar temporalmente el 'core_pattern', supongo. –
"ulimit -c unlimited" es exactamente lo que necesitaba, ¡gracias! –
Si eres núcleo faltante vertederos para binarios en RHEL y cuando se utiliza abrt, asegúrese de que /etc/abrt/abrt-action-save-package-data.conf
contiene
ProcessUnpackaged = yes
Esto permite la creación de informes de fallos (i incluyendo los volcados centrales) para los archivos binarios que no forman parte de los paquetes instalados (p. construido localmente).
Para fedora25, he podido encontrar el archivo central en la
/var/spool/abrt/ccpp-2017-02-16-16:36:51-2974/coredump
donde ccpp-2017-02-16-16:36:51-2974" is pattern "%s %c %p %u %g %t %P % según las instrucciones `/ proc/sys/kernel/core_pattern'
de escritura para conseguir un núcleo volcado bajo Ubuntu 16.04 LTS:
Como @jtn ha mencionado en su respuesta, los delegados de Ubuntu la visualización de los accidentes a informe, que a su vez se niega a escribir el volcado porque el programa no es un paquete instalado. 
Para remediar el problema, hay que asegurarse de Apport escribe los archivos de volcado del núcleo de no paquete de programas también. Para hacer esto crea un archivo llamado ~/.config/apport/ajustes con el contenido: [main] unpackaged=true
[Opcional] Para hacer el readble vertedero de GDB, ejecute el siguiente comando:
apport-unpack <location_of_report> <target_directory>
Referencias: Terry : Core Dump
¿El programa invocan chdir en algún momento ? Si es así, mira allí. –
¿El programa cambia su directorio de trabajo? Mira allí. –
Buscaría todo el disco duro para un archivo reciente;) –