¿Cómo determinamos dónde está el error en nuestro código que causa un segmentation fault?¿Determinar la línea de código que causa una falla de segmentación?
Después de escribir un código, para determinar dónde tengo una falla de segmentación, ¿puede mi compilador (gcc) mostrarme la ubicación de la falla en mi programa?
GCC no puede hacer eso, pero GDB puede hacerlo. Compilar se programa mediante el interruptor -g, así:
gcc program.c -g
A continuación, utilice el BGF:
$ gdb ./a.out
(gdb) run
<segfault happens here>
(gdb) backtrace
<offending code is shown here>
Here es un buen tutorial para empezar con el BGF.
El uso de backtrace de gdb ('bt') encontrará dónde sucedió rápidamente. – nategoose
@nategoose: verdadero :) – nc3b
Tenga en cuenta que donde se produce el segfault generalmente es solo una pista de dónde "el error que causa" está en el código.Una pista importante, pero no es necesariamente donde reside el problema. – mpez0
También podría usar un volcado de núcleo y luego examinarlo con gdb. Para obtener información útil, también debe compilar con el indicador -g.
cada vez que reciba el mensaje:
Segmentation fault (core dumped)
un archivo central se escribe en el directorio actual. Y se puede examinar con el comando
gdb your_program core_file
El archivo contiene el estado de la memoria cuando el programa falla. Un volcado de memoria puede ser útil durante la implementación de su software.
Asegúrese de que su sistema no establece el tamaño del archivo de volcado del núcleo en cero. Usted puede configurarlo para ilimitada con:
ulimit -c unlimited
Cuidado, sin embargo! que los vertederos centrales pueden volverse enormes
Cambié a arch-linux recientemente. Mi directorio actual no contiene el archivo de volcado del núcleo. ¿Cómo puedo generarlo? – Abhinav
No lo genera; Linux lo hace. Los volcados del núcleo se almacenan en diferentes ubicaciones en Linuces diferentes: Google alrededor. Para Arch Linux, lea este https://wiki.archlinux.org/index.php/Core_dump – Mawg
La respuesta de Lucas sobre los volcados del núcleo es buena. En mi .cshrc tengo:
alias core 'ls -lt core; echo where | gdb -core=core -silent; echo "\n"'
para mostrar la traza inversa al ingresar 'core'. Y el sello de la fecha, para asegurarse de que estoy mirando el archivo correcto :(
Agregado:.. Si hay un error de pila la corrupción, entonces la traza inversa aplicada al volcado de memoria es a menudo la basura en este caso , ejecutando el programa dentro de gdb puede dar mejores resultados, según la respuesta aceptada (asumiendo que la falla es fácilmente reproducible). Y también tenga cuidado con múltiples procesos de dumping núcleo simultáneamente; algunos sistemas operativos agregan el PID al nombre del archivo de núcleo.
y no olvide 'ulimit -c unlimited' para habilitar los volcados del núcleo en primer lugar. –
@Juegos: Correcto. Lucas ya mencionó esto. Y para aquellos de nosotros que todavía estamos atrapados en el csh, use 'limit'. Y nunca he podido leer los stackdumps de CYGWIN (pero no lo he intentado durante 2 o 3 años). –
Además, puede probar Valgrind: si instala Valgrind y ejecuta valgrind --leak-check = full, entonces ejecutará su programa y mostrará la pila t carreras para cualquier segfaults, así como cualquier lectura o escritura inválida de memoria y pérdidas de memoria. Es realmente bastante útil.
+1, Valgrind es mucho más rápido/fácil de usar para detectar errores de memoria. En compilaciones no optimizadas con símbolos de depuración, le dice _exactamente_ dónde ocurrió una segfault y por qué. –
Tristemente mi segfault desaparece al compilar con -g -O0 y combinado con valgrind. – JohnMudd
No gcc/gdb no puede. Puede averiguar _donde se produjo la segfault, pero el error real podría estar en una ubicación totalmente diferente. –