Newsgroup: it.comp.os.dibattiti
Titolo: memoria sotto gli *altri-* S.O.

Mi sto occupando di memoria virtuale per motivi di curiosita' professionale.
La mia sistemista unix di fiducia mi ha sconvolto con la notizia di una
versione speciale della malloc che riesce a beccare codice del tipo:
char pippo[1];
strcpy(pippo, "Quack");
Io sono rimasto sconvolto.
"Ma come fa? Allora la memoria non e' paginata in Unix. Come fate allora con
lo swap file, ve lo gestite a mano?"
Lei mi dice che probabilmente e' paginata, che non se lo ricorda bene, ma se
e' paginata (sostengo io) è impossibile allocare meno di una pagina.
La sua risposta e' stata che in Unix se vuoi non sprechi un byte. La cosa
non mi convince. Come afermazione e' un atto di fede.
Come funziona la gestione della memoria in Unix, e negli altri S.O.?
+++
E' meglio che mi sposti a fare queste domande in it.comp.c++?
--- (Elimina il papero per le repliche) ---

 E' meglio che mi sposti a fare queste domande in it.comp.c++?
Direi di no.
Per quello che riguarda malloc e bound check, questo e' quello
che dice la man malloc (Linux RH 5.1 - altri OS dicono altre
cose, ovviamente):
NOTES
       Crashes in malloc(), free() or realloc() are almost always
       related  to  heap corruption, such as overflowing an allo-
       cated chunk or freeing the same pointer twice.
       Recent versions of Linux libc (later than 5.4.23) and  GNU
       libc  (2.x)  include a malloc implementation which is tun-
       able via environment  variables.   When  MALLOC_CHECK_  is
       set,  a  special  (less  efficient) implementation is used
       which is designed to be tolerant  against  simple  errors,
       such  as double calls of free() with the same argument, or
       overruns of a single byte (off-by-one bugs).  Not all such
       errors  can be proteced against, however, and memory leaks
       can result.  If MALLOC_CHECK_ is set to  0,  any  detected
       heap  corruption is silently ignored; if set to 1, a diag-
       nostic is printed on stderr;  if  set  to  2,  abort()  is
       called  immediately.  This can be useful because otherwise
       a crash may happen much later, and the true cause for  the
       problem is then very hard to track down.
 
Cheers,
	Alessandro
-- 
One standard to rule them all, one standard to find them,
One standard to bring them all, and in darkness bind them.
In the land of Microsoft, where the Shadow lie.
Alessandro Forghieri              
http://www.orion.it/~alf

 lo swap file, ve lo gestite a mano?"
....
Probabilmente si riferisce ad un pacchetto per il controllo dello "sforamento"
dei ptr che rimpiazza alcune funzioni standard per la gestione del pool di
memoria facente riferimento a malloc()/free().
Queste funzioni modificate inseriscono dei checksum o codici di controllo 
prima dell'inizio e dopo la fine del buffer allocato in modo da poter facilmente
riconoscere problemi di buffer over/underrun ALL'ATTO del free(). Cioe' il
tutto viene segnalato solo quando si dealloca il blocco o al massimo quando
si esegue un controllo specifico con un walking della lista dei buffer allocati.
Il tutto avviene a livello di sorgente o al massimo a livello di link con la
libreria in questione, non presuppone in nessun modo l'intervento del s.o. ed 
ovviamente e' implementabile per qualsiasi sistema.
Ciao
Vincenzo Valvano

Io sono rimasto sconvolto.
Anch'io, sono perlomeno 10 minuti che sono inebetito davanti al monitor a 
chiedermi : "ma che cazzo vuol dire ``una versione speciale della malloc 
che riesce a beccare codice del tipo:''????"
-- 
Warning!
Don't send any mail for me at my from: or replayto: addresses ;
I just kill the mail over there without reading!

papero...@tin.it
 wrote:
 >La mia sistemista unix di fiducia mi ha sconvolto con la notizia di una
 >versione speciale della malloc che riesce a beccare codice del tipo:
 >char pippo[1];
 >strcpy(pippo, "Quack");
Ci sono sia compilatori con il bound checking che librerie speciali da
linkare ai propri programmi che con dei trucchi della MMU fanno queste
cose.
 >"Ma come fa? Allora la memoria non e' paginata in Unix. Come fate allora con
Linux usa pagine di 4 KB e in certi casi di 4 MB (funzione non
documentata dei processori intel).
 >La sua risposta e' stata che in Unix se vuoi non sprechi un byte. La cosa
Per quanto riguarda i dettagli dell'allocazione ti consiglio di guardare
i sorgenti di malloc.
-- 
ciao, | [Per rispondere togli "toglimi" dal mio indirizzo.]
Marco | * The Internet is full. Go away.  -- Joel Furr *

 non mi convince. Come afermazione e' un atto di fede.
per avere un controllo perfetto (o quasi..), 
l'unica soluzione e` utilizzare anche la segmentazione ...
ho provato:
void main() { char pippo[1]; strcpy(pippo, "Quack"); }
. ed in effetti ho ricevuto un SIGSEGV.
sono rimasto abbastanza stupito .. ma basta pensare che pippo 
e` allocato nello stack (non con malloc..) ed anche se viene allineato
a 4 byte, Quack e` 5 caratteri percio` va a modificare l'indirizzo
di ritorno (o altre cose sullo stack).
ho provato ad usare pippo = (char*)malloc(1); ed ovviamente non ho
ricevuto nessun errore.
sara` una qualche versione di malloc con debug, che esiste anche per win
-- 
Ranger, togli .fr dal mio indirizzo per rispondere
http://ranger-rg.home.ml.org/

documentata dei processori intel).
4Mb ??
E poi sulle altre piattoforme come fa a funzionare ?
In che parte del codice utilizza pagine da 4 Mb ?

krei...@usa.net
 wrote:
 >> >"Ma come fa? Allora la memoria non e' paginata in Unix. Come fate allora con
 >>Linux usa pagine di 4 KB e in certi casi di 4 MB (funzione non
 >>documentata dei processori intel).
 >4Mb ??
 >E poi sulle altre piattoforme come fa a funzionare ?
Non le usa, esattamente come fa con i 486.
 >In che parte del codice utilizza pagine da 4 Mb ?
Per mappare cose in kernel space, ma non ricordo i dettagli.


 Io sono rimasto sconvolto.
io no capisco la tua domanda??? dove interviene la malloc in questo spezzone
di codice??
-- 
________________________________________________________________
Luca Di Taranto                             dita...@zappami.tin
to email me, please, remove "zappami" and add ".it" after ".tin"

 In che parte del codice utilizza pagine da 4 Mb ?
per quanto ne so le usa solo in /i386/mm/init.c, cioe` al boot.
(comunque la feature e` stata documentata con PPRO)


       called  immediately. 
Se fosse possibile vorrei vedere il codice che fa il check. La corruzione
dell'heap che fa il runtime del C del VC non l'ho capita. Si limita a
richiamare una funzione del S.O. Ma non credo che il S.O. operativo abbia
potere divinitario, o che controlli il singolo byte. Altrimenti che memoria
paginata sarebbe?


i sorgenti di malloc.
Dovrei capire dove sono. Ho avuto problemi con il mio computer ultimamente
(colpa mia tra l'altro n.d.p.). E' un miracolo se non mi sono perso i dati,
ma l'installato l'ho perso.
Non ho voglia di reinstallare Linux, sono ancora dietro a riconfigurare i
programmi sotto NT (e sara' lunga).


 non presuppone in nessun modo l'intervento del s.o. 
ergo cui
ptr = (char*) malloc(byte)
strcpy(ptr + sizeof(checksum), "quack");
e' possibile a priori.
che dire poi di:
//codice quasi corretto altrimenti qui ti mettono in croce
ptr = (char*) malloc(sizeoff(char));
//dimensione_giusta = dimensione massima  per non avere page foult
ptr_carogna = (char*) malloc(dimensione_giusta);
memcpy(ptr_carogna, ptr, dimensione_giusta);
for(int i = 0; (i = i + sizeof(char) * 6) < dimensione_giusta; )
	memcpy(ptr + i, "Quack");
memcpy(ptr, ptr_carogna, dimensione_giusta);
free(ptr);
free(ptr_carogna);
nessun errore a run time?


On Wed, 26 Aug 1998 19:45:27 GMT, 
papero...@tin.it
 (Davide Quack) wrote:
codice testato
#include <windows.h>
#include <winbase.h>
void main()
{
	int* piPapero = NULL;
	BOOL iRis = FALSE;
	//impegno una pagina (che mi piaccia o no)
	piPapero = (int*)VirtualAlloc(NULL, sizeof(int), MEM_RESERVE,
PAGE_READWRITE );
	//l'alloco fisicamente
	piPapero = (int*)VirtualAlloc(piPapero, sizeof(int), MEM_COMMIT ,
PAGE_READWRITE );
 
	//tutto ok
	*piPapero = 1234;
	//tutto ok, ma non dovrebbe (vedi discorso delle pagine)
	*(piPapero + 1) = 5678;
	//disimpegno la memoria fisica
	iRis = VirtualFree(piPapero, sizeof(int), MEM_DECOMMIT);
	//disimpegno la memoria virtuale
	iRis = VirtualFree(piPapero, 0, MEM_RELEASE);
	//crash	
	*piPapero = 0; 
}
Non ho usato funzioni del run-time C. Solo del sistema operativo NT. Il
sistema operativo usa pagine per i processi in user space. Che piaccia o non
piaccia. La malloc non puo' andare oltre questa realta'.
Esistono S.O. per cui *(piPapero + 1) = ..; da errore?
Esistono S.O. che non allocano pagine per i i processi in user space?
Se esistono come gestisco lo swap file e quindi la memoria virtuale?
++++
Non ho la piu' pallida idea di come si allochi memoria in Linux, non credo
con malloc visto che e' una funzione standard del C, e non del generico
S.O.. Ammesso e non concesso che sia malloc, cosa succede quando la invoco?
Alloco veramente solo quello che ho richiesto?


 dell'heap che fa il runtime del C del VC non l'ho capita.
[...]
Qui non ho linux, ma penso che altri potranno inviarti malloc.c
Cheers,
	ALessandro

 ptr = (char*) malloc(sizeoff(char));
Whoops.
... unresolved external: sizeoff
 
;-)
Cheers,
	Alessandro

Qui non ho linux, ma penso che altri potranno inviarti malloc.c
Se riesco a ricordarmi dove ho messo il CD con il Cignus, e  quando avro'
piu' tempo, ci guardero' io, senza bisogno di Linux.


tifo e dal disprezzo per il resto del mondo (piu' di NT odia l'AS).
Si odia cio' che non si conosce e di cui si ha paura...dille che l'AS
non morde...
Obelix

dille che l'AS non morde...
Pare che RPG in compenso abbaia. Comunque adesso lavora (anche) su NT.
Praticamente (dal suo punto di vista) ha peggiorato le condizioni di lavoro.


Pare che RPG in compenso abbaia. 
Tze'. RPG e' un linguaggio comodissimo, privo dei fronzoli di tutta
sta robaccia moderna !!!  :-)) 
e,soprattutto, permette uno sviluppo fulmineo...  :-))
Obelix

Tze'. RPG e' un linguaggio comodissimo,
Ho pagato la mia tassa mensile alla UTET e mi sono comprato il Tanenbaum sui
S.O. e Minix. Ovviamente mi sono precipitato sulla parte della gestione
della memoria (mio interessere attuale).
Mi e' venuto il dubbio che la gestione della memoria dell'AS400 sia in
controtendenza rispetto agli altri S.O.. Sia la mancanza di stack in RPG,
che l'uso massiccio dei Job, mi fa pensare che l'AS sia una scheggia con i
programmi di cui e' noto a priori il consumo di memoria, ma in contropartita
non sia un gran che con i programmi che usano in modo dinamico la memoria.
Il che spiegherebbe perche' i compilatori C/C++ pare siano delle immonde
schifezze sotto AS (presuno delle malloc e new molto lente a questo punto).
Per ora sono solo ilazioni naturalmente.
Sai qualcosa sulla gestione della memoria su AS? Se esiste l'indirizzamento
separato per i processi, la mia teoria va (in parte) a pallino. 


separato per i processi, la mia teoria va (in parte) a pallino. 
Ahem?? Sono appena tornato dalle ferie... esplicita meglio il
concetto....
Obelix

 esplicita meglio il concetto....
Si basa su una supposizione. Con un linguaggio di sviluppo che
sostanzialmente (se ho ben capito) non ti permette allocazione dinamica
della memoria, e uso dello stack, puoi permettere di usare uno diverso modo
di allocare la memoria.
Il goal e' che in un sistema simile puoi allocare dei processi in un insieme
di job alla perfezione, in quanto prima di farli partire sai esattamente
quanta memoria useranno (e quante risorse in genere).
+++
Poi AS400 sara' il S.O. a memoria paginata. Qui nessuno inventa nulla di
veramente nuovo.
