Sfondo
Il moderno hardware general purpose include una “unità di gestione della memoria” (o MMU). Questa caratteristica dell’hardware è usata dai sistemi operativi come Linux per implementare la protezione della memoria, cioè per prevenire che diversi processi accedano o modifichino la memoria degli altri (tranne che in modo strettamente controllato attraverso specifiche API). Questo semplifica la risoluzione dei problemi e aumenta la resilienza in quanto i processi sono accuratamente contenuti e separati l’uno dall’altro.
Un segnale di “violazione della segmentazione” viene inviato a un processo di cui l’unità di gestione della memoria ha rilevato un tentativo di utilizzare un indirizzo di memoria che non gli appartiene.
Cause comuni: errore di programmazione
Se un processo cerca di accedere alla memoria attraverso un puntatore che non è stato correttamente inizializzato, o che punta alla memoria che è stata precedentemente deallocata, questo probabilmente risulterà in un segfault. In questo caso, il segfault si sta verificando con un processo o un binario specifico, forse in un insieme specifico di circostanze.
Per affrontare questo tipo di segfault, iniziate ad applicare tutti i service pack e gli aggiornamenti di manutenzione pertinenti. Successivamente, se il problema è ancora riproducibile con il codice corrente, provate a catturare un core dump dell’applicazione per l’analisi. I dettagli si trovano nel TID 3054866 – How to obtain application core dump.
Se il binario problematico è fornito da Novell come parte del prodotto, aprite una richiesta di assistenza con i servizi tecnici Novell, fornendo
- una descrizione delle circostanze in cui il core dump è stato generato,
- un rapporto supportconfig -v per il sistema interessato (pagina iniziale di supportconfig), e
- il file core dump stesso, se più piccolo di 50 MB. Se è più grande, aspetta che la richiesta di servizio sia assegnata ad un ingegnere e poi lavora con l’ingegnere per trasferirla.
Se il binario problematico è stato fornito da una terza parte, contatta il dipartimento di supporto di quella parte per assistenza.
Cause comuni: binari e librerie non corrispondenti
I guasti possono verificarsi con processi che combinano binari e librerie condivise che non sono (pienamente) compatibili. Questo può accadere, per esempio, quando una libreria viene aggiornata in un modo che cambia l’ABI (application binary interface) della libreria, ma il numero di versione interno della libreria non viene aggiornato per riflettere questo. Un binario che è stato costruito con una versione più vecchia della libreria può iniziare a fare segfault quando viene caricato con la versione più recente.
Questo caso può essere difficile da riconoscere, e non c’è una lista di passi per affrontarlo. Quando si sospetta questo caso, alcune cose da considerare sono:
- Controllare il sistema per la corruzione dei file (ad esempio utilizzando il file rpm-verify.txt in un rapporto supportconfig -v)
- Controllare le impostazioni del sistema che riguardano le librerie condivise, come i file di configurazione /etc/ld.so.conf e /etc/ld.so.conf.d/* e le variabili di ambiente LD_LIBRARY_PATH e LD_PRELOAD.
- Utilizzando lo strumento objdump per controllare il binario per un override del percorso di ricerca della libreria integrata (RPATH).
Causa comune: problema di hardware o di configurazione hardware
Quando i segfault si verificano frequentemente, o con diversi processi o senza un chiaro schema, questo può indicare che l’hardware di un sistema (sottosistema di memoria) è problematico, o che le impostazioni di configurazione di basso livello sono inappropriate. Fate riferimento a TID 3301593 – Il sistema Linux si blocca o è instabile per maggiori informazioni su come gestire questa situazione.