Newsgroup: it.comp.os.linux.development
Titolo: Linux tollerante?

Ciao raga' ultimamente mi capitano cose un po' strane...
Sto sviluppando un po' su linux e un po' su Nt (con cygwin..) e mi sto'
rendendo conto che (a parita' di bug.. :) su Linux tutto sembra girare bene,
mentre su Nt ricevo errori (l'applicazione ha eseguito....).
In effetti a volte anche su linux ricevo segmentation fault...ma mooolto
raramente!
Sara' che linux e' piu' tollerante verso programmi che scrivono dove
vogliono in memoria o mi sbaglio?
--
---
Alessandro >>CoMiX<< Cominu
e-mail: 
aco...@tiscalinet.it
Icq: 116354077
Linux User # 203765
[That's not a bug, that's a feature..]

vogliono in memoria o mi sbaglio?
Sbagli.
-- 
"Unix is user friendly, it's just selective 
about who its friends are."

vogliono in memoria o mi sbaglio?
Se e' cosi' e' un guaio.
I crash nei programmi sono d'aiuto per il programmatore, se
il sistema operativo me li nasconde, non mi vuole bene.
Io credo che faresti bene a rivedere il tuo codice.
--
Andrea Laforgia (mica uno qualunque...)

 Io credo che faresti bene a rivedere il tuo codice.
Certo che e' un guaio...soprattutto quando usare il debug e' difficile o
impossibile! (troppi thread!!!)
Rivedere il codice?certo...
xo' molte volte mi capitava di fare uso di char* senza allocare memoria x
loro... beh, li usavo, li riusavo, li usavo ancora...e nulla!
Tutto bene, trannr qualche volta..
Su win invece esplodeva(giustamente) sempre!
Non voglio difendere win (che odio) xo' sta' cos non mi va' giu'!
Che ne pensi?


Non voglio difendere win (che odio) xo' sta' cos non mi va' giu'!
L'allocazione da parte di libc avviene a pagine di 4k (su x86, gli altri
non so). Per cui, quando chiedi spazio per 1 byte tramite malloc:
- libc chiede al kernel una pagina; 
- il kernel la concede;
- libc si segna che il primo byte di quella pagina e' usato da te, e ti
  restituisce l'indirizzo di questo byte;
La volta successiva, quando chiederai 33 byte, libc ti assegnera' il
blocco 2-34 di quella stessa pagina, quindi il kernel nulla sa di quanto
stai facendo.
Ora, se tu prendi l'indirizzo del primo byte di questa pagina, e lo
incrementi di 200, scriverai sempre all'interno della stessa pagina,
quindi non saranno generate eccezioni.
Quindi, quello che conta e' se tu, scegliendo un indirizzo fosse pure a
caso, cadi nello spazio di indirizzamento del processo oppure no,
perche' se ci cadi il kernel non viene richiamato.
Questo in un mondo molto semplificato, in un mondo reale libc (o la sua
versione sotto Windows), potrebbe fare dei sanity check ogni volta che
giochi con i puntatori.
Questo sempre che non ci siano altre faccende (librerie, ambienti di
sviluppo) a spiegare la differenza.


 stai facendo.
[SNIPPONE]
quindi il maledetto "segmentation fault" viene lanciato dal kernel, e solo
se scrivo in un indirizzo non valido in una pagina non associata al mio
processo?!
Beh, se e' cosi ritiro le mie accuse a linux.. :)


Che ne pensi?
Che faresti bene ad allocare memoria.


al mio processo?!
Se chiedi di leggere il contenuto di una pagina che non appartiene a ecc..


 processo?!
Right. Ne' il linguaggio C ne' le funzioni di allocazione della libc
fanno dei controlli su dove vai a scrivere quando lavori con la
memoria allocata dinamicamente (beh, non e' proprio del tutto
vero [*]...).
E' il kernel ad arrabbiarsi quando esci dal tuo orticello... ma
ovviamente se il tuo puntatore impazzito punta ancora all'interno
dello heap assegnato al tuo processo, il kernel non si accorge di
nulla.  Se vuoi conoscere nel dettaglio il modo in cui la memoria
viene allocata nello heap, ti consiglio di leggere l'articolo
0x08 di phrack magazine #57 (
www.phrack.org
).
[*] in realta' la libc permette di abilitare dei controlli minimali
per il debugging (che di default sono disabilitati). Uno banale e'
quello di settare la variabile d'ambiente MALLOC_CHECK_ a 1 o a 2
(man malloc), comodissimo perche' funziona a run-time su qualsiasi
programma, non servono opzioni di compilazione particolari.
Poi ti suggerisco di fare un 'info libc', andare nella sezione
'memory allocation' e leggere la documentazione riguardante mtrace()
e i vari hook (__malloc_hook(), __free_hook() ecc.)
-- 
addio, e grazie per tutto il pesce

> vogliono in memoria o mi sbaglio?
AL> Se e' cosi' e' un guaio.
Il  problema è  un'altro, tranquillizzati,  ed è  la robustezza  di di
cygwin che è molto minore di quella di Linux. Ci sono vari problemi in
quel runtime, anche se è di gran lunga meglio di niente.
--
Gian Uberto| main(){printf(&unix["\021%six\012\0"],(unix)["have"]+"fun"-0x60);}
Lauri      |                        David Korn, 1987 ioccc best one liner 
(aka saint)|-------------------------------------------------------------------
em@ail: 
sa...@eng.it
 ( vedere X-nospam nello header - see X-nospam in header )