Quanto è importante riparare le perdite di memoria?


19

Ho scoperto da Valgring che alcuni programmi GTK + perdono memoria. Quanto è importante riparare quelle perdite? Voglio dire, spesso quei programmi funzionano molto bene, ma d'altra parte, non si può mai essere sicuri se si vuole copiare parte del codice che perde in qualche altro programma. E non sono sicuro che l'idea dei programmi GTK + funzioni velocemente e quindi ci sono perdite.

Quindi, se a volte trovo una perdita di memoria in un programma open source, dovrei risolverlo o ci sono ad esempio problemi di efficienza e quindi l'idea originale dei programmatori era quella di scrivere un piccolo codice che perde?


17
Le perdite di memoria sono sempre indesiderabili. Rappresentano risorse che l'intero sistema non può utilizzare, incluso il programma host, fino al termine del programma.
recursion.ninja,

Esistono strumenti / librerie sufficienti per gestire le perdite di memoria. Ne vale la pena, poiché l'utilizzo dell'API dalla tua parte potrebbe essere sbagliato.
Joop Eggen,

1
Come nota a margine: valgrind è fantastico ma potrebbe riportare alcuni falsi positivi (li ho visti su GObject).
Maciej Piechotka,

Il calcolo dipende dall'elaborazione e dalla memoria: il primo è il codice e il secondo lo spazio in cui viene eseguito. Se non ti puoi fidare di non rovinare la tua stanza, come puoi aspettarti di usarlo per qualcosa di utile?
imallett,

1
"Codice sempre come se la persona che finisce per mantenere il tuo codice sia uno psicopatico violento che sa dove vivi."
Jesse C. Slicer,

Risposte:


6

L'importanza della correzione delle perdite di memoria dipende dalla gravità del problema e da cos'altro è importante. La mia esperienza è che piccole perdite di memoria tendono ad essere piuttosto favorevoli per la maggior parte delle applicazioni. La durata di una sessione dell'app desktop non è in genere abbastanza lunga da vedere un degrado da una piccola perdita di memoria.

Se stai scrivendo un server che funziona 24 ore su 24, 7 giorni su 7, le perdite di memoria ridotte possono accumularsi nel tempo e diventare un grave problema. Ma è per questo che molte aziende pianificano il riavvio giornaliero o settimanale dei loro server. Lo sforzo per trovare perdite di memoria è spesso eccessivo rispetto a ciò che potrebbe essere ottenuto, quindi è più facile riavviare i server su base regolare e passare a cose più importanti.


2
Non ho mai lavorato in un'azienda che ha riavviato il proprio server settimanalmente ... ancor meno ogni giorno. Sono d'accordo che il costo per riparare la perdita potrebbe essere troppo alto per risolverlo, ma avere questa mentalità non è buona IMO
Rémi

@ Rémi La maggior parte, se non tutti, i server di gioco MMO lo fanno, di solito su base settimanale.
Sjoerd,

35

Per i programmi a esecuzione breve, le perdite di memoria non sono così importanti; il sistema operativo recupererà tutto al termine, ma potrebbero impedire il rilascio di altre risorse.

Per quanto la corsa breve sia relativa, una perdita può sfuggire al controllo in poche ore o accumularsi per settimane inosservata.

Il mio consiglio è di segnalare un bug nel tracker con una correzione proposta, se il lead si preoccupa che lo risolverà.

Anche il tipo di perdita è importante. È possibile che l'allocazione che perde sia un'allocazione una tantum in cui lo sviluppatore ha deliberatamente fatto affidamento sul sistema operativo per la pulizia. Questi daranno un falso positivo su valgrind.


4
Sono principalmente d'accordo. Tuttavia, ti suggerisco di sottolineare l'importanza di una perdita di memoria. Le perdite di memoria non sono da prendere alla leggera e possono causare alcune interessanti "funzionalità" dell'applicazione.
Vladimir Kocjancic,

@VladimirKocjancic: +1 per "feature"
Emilio Garavaglia,

1
Voglio solo sottolineare che un computer è in grado di eseguire quell'elaborazione su un milione diversi milioni di volte abbastanza rapidamente. Non dimenticarlo mai. Quindi, se lo prendi in considerazione, sono d'accordo con questa risposta, perché dipende davvero dal programma. Per un sistema incorporato destinato a funzionare senza intervento umano, le perdite di memoria sono mortali. Per un'implementazione "grep" probabilmente non ti potrebbe interessare di meno.
Dunk

2
@Dunk: dipende: se grepattraversi un file molto grande e il tuo programma perde qualche byte per ogni riga di input, potresti esaurire la memoria.
Giorgio,

0

Secondo la mia opinione dogmatica su questo argomento, non ci sono scuse per perdite fisiche almeno in qualsiasi biblioteca che mira ad essere ampiamente applicabile. Quindi cercherei di infastidire gli sviluppatori GTK + fino a quando non lo risolvono da soli.

È abbastanza banale che una libreria registri atexitcallback per liberare tutta la memoria che alloca almeno dopo essere stata scaricata. Se vuole evitare la spesa di un carico di stanziamenti per adolescenti, non dovrebbe in primo luogo farli.

Perfino il programma più pigro che vuole allocare un carico di memoria di pezzi di memoria per adolescenti allo stesso tempo potrebbe usare un semplice allocatore sequenziale che cancella tutta la memoria allo spegnimento. Se l'allocatore non vuole nemmeno occuparsi dell'allineamento, può semplicemente riempire ogni singolo blocco che raggruppa ai limiti massimi di allineamento. Se è stato in grado di beneficiare di tempi di spegnimento più rapidi non liberando tutti quei piccoli pezzi di memoria singolarmente, allo stesso modo si trarrà molto beneficio simmetricamente in cambio di uno sforzo banale utilizzando un allocatore sequenziale tale che raggruppa la memoria in modo immediatamente sequenziale con allocazioni molto più veloci dimalloce altri schemi di memoria compatibili con la cache, solo per liberare tutti i blocchi di memoria contigui raggruppati dall'allocatore al termine della libreria. Tutto ciò che la libreria deve fare è sostituire le loro mallocchiamate per le quali non si preoccupano di freequalcosa di simile seq_malloce chiamare seq_purgeun atexitcallback per liberare tutta la memoria allocata dopo essere stata scaricata.

Altrimenti hai questa cattiva libreria che ingombra i messaggi nei tuoi strumenti di rilevamento delle perdite di memoria che ora devi filtrare. Peggio ancora, se non li filtrate sistematicamente, potrebbero oscurare le perdite nella vostra applicazione e i vostri colleghi potrebbero sviluppare l'abitudine di trascurarli, riducendo in primo luogo l'utilità degli strumenti di rilevamento delle perdite per impedire al vostro team di spingendo il codice che perde. È brutto e brutto e soprattutto non trovo che gli argomenti a favore di farlo deliberatamente siano convincenti affatto dato quanto sia banale usare la soluzione sopra.

Le perdite logiche (il tipo più complesso da cui persino la garbage collection non è in grado di proteggere) sono un problema più complesso, e lì potrei trovare una giustificazione per i programmi di breve durata che hanno perdite logiche fintanto che eliminano tutta quella memoria su cui hanno allocato spegnimento poiché richiede molta riflessione sulla gestione delle risorse per evitare perdite logiche (probabilmente più nelle lingue che hanno GC). Ma non trovo alcuna scusa ragionevole per evitare perdite fisiche, dato che sono banali da evitare anche nei contesti più pigri.

Ad ogni modo, almeno filtrerei le perdite di Valgrind in modo che almeno non si scherzino con la capacità della tua squadra di individuare le tue.


1
Mi chiedo se le perdite hanno qualcosa a che fare con la "codifica della barca"?

0

FWIW, se un utente segnalasse una perdita in un'applicazione su cui lavoro, sarei molto propenso a risolverlo (specialmente se includessero il codice per la correzione nella segnalazione dei bug!). Detto questo, potrebbe non accadere immediatamente se la perdita fosse piccola e altri problemi fossero più urgenti (diciamo, un bug che si verificava frequentemente). Ma lo apprezzerei sicuramente e lavorerei per risolverlo alla fine. Dovresti assolutamente farglielo sapere. Lo apprezzeranno e lavoreranno per risolverlo (molto probabilmente), o non se ne cureranno e tutto ciò che ti sarà costato è un po 'di tempo.

Utilizzando il nostro sito, riconosci di aver letto e compreso le nostre Informativa sui cookie e Informativa sulla privacy.
Licensed under cc by-sa 3.0 with attribution required.