Nel corso degli anni ho scritto a lungo su come risolvere i problemi relativi al software nel mondo IT in generale e in Linux in particolare. Dopotutto, questo è stato il mio pane quotidiano per molto tempo e sono ancora piuttosto appassionato dell'arte della risoluzione dei problemi. Uno degli argomenti che ho trattato copiosamente è gdb, il debugger software per eccellenza. L'unico problema è che devi eseguire innit per vincere.
Cosa intendo con questo:gdb è eccellente se riesci a riprodurre i tuoi problemi. Ma se esegui il software in una configurazione di produzione, potresti non avere il lusso di continuare ad attivare problemi più e più volte. La capacità di catturare e quindi riprodurre i bug è una grande risorsa, e si presenta sotto forma di RR, uno strumento progettato per aiutare a eseguire il debug delle esecuzioni registrate di software in modo preciso e deterministico. Vediamo cosa regala.
Rpronto, fisso, impostato
In sostanza, RR è gdb e gdb è RR. L'idea è semplice e la realizzazione elegante. Esegui il tuo strumento con rr, catturi l'esecuzione (e l'errore), quindi riproduci la registrazione tutte le volte che vuoi, lontano dall'ambiente di produzione. Inoltre, se ci sono problemi sfuggenti, potresti essere in grado di afferrare uno scenario ripetibile, che ti consente di capire più rapidamente la causa principale e risolvere il problema.
Ho installato e configurato RR in Fedora 32. Abbastanza semplice. Ora, l'esecuzione richiede una certa attenzione ai dettagli. Se esegui il programma come utente normale, potresti visualizzare un avviso che RR non può effettivamente acquisire eventi privilegiati del kernel. Puoi cambiarlo e quindi non hai bisogno di sudo. Simile a quello che abbiamo visto con perf davvero. Dolce.
rr record ./seg
rr ha bisogno di /proc/sys/kernel/perf_event_paranoid <=1, ma è 2.
Cambialo in 1 o usa 'rr record -n' (lento).
Considera di inserire 'kernel.perf_event_paranoid =1' in /etc/sysctl.conf
Ci sono molti modi in cui puoi cambiarlo. Cattura un valore in /proc, usa sysctl -w per scrivere il valore, modifica manualmente il file /etc/sysctl.conf e quindi ricarica la configurazione. In qualunque modo tu scelga, avrai prestazioni migliori e la possibilità di tracciare tutti gli eventi necessari.
sudo sysctl -w kernel.perf_event_paranoid=1
Esempio di errore di segmento
Per vedere quanto sia pratico e utile RR, ho deciso di utilizzare lo stesso esempio segfault del tutorial gdb. Fondamentalmente, un ciclo con malloc() che porterà a un errore di segmentazione:
#include
#include
main()
{
int *pointer;
int i;
puntatore =malloc(sizeof(int));
for (i =0; 1; i++)
{
pointer[i]=i;
printf("puntatore[%d] =%d\n", i, puntatore[i]);
}
ritorno(0);
}
gcc -g seg.c -o seg
seg.c:4:1:avviso:il tipo restituito è impostato su 'int' [-Wimplicit-int]
4 | main()
| ^~~~
Registrazione RR e riproduzione RR
Le due funzioni principali utilizzate da RR:registra e riproduci.
rr record ./seg
...
pointer[33621] =33621
pointer[33622] =33622
pointer[33623] =33623
Errore di segmentazione (core scaricato)
Tieni presente che l'esecuzione effettiva sarà più lenta del solito. Ciò significa che se si verificano problemi dipendenti dal tempo, RR potrebbe non essere utile. Abbastanza simile a quello che abbiamo visto con strace davvero. Vuoi problemi deterministici che possono essere replicati in modo affidabile (nelle giuste condizioni, cioè).
Ad ogni modo, una volta registrato il problema, possiamo riprodurlo:
rr riproduci
La prima volta che RR è stato caricato, mi ha avvertito che i simboli di debug non erano disponibili:questo è abbastanza importante se vuoi davvero essere in grado di risolvere il problema. Non è in alcun modo specifico di RR, ma questo è qualcosa da tenere in considerazione:puoi installare i pacchetti mancanti se lo desideri, il programma elenca anche il comando esatto che puoi utilizzare per farlo.
Debug remoto tramite 127.0.0.1:7747
Lettura di simboli da /lib64/ld-linux-x86-64.so.2...
(Nessun simbolo di debug trovato in /lib64/ld-linux-x86 -64.so.2)
0x00007f25ce73e110 in _start () da /lib64/ld-linux-x86-64.so.2
Informazioni di debug separate mancanti, utilizzare:dnf debuginfo-install glibc-2.31-2 .fc32.x86_64--Digitare
Una volta caricata l'interfaccia RR, sei nella terra di gdb. I comandi sono gli stessi. Puoi impostare punti di interruzione e quindi utilizzare le condizioni per quando tali punti di interruzione devono essere effettivamente attivati e l'esecuzione dell'attività interrotta.
pausa 10
condizione 1 i ==33610
continua
E la sessione di debug sarà simile a:
(rr) next
pointer[33611] =33611
9 for (i =0; 1; i++)
(rr) next
11 pointer[i]=i;
(rr) next
Segnale ricevuto programma SIGSEGV, Errore di segmentazione.
0x000000000040116a in main () in seg.c:11
11 pointer[i]=i;
Ora puoi approfondire ed eseguire ulteriori controlli. La differenza principale è che tutto ciò si verifica su un'istanza registrata del tuo software, quindi non interferisci potenzialmente con l'utilizzo effettivo dei tuoi servizi e applicazioni. Idealmente, hai bisogno di una configurazione intelligente in grado di rilevare automaticamente i problemi e registrarli, ma questa è tutta un'altra storia.
Conclusione
Non ho passato troppo tempo a usare RR, ma mi piace quello che vedo. Il programma utilizza i fondamenti familiari e solidi di gdb, il che significa che non è necessario reimparare la risoluzione dei problemi di Linux da zero. Inoltre, aggiunge un livello di potente flessibilità, consentendo di ridurre al minimo la pressione del tempo che è spesso associata a problemi IT, come l'arresto anomalo del software. Puoi registrare e riprodurre a tuo piacimento. Ciò significa anche che è più probabile che tu trovi il problema, soprattutto se hai a che fare con lunghe e complicate esecuzioni di attività.
Spero che troverai utile questo breve tutorial. In un mondo in cui ci sono dieci chef per ogni pasto e cinquanta strumenti Linux ridondanti per ogni esigenza, è bello vedere un software che offre funzionalità extra significative piuttosto che un rimaneggiamento dello stesso vecchio. Bene, ora hai un'altra utility nel tuo arsenale, il che significa anche una scusa in meno per non essere in grado di risolvere quei fastidiosi problemi software abbastanza rapidamente. È così che funziona, no.