Memoria di utilizzo del problema in c

Question

Aiuto :) OS: Linux

Dove in "Sleep (1000);", in questo momento "Top (display Attività Linux)" Mi ha scritto il 7,7% dell'uso dell'MM. Valgrind: non trovato perdita di memoria.

Capisco, ha scritto correttamente e tutto il risultato di malloc è nullo. Ma perché in questo momento "dorme" il mio programma non è diminuito della memoria?Cosa manca?

Scusa per il mio pessimo inglese, grazie

generacodictagpre

~ # tmp_soft
For : Is it free??  no
Is it free??  yes
For 0 
For : Is it free??  no
Is it free??  yes
For 1 
END : Is it free??  yes
END 

.

Figura intera: TMP_SOFT.C

~ #top
  PID USER      PR  NI  VIRT  RES  SHR S %CPU %MEM    TIME+  COMMAND                                                                
23060 root      20   0  155m 153m  448 S    0  7.7   0:01.07 tmp_soft    

.

Answer 1

Se stai cercando di stabilire se il tuo programma ha una perdita di memoria, allora top non è lo strumento giusto per il lavoro (valrind è).

top mostra l'utilizzo della memoria come visto dal sistema operativo.Anche se chiami free, non vi è alcuna garanzia che la memoria libera sia tornata al sistema operativo.Tipicamente, non lo farebbe.Nondimeno, la memoria diventa "libera" nel senso che il tuo processo può usarlo per le allocazioni successive.

Modifica Se il tuo libc lo supporta, è possibile provare a sperimentare con M_TRIM_THRESHOLD .Anche se segui questo percorso, sarà difficile (un singolo blocco usato seduto vicino alla cima del mucchio impedirebbe tutta la memoria libera sotto di essa rilasciata al sistema operativo).

Answer 2

Per le buone ragioni, praticamente nessun allocatore della memoria restituisce i blocchi sul sistema operativo

---

.

La memoria può essere rimossa dal tuo programma in unità di pagine, e anche che è improbabile che sia osservato.

calloc (3) e malloc (3) Interagisci con il kernel per ottenere memoria, se necessario. Ma molto, pochissime implementazioni di libero (3) sempre la memoria di ritorno al kernel ^{1 , lo aggiungono solo a un elenco gratuito che calloc () e malloc () si consulterà più tardi per riutilizzare il riutilizzo del blocchi rilasciati. Ci sono buone ragioni per questo approccio di progettazione.}

Anche se un libero () voleva restituire la memoria al sistema, necessita di almeno una pagina di memoria contigua per ottenere il kernel per proteggere effettivamente la regione, quindi rilasciando un piccolo blocco porterebbe solo a un cambiamento di protezione Se fosse il piccolo blocco Ultimo in una pagina.

Teoria dell'operazione

SO MALLOC (3) Ottiene la memoria dal kernel quando ne ha bisogno, in definitiva in unità di multipli di pagina discreti. Queste pagine sono divise o consolidate come richiede il programma. Malloc e cooperare gratis per mantenere una directory. Coalesano i blocchi gratuiti adiacenti quando possibile per essere in grado di fornire blocchi di grandi dimensioni. La directory può o non può comportare l'utilizzo della memoria nei blocchi gratuiti per formare un elenco collegato. (L'alternativa è un po 'più condivisa-memoria e pagaging-friendly, e implica l'assegnazione della memoria in modo specifico per la directory.) MALLOC e GRATUITO hanno poco se una capacità di applicare l'accesso ai singoli blocchi anche quando viene compilato un codice di debug speciale e opzionale il programma.

---

.

^{1. Il fatto che pochissime implementazioni di GRATUITO () tentativo di restituire la memoria al sistema non è affatto a causa degli implementatori che si allentano.}

^{interagendo con il kernel è molto più lento di Basta eseguire il codice della biblioteca e il vantaggio sarebbe piccolo. La maggior parte dei programmi ha un impronta di memoria stazionaria o aumentando, quindi il tempo trascorso analizzato l'analizzazione dell'heap in cerca di memoria restituita sarebbe completamente sprecata. Altri motivi includono il fatto che la frammentazione interna rende improbabile i blocchi allineati dalla pagina che esistono, ed è probabile che il restituzione di un blocco fosse bloccato su entrambi i lati. Infine, i pochi programmi che restituiscono grandi quantità di memoria sono suscettibili di bypass in malloc () e semplicemente assegnare e assegnare comunque pagine.}

Answer 3

Generalmente libero () non conferisce alla memoria fisica al sistema operativo, sono ancora mappati nella memoria virtuale del processo.Se alloca un grosso pezzo di memoria, la libc può allocarla da mmap ();Quindi se lo gratis, LIBC può rilasciare la memoria in OS da MunMap (), in questo caso, in alto, verrà visualizzato il tuo utilizzo della memoria.

Quindi, se non si vuole rilasciare la memoria su OS esplicitamente, è possibile utilizzare MMAP () / MunMap ().

Answer 4

Quando la memoria free(), viene restituita al pool di memoria della Biblioteca standard C e non è restituito al sistema operativo. Nella visione del sistema operativo, come la vedi attraverso top, il processo è ancora "usando" questa memoria. All'interno del processo, la libreria C ha rappresentato la memoria e potrebbe restituire lo stesso puntatore da malloc() in futuro.

Lo spiegherò ancora un po 'con un inizio diverso:

Durante le chiamate a malloc, l'implementazione della libreria standard può determinare che il processo non ha abbastanza memoria assegnata dal sistema operativo. A quel tempo, la biblioteca effettuerà una chiamata di sistema per ricevere più memoria dal sistema operativo al processo (ad esempio, sbrk() o chiamate di sistema VirtualAlloc() su Unix o Windows, rispettivamente).

Dopo che la biblioteca richiede memoria aggiuntiva dal sistema operativo, aggiunge questa memoria alla sua struttura della memoria disponibile per tornare da malloc. Le chiamate successive a malloc useranno questa memoria finché non si esaurisce. Quindi, la biblioteca chiede al sistema operativo per una memoria ancora più.

Quando la memoria free, la libreria di solito non restituisce la memoria al sistema operativo. Ci sono molte ragioni per questo. Una ragione è che l'autore della biblioteca credeva di chiamare di nuovo malloc. Se non chiamerai di nuovo malloc, il tuo programma probabilmente finirà presto. Entrambe il caso, non c'è molto vantaggio per restituire la memoria al sistema operativo.

Un altro motivo che la Biblioteca non può restituire la memoria al sistema operativo è che la memoria del sistema operativo è assegnata in intervalli grandi e contigui. Potrebbe essere restituito solo quando un intero intervallo contiguo non è più in uso. Il modello di chiamare malloc e free non può cancellare l'intera gamma di utilizzo.

Answer 5

Due problemi:

.

• in make_cache_db(), la linea

  for (int i=0; i = n; i++)
  

  .

  dovrebbe probabilmente leggere

  for (int i=0; i<n; i++)
  

  .

  In caso contrario, assegnerà solo un singolo nodo cache_db_s.

• Il modo in cui stai assegnando cache_db in make_cache_db() sembra essere buggy.Sembra che la tua intenzione sia quella di restituire un puntatore al primo elemento della lista collegata;Ma poiché stai riassegnando cache_db in ogni iterazione del ciclo, finirai per restituire un puntatore all'elemento Ultimo dell'elenco.

  Se è successivamente libero l'elenco utilizzando free_cache_db(), questo ti farà perdere memoria.Al momento, tuttavia, questo problema è mascherato dal bug descritto nel punto di proiettile precedente, che ti fa allocare elenchi di lunghezza solo 1.

  Indipendente da questi bug, il punto sollevato da AIX è molto valido: la libreria runtime non è necessaria restituire tutta la memoria free()d al sistema operativo.