Sistema per salvare lo stato dell'applicazione al momento del crash, per poter debuggare anche dopo il crash.
Possiamo anche usare gdb da x86 per debuggare un'applicazione che girava su arm.
Per mettere al massimo il limite della dimensione disponibile per i core dump:
ulimit -c unlimited
Attenzione: questo imposta il limite solo per la shell attuale e per i processi che verranno lanciati da tale shell. Dovrebbe essere possibile modificare il comportamento per tutto il sistema: bisogna modificare il file /etc/security/limits.conf
aggiungendo queste due righe:
root - core unlimited
* - core unlimited
Purtroppo non sono riuscito a farlo funzionare. Quindi, assicurati che il processo che devi debuggare venga lanciato dalla stessa shell in cui hai chiamato ulimit
.
Per configurare il nome del file del core dump che verrà creato.
echo "/data/log/core.%e.%p.%t" > /proc/sys/kernel/core_pattern
%e è il nome dell'eseguibile. %p è il pid. %t è il timestamp. Per altri pattern vedi man core
. Questo configura il sistema a scrivere il core dump in /data/log/core.MyApp.1234.1496822060
. Normalmente è configurato a scrivere nel file core
, quindi nella cartella di lavoro da cui hai lanciato l'eseguibile. Trovo più comodo scrivere i dump in una cartella con percorso assoluto, così eviti di lasciare file sparsi a caso nel sistema.
A questo punto lanci l'applicazione. Quando il processo crasha, viene scritto il core dump nella cartella che hai configurato.
Copia il core dump dal sistema in cui girava il processo al tuo pc.
Lancia il debugger per l'architettura giusta:
/opt/Texas/ti-sdk-am335x-evm/linux-devkit/sysroots/i686-arago-linux/usr/bin/arm-linux-gnueabihf-gdb
A questo punto hai il prompt dei comandi di gdb.
Configura gdb per leggere il file eseguibile (compilato per arm):
(gdb) file Debug_arm/MyApp
Configura gdb per leggere il core dump:
(gdb) target core core.MyApp.1139.1496822060
Ora puoi debuggare come se l'applicazione fosse crashata lanciandola da gdb. Ad esempio, puoi vedere il backtrace:
(gdb) bt