processo.
In genere i segnali vengono usati dal kernel per riportare situazioni
-eccezionali (come errori di accesso, eccezioni atritmetiche, etc.) ma possono
+eccezionali (come errori di accesso, eccezioni aritmetiche, etc.) ma possono
anche essere usati come forma elementare di comunicazione fra processi (ad
esempio vengono usati per il controllo di sessione), per notificare eventi
(come la terminazione di un processo figlio), etc.
essere perso o causare il comportamento originale (in genere la terminazione
del processo). Questa è la ragione per cui detti segnali sono chiamati
\textit{inaffidabili}, in quanto la ricezione del segnale e la reinstallazione
-del suo manipolatore non sono oiperazioni atomiche.
+del suo manipolatore non sono operazioni atomiche.
In caso di implementazione inaffidabile le chiamate di sistema non sono fatte
ripartire automaticamente quando sono interrotte da un segnale, per questo il
In caso di segnali \textit{reliable} invece il signal handler resta installato
quando viene chiamato e i problemi precedenti sono evitati. Inoltre alcune
-chiamate di sisteme possono essere fatte ripartire automaticamente e si può
+chiamate di sistema possono essere fatte ripartire automaticamente e si può
ottenere un'operazione di pausa atomica (usando la funzione POSIX
\texttt{sigsuspend}).
\label{sec:sig_types}
-In generale gli eventi che generano i segnali si possono diviedere in tre
+In generale gli eventi che generano i segnali si possono dividere in tre
categorie principali: errori, eventi e richieste esplicite.
Un errore significa che un programma ha fatto qualcosa di sbagliato e non può
\end{itemize}
Il programma può specificare queste scelte usano le due routine
-\texttt{signal} e \texttt{sigaction}; se si è installato un manipalatore sarà
+\texttt{signal} e \texttt{sigaction}; se si è installato un manipolatore sarà
quest'ultimo a intercettare il segnale ed ad essere eseguito, e mentre viene
eseguito (onde evitare race conditions) il segnale viene bloccato.
Se arriva un segnale per il quale non è stato specificata un'azione viene
utilizzata l'azione standard. Questa è diversa da segnale a segnale (come
-vedremo in \ref{sec:sig_standard}) ma per la maggior parte essa comporta la
-terminazione del processo, per alcuni che invece rappresentano eventi innoqui
+vedremo in \secref{sec:sig_standard}) ma per la maggior parte essa comporta la
+terminazione del processo, per alcuni che invece rappresentano eventi innocui
l'azione standard è di non fare nulla.
Quando un segnale termina un processo, il padre può determinare la causa della
violazioni di accesso) hanno anche la caratteristica di scrivere un file
\textit{core dump} che registra lo stato del processo prima della terminazione
e può essere esaminato da un debugger per investigare sulla causa dell'errore.
-Lo stesso avvine se i suddetti segnale vengono generati artificialmente con
+Lo stesso avviene se i suddetti segnale vengono generati artificialmente con
una \texttt{kill}.
Il numero totale di segnali presenti è dato dalla macro \texttt{NSIG}, e dato
che i numeri dei segnali sono allocati progressivamente, essa corrisponde
-anche al successivo del valore numerico assegnato al'ultimo segnale definito.
+anche al successivo del valore numerico assegnato all'ultimo segnale definito.
\subsubsection{Segnali di errore di programma}
-Questi segnali sono generati quando c'é un grave errore nel programma rilevato
-dal sistema o dallo stesso hardware. In generale indicano che il programma ha
-dei gravi problemi e l'esecuzione non può essere proseguita.
-
-Alcuni programmi usano questi segnali per riordinare le cose prima di uscire.
-As esempio ripristinare i settaggi della console, o eliminare i file di lock.
-In questo caso il manipolatore deve concludersi ripristinando l'azione di
-default e rialzando il segnale, così che il programma possa concludersi come
-se il manipolatore non ci fosse mai stato.
-
-L'azione di default per tutti questi segnali è causare la terminazione del
+Questi segnali sono generati quando il sistema, o in certi casi direttamente
+l'hardware (come per i page fault non valildi) rileva un qualche errore
+insanabile nel programma in esecuzione. In generale la generazione di questi
+segnali significa che il programma ha dei gravi problemi (ad esempio ha
+dereferenziato un puntatore non valido o ha eseguito una operazione aritmetica
+proibita) e l'esecuzione non può essere proseguita.
+
+In genere si intercettano questi segnali per permettere al programma di
+terminare in maniera pulita, ad esempio per ripristinare i settaggi della
+console o eliminare i file di lock prima dell'uscita. In questo caso il
+manipolatore deve concludersi ripristinando l'azione di default e rialzando il
+segnale, in questo modo il programma si concluderà senza effetti spiacevoli,
+ma riportando lo stesso stato di uscita che avrebbe avuto se il manipolatore
+non ci fosse stato.
+
+L'azione di default per tutti questi segnali è causare la terminazione del
processo che li ha causati. In genere oltre a questo il segnale provoca pure
la registrazione su disco di un \textit{core dump file} che viene scritto in
un file \texttt{core} nella directory corrente del processo al momento
-dell'errore.
+dell'errore.
Questi segnali sono:
\begin{itemize}
-\item \texttt{SIGFPE} Riporta un errore aritmetico fatale. Benchè il nome
+\item \texttt{SIGFPE} Riporta un errore aritmetico fatale. Benché il nome
derivi da \textit{floating point exception} si applica a tutti gli errori
- aritmetici comprea la divisione per zero e l'overflow.
+ aritmetici compresa la divisione per zero e l'overflow.
% Per questo segnale le cose sono complicate dal fatto che possono esserci
% molte diverse eccezioni che \texttt{SIGFPE} non distingue, mentre lo
% standard IEEE per le operazioni in virgola mobile definisce vaire eccezioni
% aritmetiche e richiede che esse siano notificate.
-\item \texttt{SIGFPE} Il nome deriva da \textit{illegal instruction}
-\item \texttt{SIGILL}
-\item \texttt{SIGSEGV}
+\item \texttt{SIGILL} Il nome deriva da \textit{illegal instruction},
+ significa che il programma sta cercando di eseguire una istruzione
+ privilegiata od inesistente, in generale del codice illegale. Poiché il
+ compilatore del C genera del codice valido si ottiene questo segnale se il
+ file eseguibile è corrotto o si stanno cercando di eseguire dei
+ dati. Quest'ultimo caso può accadere quando si passa un puntatore sbagliato
+ al posto di un puntatore a funzione, o si eccede la scrittura di un array di
+ una variabile locale, andando a corrompere lo stack. Lo stesso segnale viene
+ generato in caso di overflow dello stack o di problemi nell'esecuzione di
+ di un signal handler.
+
+\item \texttt{SIGSEGV} Il nome deriva da \textit{segment violation}, e
+ significa che il programma sta cercando di leggere o scrivere in una zona di
+ memoria protetta al di fuori di quella che gli è stata riservata dal
+ sistema. In genere è il meccanismo della protezione della memoria che si
+ accorge dell'errore ed il kernel genera il segnale.
+
+ È tipico ottenere questo segnale dereferenziando un puntatore nullo o non
+ inizializzatoo leggendo al di la della fine di un vettore.
+
\item \texttt{SIGBUS}
\item \texttt{SIGABRT}
\item \texttt{SIGTRAP}
projects / gapil.git / blobdiff