Navigacija
Lista poslednjih: 16, 32, 64, 128 poruka.

Curenje memorije

[es] :: C/C++ programiranje :: Curenje memorije

[ Pregleda: 3805 | Odgovora: 12 ] > FB > Twit

Postavi temu Odgovori

Autor

Pretraga teme: Traži
Markiranje Štampanje RSS

Furion
BiH

Član broj: 95467
Poruke: 2
*.PPPoE-2887.sa.bih.net.ba.



Profil

icon Curenje memorije06.06.2006. u 01:04 - pre 174 meseci
Imam mali problem. Ako vam nije tesko pogledajte, pls.
Da li ovdje curi memorija:
Code:
#include <iostream>
#include <string>
#include <conio.h>                     // Samo za "getch" funkciju

using namespace std;

struct Cvor {
  string element;
  Cvor *veza;
};

int main() {
  Cvor *pocetak(0);
  for(;;) {
    string recenica;
    cout << "Unesite recenicu (ENTER za kraj): ";
    getline(cin, recenica);
    if(recenica.length() == 0) break;
    Cvor *prethodni(0);
    for(Cvor *p = pocetak; p !=0 && p->element < recenica; p = p->veza) 
      prethodni = p;
    Cvor *novi = new Cvor;
    novi->element = recenica;
    if(prethodni == 0) {
      novi->veza = pocetak;
      pocetak = novi;
    }
    else {
      novi->veza = prethodni->veza;
      prethodni->veza = novi;
    }
  }
  for(Cvor *p = pocetak; p != 0; p = p->veza) {
    cout << p->element << endl;
  }
  getch();
  return 0;
}
 
Odgovor na temu

NastyBoy
Bojan Nastic
UK

Član broj: 12041
Poruke: 895
*.plus.com.



+4 Profil

icon Re: Curenje memorije06.06.2006. u 01:12 - pre 174 meseci
Kako mislish "da li curi"?
Ako si neshto alocirao sa "new", a nigde do kraja programa nemash odgovarajuci "delete", naravno da imash memory leak.
Prodji na kraju programa kroz celu listu novokreiranih nodova i pobrishi ih.
 
Odgovor na temu

Furion
BiH

Član broj: 95467
Poruke: 2
*.PPPoE-2887.sa.bih.net.ba.



Profil

icon Re: Curenje memorije06.06.2006. u 01:21 - pre 174 meseci
Ma pretpostavljam i ja da imam memory leak, cak sam bio prilicno siguran. Ali eto da opet provjerim...
A znam i kako cu dealocirat.
Thanx
 
Odgovor na temu

tosa
上海, 中国

Član broj: 1811
Poruke: 1339
*.ubisoft.com.cn.

ICQ: 14293955
Sajt: https://github.com/milost..


+46 Profil

icon Re: Curenje memorije06.06.2006. u 06:46 - pre 174 meseci
Najlakše je da override-uješ new i delete operatore i da pamtiš svaku alokaciju.
Tako na kraju izvršavanja programa možeš lako znati u kom fajlu/redu imaš leak.
 
Odgovor na temu

Dragi Tata
Malo ispod Kanade

Član broj: 1958
Poruke: 3906
*.lionbridge.com.



+6 Profil

icon Re: Curenje memorije06.06.2006. u 14:00 - pre 174 meseci
Citat:
tosa: Najlakše je da override-uješ new i delete operatore i da pamtiš svaku alokaciju.


Najlakše je da koristiš ovako nešto:
http://www.codeproject.com/tools/visualleakdetector.asp
 
Odgovor na temu

tosa
上海, 中国

Član broj: 1811
Poruke: 1339
222.67.157.*

ICQ: 14293955
Sajt: https://github.com/milost..


+46 Profil

icon Re: Curenje memorije06.06.2006. u 16:50 - pre 174 meseci
Citat:

Činjenica, mada je ipak bolje napisati svoje rešenje koje će raditi i na drugim platformama.
Veoma zanimljiva ideja da se pamti call-stack za svaku alokaciju, mada već imam
nekoliko platformi u glavi koje to ne bi podnele (zbog male količine memorije) :)
 
Odgovor na temu

cynique
Ivan Štambuk
[email protected]

Član broj: 93690
Poruke: 155
193.198.17.*

ICQ: 106979934
Sajt: istambuk.blogspot.com


Profil

icon Re: Curenje memorije07.06.2006. u 10:52 - pre 174 meseci
Ako je ovo čitav program, onda leakova memorije nema, jer će OS uništiti cijeli adresni prostor po izlasku procesa :)

Nisam nikad koristio custom alokatore, kad me zanima potrošnja memorije programa samo dodam performance counter za Virtual Bytes i Peak Virtual Bytes, veće neslaganje između njih bi trebalo ukazati na loše baratanje memorijom..
 
Odgovor na temu

Nedeljko
Nedeljko Stefanović

Član broj: 314
Poruke: 8391
*.sr.gov.yu.



+2718 Profil

icon Re: Curenje memorije07.06.2006. u 12:15 - pre 174 meseci
Citat:
cynique: Ako je ovo čitav program, onda leakova memorije nema, jer će OS uništiti cijeli adresni prostor po izlasku procesa :)

Da li si baš siguran? Probaj program da pokreneš pod operativnim sistemima DOS. Win16, Win9x. Pod Win16 nisam isprobavao (jer ga nikad nisam ni imao na mašini). Mislim da MS DOS neće osloboditi zauzetu memoriju, a na Win 98SE se nakon izvršenja takvog procesa javlja problem kod gašenja sistema. To što si rekao zavisi od OS-a. Na Win2000, WinXP i GNU/Linux sistemima svakako nema nikakvih problema. U svakom slučaju, oslobađanje memorije od strane procesa, a ne OS-a je stvar osnovne programerske kulture. Ja sam u C++ jeziku za automatske pokaziveče.
Nije bitno koji su zaključci izvučeni, već kako se do njih došlo.
 
Odgovor na temu

cynique
Ivan Štambuk
[email protected]

Član broj: 93690
Poruke: 155
193.198.17.*

ICQ: 106979934
Sajt: istambuk.blogspot.com


Profil

icon Re: Curenje memorije07.06.2006. u 12:54 - pre 174 meseci
Naravno da neće raditi za real-mode OS-eve (MS-DOS i njegova 16-bitna grafička sučelja eehh) koji uopće ne poznaju koncept virtualne memorije ;) Na svim modernim OS-evima u zadnjih 10 god ne bi trebalo biti problema. NT kernel održava AVL stablo VAD (Virtual Address Descriptor) struktura koje opisuju izgled procesovog adresnog prostora (opseg rezerviranih (svaki page mora biti rezerviran prije nego je committed, tako da sigurno ovdje završi) pages, permisije, dijeljenje..).

Na Solarisu je to također AVL-stablo seg_t struktura, i odatle dolazi famozni pojam segmentation fault, kad se dereferencira virtualna adresa neprisutna ni u jednom mapiranom segmentu. Generirani SIGSEG se sinkrono dispatcha u procesov uarea (koji služi za dispatching signala preko aslwp LWP-a) iz ISSIG makroa pri izlasku iz pozvanog syscalla ili iz recimo page fault handlera. Vjerojatno je sl. na linuxu i ostalim *nixoidima.

Što se tiče općenito memory leakova na Windows platformi, važno je zapamtiti da memory leakovi povećavaju procesovu privatnu virtualnu veličinu, a ne veličinu working seta. WS je veći od stvarne potrošnje procesa jer se za svaki proces broje i shared pages. Za točniju potrošnju od ukupne fizičke memorije treba oduzeti slobodnu memoriju (Available bytes), memoriju koju koristi OS (nonpaged pool, resident page pool, resident OS & driver code), te veličinu modified liste. Veličinu ovog zadnjeg faktora je moguće dobiti jedino iz kernel debuggera (!vm 1 komandom).

Što se tiče std::auto_ptr, to će u principu raditi samo za objekte alocirane unutar scope-a, jer će pri njihovom izlasku se automatski pozvati delete nad objektima sa kojim su kreirani. Ali to znači da objekt neće biti oslobođen ako sve do kraja bloka, čak i ako nije više potreban nakon nekog trenutka! Koliko sam shvatio, auto_ptr nije najsretnije rješenje za dijeljene objekte u multithreaded okolini, pored zaštite od double deletion i sl. suptilnih bugova, jer je pravilno implementirati prenošenje ownershipa sa jednog threada na drugi pravi PITA, pogotovo recimo za Javu koja je 10 god imala problema sa tim (mislim da je taj problem riješen u Javi 5).

Najbolje bi bilo da je C++ bio projektiran da podržava GC od samog početka. Šteta što su Stepanov, Stroustrup, Koening i ostala ekipa iz Bel labsa imali puno glupih predrasuda za GC. U zadnjih 20 god, ne postoji ni jedan jedini novi mainstream jezik koji nema integriran GC, i C++ ima sve pretpostavke da u roku 5 god potpuno preuzme tron COBOL-a 90-ih po tom pitanju, ako se nešto radikalno ne promijeni (a neće).
 
Odgovor na temu

kiklop74
Darko Miletić
Buenos Aires

Član broj: 78422
Poruke: 569
..36.static.techtelnet.com.ar.

Sajt: ar.linkedin.com/pub/darko..


+13 Profil

icon Re: Curenje memorije07.06.2006. u 12:55 - pre 174 meseci
Citat:
Nedeljko:Ja sam u C++ jeziku za automatske pokaziveče.


Je'l ti to o std::auto_ptr pričaš?

Baš si me zbunio sa automatskim pokazivačima. Kao da čitam neku od knjiga Laszla Krausa. :)


Tko leti vrijedi
 
Odgovor na temu

Dragi Tata
Malo ispod Kanade

Član broj: 1958
Poruke: 3906
*.lionbridge.com.



+6 Profil

icon Re: Curenje memorije07.06.2006. u 13:07 - pre 174 meseci
Citat:
cynique:
Najbolje bi bilo da je C++ bio projektiran da podržava GC od samog početka. Šteta što su Stepanov, Stroustrup, Koening i ostala ekipa iz Bel labsa imali puno glupih predrasuda za GC. U zadnjih 20 god, ne postoji ni jedan jedini novi mainstream jezik koji nema integriran GC,


Predlažem da prelistaš "The Design and Evolution of C++" pre nego što sledeći put napišeš tako nešto ;) http://www.research.att.com/~bs/dne.html

C++ jednostavno ne može da ima "obavezan" GC zbog svoje namene (low-level sistemski jezik) i kompatiblinosti sa C-om. Inače, "pametni pointeri" kao što su oni iz Boost biblioteke koji su već na putu da uđu i u standard, su najčešće sasvim dobro rešenje za automatsko upravljanje memorijom.

Citat:
cynique:
C++ ima sve pretpostavke da u roku 5 god potpuno preuzme tron COBOL-a 90-ih po tom pitanju, ako se nešto radikalno ne promijeni (a neće).


Kad su u pitanju interne biznis aplikacije, C++u je već odavno odzvonilo. Međutim za sistemske, real-time, grafičke, multimedijalne itd. primene trenutno ne vidim nikakvu alternativu osim C-a i eventualno Fortrana ;)
 
Odgovor na temu

kiklop74
Darko Miletić
Buenos Aires

Član broj: 78422
Poruke: 569
..36.static.techtelnet.com.ar.

Sajt: ar.linkedin.com/pub/darko..


+13 Profil

icon Re: Curenje memorije07.06.2006. u 13:56 - pre 174 meseci
Citat:
cynique:
Najbolje bi bilo da je C++ bio projektiran da podržava GC od samog početka. Šteta što su Stepanov, Stroustrup, Koening i ostala ekipa iz Bel labsa imali puno glupih predrasuda za GC.


Mešanje baba i žaba ne ide. C++ i GC ne ide. Sam jezik nije dizajniran za tako nešto. Postoji CLI ali to je već nešto drugo.

Citat:
cynique:
C++ ima sve pretpostavke da u roku 5 god potpuno preuzme tron COBOL-a 90-ih po tom pitanju, ako se nešto radikalno ne promijeni (a neće).


Ti si stvarno odvojen od realnosti. U svetu windowsa klasičan C++ je praktično mrtav kad se priča o novim klasičnim GUI aplikacijama. Samo se održavaju postojeće i sve se lagano portuje na .NET .

C/C++ će se koristiti za realtime aplikacije, matematiku, igre, drajvere i ostale low-level stvari.

Jedina platforma gde se jos masivno koristi C++ za biznis aplikacije i GUI klasiku je UNIX/Linux. Mada i tu se trude da idu na javu ako može.




Tko leti vrijedi
 
Odgovor na temu

Nedeljko
Nedeljko Stefanović

Član broj: 314
Poruke: 8391
*.sr.gov.yu.



+2718 Profil

icon Re: Curenje memorije08.06.2006. u 01:54 - pre 174 meseci
Upravo je odsusustvo GC-a ono što ga čini podesnijim za razvoj real-time softvera (kao što su video igre, multimedija itd.) u odnosu na jezike sa GC-om. GC uvodi nedeterminizam. Nikada se ne zna kada će se uključiti, a vrlo skupa operacija je u pitanju. CAD se i dan-danas radi u jeziku C++.

Postoje jezici sa pitomijim GC-om, kao što su PROLOG i LISP. U PROLOG-u se liste realizuju preko binarnih drveta, i svaka druga vrsta grafa pokazivanja između objekata u memoriji je nemoguća, pa je lako napraviti deterministički GC. Sa druge strane, u jezicima kao što je C#, graf pokazivanja između objekata u memoriji može biti bilo kakav, pa je i GC nedeterministički.
Nije bitno koji su zaključci izvučeni, već kako se do njih došlo.
 
Odgovor na temu

[es] :: C/C++ programiranje :: Curenje memorije

[ Pregleda: 3805 | Odgovora: 12 ] > FB > Twit

Postavi temu Odgovori

Navigacija
Lista poslednjih: 16, 32, 64, 128 poruka.