¿Cómo leer y usar informes de fallos?

12

Una pequeña aplicación independiente se está bloqueando en mi sistema (Kubuntu 12.04). Quiero revisar manualmente la información en el informe de bloqueo y luego enviar por correo electrónico las partes relevantes al desarrollador. El archivo se encuentra en /var/crash/_usr_bin_appname.1000.crashsin embargo no estoy seguro de qué herramienta que necesito para poder leer, editar y guardar el informe de bloqueo en una forma que puedo enviar por correo electrónico a los desarrolladores.

MountainX
fuente

Respuestas:

7

Los informes de bloqueo de Apport deben ubicarse en:

/var/crash

Y cuando miro uno:

jmunsch@NE-522:/var/log$ sudo cat /var/crash/*.*


ProblemType: Crash
Architecture: i386
Date: Fri Jul 11 20:40:09 2014
DistroRelease: Ubuntu 12.04

Este es el programa que causó un problema:

ExecutablePath: /usr/sbin/winbindd
ExecutableTimestamp: 1395068066
ProcCmdline: /usr/sbin/winbindd
ProcCwd: /var/log/samba/cores/winbindd
ProcEnviron:
 TERM=linux
 PATH=(custom, no user)

Estos son los objetos compartidos C / bibliotecas compartidas que estaba utilizando el programa problemático:

ProcMaps:
 b6606000-b6622000 r-xp 00000000 08:01 394314     /lib/i386-linux-gnu/libgcc_s.so.1
 b6622000-b6623000 r--p 0001b000 08:01 394314     /lib/i386-linux-gnu/libgcc_s.so.1
 b6623000-b6624000 rw-p 0001c000 08:01 394314     /lib/i386-linux-gnu/libgcc_s.so.1
 b6642000-b664d000 r-xp 00000000 08:01 442782     /lib/i386-linux-gnu/libnss_files-2.15.so
 b664d000-b664e000 r--p 0000a000 08:01 442782     /lib/i386-linux-gnu/libnss_files-2.15.so
 b664e000-b664f000 rw-p 0000b000 08:01 442782     /lib/i386-linux-gnu/libnss_files-2.15.so
 b664f000-b6659000 r-xp 00000000 08:01 442517     /lib/i386-linux-gnu/libnss_nis-2.15.so
 b6659000-b665a000 r--p 00009000 08:01 442517     /lib/i386-linux-gnu/libnss_nis-2.15.so
 b665a000-b665b000 rw-p 0000a000 08:01 442517     /lib/i386-linux-gnu/libnss_nis-2.15.so
 b665b000-b6662000 r-xp 00000000 08:01 442803     /lib/i386-linux-gnu/libnss_compat-2.15.so
 b6662000-b6663000 r--p 00006000 08:01 442803     /lib/i386-linux-gnu/libnss_compat-2.15.so
 b6663000-b6664000 rw-p 00007000 08:01 442803     /lib/i386-linux-gnu/libnss_compat-2.15.so
 b666c000-b6670000 rw-s 00000000 00:0f 11331      /run/samba/messages.tdb
 b6670000-b6679000 rw-s 00000000 08:01 393253     /var/lib/samba/account_policy.tdb
 b6679000-b6682000 rw-s 00000000 08:01 445067     /var/lib/samba/passdb.tdb
 b6682000-b668a000 rw-s 00000000 08:01 394026     /var/cache/samba/winbindd_cache.tdb
 b668a000-b668b000 rw-s 00000000 08:01 442342     /var/cache/samba/netsamlogon_cache.tdb
 b668b000-b668d000 rw-s 00000000 00:0f 11353      /run/samba/serverid.tdb
.
.
.

Esto muestra lo que estaba haciendo el programa cuando ocurrió el bloqueo:

ProcStatus:
 Name:  winbindd
 State: S (sleeping)
 Tgid:  1556
 Pid:   1556
 PPid:  1
 TracerPid: 0
 Uid:   0   0   0   0
 Gid:   0   0   0   0
 FDSize:    256
 Groups:    
 VmPeak:       18000 kB
 VmSize:       17880 kB
 VmLck:        0 kB
 VmPin:        0 kB
 VmHWM:     2956 kB
 VmRSS:     2956 kB
 VmData:         400 kB
 VmStk:      136 kB
 VmExe:     7668 kB
 VmLib:     8656 kB
 VmPTE:       44 kB
 VmSwap:           0 kB
 Threads:   1
 SigQ:  2/30418
 SigPnd:    0000000000000000
 ShdPnd:    0000000000000000
 SigBlk:    0000000000000400
 SigIgn:    0000000000001000
 SigCgt:    0000000180014e47
 CapInh:    0000000000000000
 CapPrm:    ffffffffffffffff
 CapEff:    ffffffffffffffff
 CapBnd:    ffffffffffffffff
 Cpus_allowed:  3
 Cpus_allowed_list: 0-1
 Mems_allowed:  1
 Mems_allowed_list: 0
 voluntary_ctxt_switches:   1215
 nonvoluntary_ctxt_switches:    11
Signal: 6
Uname: Linux 3.2.0-53-lowlatency-pae i686
UserGroups: 

Esto podría tener todas sus contraseñas, tenga cuidado con esta información:

CoreDump: base64
.
.
.
core dump looks like
aASDFNFOSIefnsldgfnsweifnLEGNi43ng3gSNSDLgn483LNdg43ls
WO$EIGNOIDGNW$INGLSDKGNSLDIGNO$WIGNLRSIGN*RW(GNDKJNLGD
*TNOIDUGNSKJDGNKSDGNSIUEGFBSGUDB*SDgUSHNEUGBSD&GSAUBSD
.
.
.
jmunsch
fuente
¿Cómo haría para ver el CoreDump?
Alex Dueppen
@ A.Dueppen debe estar al final del archivo.
jmunsch
1
//, ¿Cómo se compara esto apport-retrace? Además, ¿consideraría agregar wiki.ubuntu.com/DebuggingProgramCrash a esta respuesta?
Nathan Basanese
6

Aquí está la mejor solución que he encontrado hasta ahora:

apt-get install apport-retrace

Luego estudie el manual en:

http://manpages.ubuntu.com/manpages/raring/en/man1/apport-retrace.1.html

o

man apport-retrace

Se me ocurrió este comando:

apport-retrace --confirm --gdb --sandbox system --verbose --cache /my/path/cache/apport-retrace --output /mypath/apport-retrace/appname.1000.crash /var/crash/_usr_bin_appname.1000.crash

Use sus propias rutas (en lugar de / my / path) y el nombre correcto de la aplicación (en lugar de 'appname') en el comando anterior. Consulte el manual para conocer las variaciones de ese comando.

MountainX
fuente
2
Nota importante para los nuevos usuarios: cuando decida omitir la --cache ...opción, podría pensar que algo va mal, pero no es así. Se apt-getactivará un procedimiento integral ( ¡ sin root !) Que se puede imaginar como una especie de "máquina virtual" en la que se ejecutará el comando en cuestión. Francamente, cuando esto sucedió por primera vez, pensé "¿Qué diablos está pasando AHORA?" Además, tenga paciencia : tomará minutos hasta que el entorno de depuración esté listo para usar.
syntaxerror
3
Nota adicional : NO puede usar -oresp. --outputen combinación con --gdbesto, esto no es posible.
syntaxerror
-2

Bueno, Ubuntu también había diseñado una secuencia para ti. Su nombre es D ebugging Program Crash Edit: acabo de enterarme de un programa llamado volatility y está disponible para Ubuntu, puede instalarlo con

sudo apt-get install ubuntu

para más información

rɑːdʒɑ
fuente
2
Las respuestas de StackExchange no deberían ser solo enlaces a otros sitios.
MountainX
//, de acuerdo. Aún así, es un buen enlace.
Nathan Basanese