Pagina 1 di 2 1 2 ultimoultimo
Visualizzazione dei risultati da 1 a 10 su 12
  1. #1
    Utente di HTML.it L'avatar di Ed_Bunker
    Registrato dal
    Jul 2003
    Messaggi
    1,119

    [C] Saturazione dell'heap ?

    Ho fatto uno stupido programmino in C che non faceva altro che chiamare in continuazione la funzione malloc in modo da allocare dinamicamente lo spazio per una certa struct nell'heap.
    La mia intenzione era quella di "stampare" il totale di mem allocata nel momento in cui il valore di ritorno della malloc era NULL e errno valeva ENOMEM.

    Cio' pero' non e' accaduto.
    Ad un certo punto l'app e' stata killata dal s.o. ed a video (Su shell) e' comparso il messaggio "killed".

    In base a cosa il processo e' stato killato ?
    Esiste un numero di bytes massimo che ciascun processo puo' allocare sull'heap ?

    Rinfrescatemi bene la mem.. perche ne' ho bisogno...
    :berto:

  2. #2
    Utente di HTML.it L'avatar di oregon
    Registrato dal
    Jul 2005
    residenza
    Roma
    Messaggi
    36,480
    Con Linux, in una situazione di fallita allocazione di memoria, interviene un processo (OOM killer) che termina il processo che ha fatto la richiesta di memoria.

    Questo processo non c'e' in Windows.
    No MP tecnici (non rispondo nemmeno!), usa il forum.

  3. #3
    Utente di HTML.it L'avatar di Ed_Bunker
    Registrato dal
    Jul 2003
    Messaggi
    1,119
    Ok, cio' che volevo sapere e' se a priori ciascun processo puo' sapere quanto spazio poter allocare sull'heap ovvero e di conseguenza quanto "memory leak" si puo' in teoria permettere.

    Ho notato, poi, che dopo aver fatto una free il puntatore e' ancora valido ed e' possibile riassegnare la variabile che esso punta.

    Questo vale "sempre" o come mi sembra di capire dal man dipende dalla gestione della mem da parte del s.o. ?

    Questo il banale codice di esempio:

    codice:
    #include <stdio.h>
    #include <stdlib.h>
    
    struct prova
    {
    int val;
    struct prova *next;
    };
    
    int main()
    {
    
    /*Alloca*/
    struct prova* first = malloc(sizeof(struct prova));
    
    /*Assegna*/
    first->val = 5;
    first->next = NULL;
    
    printf ("Before free: %d\n", first->val);
    
    /*Libera*/
    free(first);
    printf ("After free: %d\n", first->val);
    
    /*Riassegna*/
    first->val = 10;
    printf ("After an assignment post-free: %d\n", first->val);
    
    return(0);
    }
    Se invece di fare la free effettuo un assegnamento del puntatore a NULL allora nell'istruzione successiva di assegnamento ottengo, "giustamente", un SIGSEGV.

  4. #4
    Utente di HTML.it L'avatar di oregon
    Registrato dal
    Jul 2005
    residenza
    Roma
    Messaggi
    36,480
    Dopo la free il puntatore NON e' valido. Fai attenzione.
    No MP tecnici (non rispondo nemmeno!), usa il forum.

  5. #5
    Utente di HTML.it L'avatar di Ed_Bunker
    Registrato dal
    Jul 2003
    Messaggi
    1,119
    Originariamente inviato da oregon
    Dopo la free il puntatore NON e' valido. Fai attenzione.
    Devo essermi spiegato male...

    SO che dopo la free il puntatore NON DOVREBBE essere valido.
    Eppure quel programma NON GENERA segmentation fault.

    Nonostante io faccia un allocazione ed un riferimento al valore puntato DOPO aver fatto la free.

    Cio' che volevo sapere e' se questo e' un comportamento che dipende dalla "particolare" gestione della memoria da parte del s.o. che si occupa di "recuperare" la memoria "freed" come e quando gli pare.

  6. #6
    Utente di HTML.it L'avatar di oregon
    Registrato dal
    Jul 2005
    residenza
    Roma
    Messaggi
    36,480
    Dopo una free il valore del puntatore non e' piu' LOGICAMENTE valido.

    Ovvero, subito dopo la free, probabilmente, puo' essere ancora utilizzato perche' la memoria a cui punta e' ancora mappata nel processo ma NON e' cosi' in generale perche' il sistema operativo puo' decidere IN QUALSIASI MOMENTO di rendere NON VALIDA quella porzione di memoria e il relativo puntatore.

    In generale, dopo la free, e' bene porre il puntatore = NULL per evitare questo tipo di problemi.
    No MP tecnici (non rispondo nemmeno!), usa il forum.

  7. #7
    Utente di HTML.it L'avatar di Ed_Bunker
    Registrato dal
    Jul 2003
    Messaggi
    1,119
    Ecco ora ci siamo.

    Come mi sembrava di aver "presunto" dipende dalla particolare gestione del s.o.

    Cio' che mi "sorprende" non e' il fatto che la memoria gia' "liberata" sia ancora accessibile quanto, invece, che sia ancora modificabile.

    Il che pensavo diventasse impossibile non appena veniva effettuata la free.

  8. #8
    Stiamo parlando di dangling pointers, o sbaglio?
    "Se riesci a passare un pomeriggio assolutamente inutile in modo assolutamente inutile, hai imparato a vivere."

  9. #9
    Utente di HTML.it L'avatar di oregon
    Registrato dal
    Jul 2005
    residenza
    Roma
    Messaggi
    36,480
    Originariamente inviato da pallinopinco
    Stiamo parlando di dangling pointers
    Esatto ...

    Originariamente inviato da Ed_Bunker
    Il che pensavo diventasse impossibile non appena veniva effettuata la free.
    No ... assolutamente ... la free indica soltanto al SO (scrivendo in strutture collegate al processo) che quell'area di memoria NON e' piu' posseduta dal processo, ma non fa nulla relativamente alla presenza della pagina in memoria o alla sua possibile utilizzazione in lettura/scrittura (di questo se ne occupa il sistema operativo quando si accorge che e' necessario "recuperare" pagine allocate per altri processi che ne fanno richiesta).
    No MP tecnici (non rispondo nemmeno!), usa il forum.

  10. #10
    Utente di HTML.it L'avatar di Ed_Bunker
    Registrato dal
    Jul 2003
    Messaggi
    1,119
    In "sostanza" e' come dire al gestore della mem: quella parte di mem non mi serve piu', fanne cio' che vuoi ?!?

Permessi di invio

  • Non puoi inserire discussioni
  • Non puoi inserire repliche
  • Non puoi inserire allegati
  • Non puoi modificare i tuoi messaggi
  •  
Powered by vBulletin® Version 4.2.1
Copyright © 2025 vBulletin Solutions, Inc. All rights reserved.