Newsgroup: it.comp.lang.c
Titolo: segmentation fault

chi mi spiega, gentilmente, cos'è un segmentation fault?

 chi mi spiega, gentilmente, cos'è un segmentation fault?
E` quando il programma cerca di accedere a memoria a cui non ha
accesso.
Per esempio, se ha allocato lo spazio 0x100 - 0x300 e poi prova a
mettere dei dati a 0x500, va in segmentation fault.
@ashland [~] $ dict 'segmentation fault' 
From Jargon File (4.2.3, 23 NOV 2000) [jargon]:
  segmentation fault n.  [Unix] 1. [techspeak] An error in which
  a running program attempts to access memory not allocated to it
  and {core dump}s with a segmentation violation error.  This is often
  caused by improper usage of pointers in the source code, dereferencing
  a null pointer, or (in C) inadvertently using a non-pointer variable as
  a pointer.  The classic example is:
 
        int i; scanf ("%d", i); /* should have used &i */
Ciao,
-- 
David N. Welton
   Consulting: 
http://www.dedasys.com/
Free Software: 
http://people.debian.org/~davidw/
   Apache Tcl: 
http://tcl.apache.org/
     Personal: 
http://www.efn.org/~davidw/

mettere dei dati a 0x500, va in segmentation fault.
Non e' detto.
Il segmentation fault si ha quando il "dolore" arriva
all'insopportabile, ma la soglia del dolore di un sistema
operativo potrebbe essere molto alta.
In generale, non e' detto che sforare i limiti di
allocazione della memoria (o quant'altro dia luogo ad un
comportamento indefinito) generi un segmentation fault.
--
Andrea Laforgia - walkietalkie(at)
libero.it
http://www.geocities.com/AndreaLaforgia

 generi un segmentation fault.
E`, appunto, un comportamento indefinito, ma comunque, la domanda era
"cos'e` un segmentation fault?", e, come ho detto, il segmentation
fault e` generato quando un programma prova ad accedere a mem a cui
non ha accesso.
-- 


 dovrebbe causare un segfault.
Solo  se il  kernel se  ne accorge. Ad  esempio, su  linux l'allocazione
della memoria avviene  in pagine da 4KB. Se tu  allochi 100B all'interno
del tuo programma,  il kernel assegna comunque 4KB di  memoria alle libc
(che si segnano che sono i  primo 100B sono allocati). Se a questo punto
"sfori" e leggi  un'area di memoria non allocata,  ma comunque contenuta
nella pagina gia` riservata, il kernel  non verra` interpellato e non si
accorgera` di nulla.
ciao
Kronos
-- 
Home: 
http://kronoz.cjb.net
La teoria e` quando sappiamo come funzionano le cose ma non funzionano.
La pratica e` quando le cose funzionano ma non sappiamo perche`.
Abbiamo unito la teoria e la pratica: le cose non funzionano piu` e non
sappiamo il perche`.

 kernel non verra` interpellato e non si accorgera` di nulla.
Test interessante per dimostrare questo:
#include <stdio.h>
int i = 0;
int main ()
{
    char bytes[100];
    bzero(bytes, 100);
    while (1) {
	bytes[i] = 'a';
	printf("%d\n", i);
	i ++;
    }
}
Su Linux PPC (2.4.4):
1015
Segmentation fault
Su MacosX PPC:
707
Segmentation fault
Su Linux i386 (2.2.18pre11):
807
Segmentation fault


non ha accesso.
Ci tengo a precisare che non hai detto questo.
Quella che citi *adesso* e' una condizione in cui si genera
*sicuramente* un errore di "segmentation fault", ma
affermare:
"Per esempio, se ha allocato lo spazio 0x100 - 0x300 e poi
prova a mettere dei dati a 0x500, va in segmentation fault."
Non e' la stessa cosa e non e' sempre vero.


Test interessante per dimostrare questo:
Be', il test che riporti e' tutt'altro che interessante, a
mio avviso.
Mi sembra quantomeno ovvio che accedendo all'infinito a
locazioni di memoria l'una di seguito all'altra, avrai
sicuramente un segmentation fault (perche' prima o poi
arriverai ad una zona protetta), ma questo non significa che
sforare i limiti di un array comporti necessariamente un


mio avviso.
Secondo me e' interessante per un motivo... anche negli
ambienti in cui e' presente la protezione di memoria
sperare che uscire da un array provochi necessariamente
un segfault e' troppo. In tutti i casi mostrati ci sono
un numero notevole di scritture fuori array che non
hanno creato problemi visibili e il segfault e' solo
saltato fuori ad un certo punto (e non lo stesso nei
vari ambienti).
Ci sono casi in cui un programma del genere potrebbe
scrivere la Divina Commedia (non inteso come una lunga
sequenza di numeri progressivi... proprio il testo
della Divina Commedia) perche' prima di superare i
limiti imposti dal sistema operativo si arrivano
a danneggiare i dati usati da printf.
Sempre per lo stesso motivo quel programma potrebbe
(anche in uno strasicuro ambiente unix protetto) cancellare
tutti i file che l'utente ha i permessi di cancellare
incluso il programma stesso invece di morire con un segfault
(si immagini che per la gestione FILE speciali si sono
usati puntatori a funzione per fare la lettura/scrittura...
sovrascrivendo quei puntatori anche la innocente chiamata
a printf potrebbe saltare *ovunque*).
Andrea
--
Andrea Griffini, Programmer
http://www.netservers.com/~agriff

 ha scritto nel messaggio
news:87sndgc...@dedasys.com...
