Debug dei file core generati sulla casella di un cliente

Cosa succede quando un file core viene generato da una distribuzione Linux diversa da quella che stiamo eseguendo in Dev? La traccia dello stack è significativa?

Se l'eseguibile è collegato dinamicamente, come il tuo, lo stack prodotto da GDB (molto probabilmente) non essere significativo.

Il motivo:GDB sa che il tuo eseguibile è andato in crash chiamando qualcosa in libc.so.6 all'indirizzo 0x00454ff1 , ma non sa quale codice fosse a quell'indirizzo. Quindi esamina il tuo copia di libc.so.6 e scopre che questo è in select , quindi lo stampa.

Ma le probabilità che 0x00454ff1 è anche selezionato tra i tuoi clienti copia di libc.so.6 sono piuttosto piccoli. Molto probabilmente il cliente aveva qualche altra procedura a quell'indirizzo, forse abort .

Puoi usare disas select e osserva che 0x00454ff1 si trova nel mezzo di un'istruzione o che l'istruzione precedente non è un CALL . Se uno di questi regge, la traccia dello stack non ha senso.

Puoi comunque aiutati:devi solo procurarti una copia di tutte le librerie elencate in (gdb) info shared dal sistema del cliente. Chiedi al cliente di tararli con ad es.

cd /
tar cvzf to-you.tar.gz lib/libc.so.6 lib/ld-linux.so.2 ...

Poi, sul tuo 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!

Consigliamo quindi al cliente di eseguire un binario -g in modo che sia più facile eseguire il debug.

Un tanto l'approccio migliore è:

• crea con -g -O2 -o myexe.dbg
• strip -g myexe.dbg -o myexe
• distribuire myexe ai clienti
• quando un cliente riceve un core , usa myexe.dbg per eseguire il debug

Avrai informazioni simboliche complete (file/riga, variabili locali), senza dover inviare un binario speciale al cliente e senza rivelare troppi dettagli sulle tue fonti.

Puoi davvero ottenere informazioni utili da un crash dump, anche da una compilazione ottimizzata (sebbene sia ciò che viene chiamato, tecnicamente, "un grosso rompicoglioni".) a -g compile è davvero migliore, e sì, puoi farlo anche quando la macchina su cui è avvenuto il dump è un'altra distribuzione. Fondamentalmente, con un avvertimento, tutte le informazioni importanti sono contenute nell'eseguibile e finiscono nel dump.

Quando abbini il file principale con l'eseguibile, il debugger sarà in grado di dirti dove si è verificato l'arresto anomalo e mostrarti lo stack. Questo di per sé dovrebbe aiutare molto. Dovresti anche scoprire il più possibile sulla situazione in cui accade:possono riprodurlo in modo affidabile? In tal caso, puoi riprodurlo?

Ora, ecco l'avvertimento:il punto in cui la nozione di "tutto è lì" si rompe è con i file oggetto condivisi, .so File. Se fallisce a causa di un problema con quelli, non avrai le tabelle dei simboli di cui hai bisogno; potresti essere in grado di vedere solo quale libreria .so succede in.

Ci sono molti libri sul debugging, ma non riesco a pensare a uno che consiglierei.