Dotaz: Memory leak v stl?

[esparky]

Dobrý den, v mém projektu mě trápí dost protivný memory leak, při jehož hledání jsem došel zhruba k následující konstrukci, která jej způsobuje:

#include <map>
#include <string>
#include <iostream>
#include <stdio.h>
#include <sstream>
using namespace std;

multimap<int,string> mapa;

int main() {
    for(int i=0;i<20000;i++) {
        stringstream s;
        mapa.insert(make_pair(i%234,string("fdsfdsfdsfdsfdsfds")+s.str()));
    };
    cout<<"Mapa vytvorena"<<endl;

    getc(stdin);  //Zde celý program zabírá 2292 KB

    cout<<"Jdu mazat"<<endl;

    for(int i=0;i<234;++i) {
        mapa.erase(i);
    };
    cout<<"smazano"<<mapa.size()<<endl;

    getc(stdin); //Zde program zabírá 2312KB
};

 

Zajímalo by mě, proč na konci programu je stále naalokováno tolik paměti, i když mapa neobsahuje žádné záznamy. Zabranou pamět zjišťuji příkazem ps s parametrem RSS. Valgrind žádný leak neukazuje.

Stejný problém jsem narazil i u vectoru, a asi bude i u dalších kontejnerů.

Máte pro to nějaké vysvětlení? Lze nějak přikázat kontejneru/překladači, aby paměť skutečně delalokoval?

Odpovědi

[graviton]

http://valgrind.org/docs/manual/faq.html#faq.reports

[blondak]

Tak nevím. ale přijde mi, že alokujete 20000 členů a pak uvolníte jenom 234, nemůže být problém tam?

[blondak]

beru zpět přehlídnul jsem tam to %234 :(

[Luboš Doležel (Doli)]

Podívejte se, co vám vrátí std::vector<T>::capacity() - tam se to asi bude skrývat. Napadá mě leda zkusit clear(), ale nevím nevím.

[karl82]

koukni sem http://www.sgi.com/tech/stl/alloc.html

[luky]

Alokátor při mazání objektů (myšleno obecně jako bloky paměti, ne nutně jako instance tříd apod.) typicky nevrací všechnu volnou paměť zpátky systému, aby měl něco v rezervě pro další alokace a nemusel od systému hned žádat novou. Jestli to jde nějak vynutit (standardními funkcemi C++/STL) netuším, ale nelámal bych si s tím hlavu.

[puk]

Je mozny vyhradit urcitou kapacitu: std::vector(int) vec, vec.reseve(10); aby nedochazelo k realokaci behem plneni. Pokud uz mame plnej vektor a chceme jej zmensit na pocet (size()), pak zavolame std::vector<int>(vec).swap(vec);

[Martin Doucha]

To není memory leak, STL je prostě žrout paměti. Co kontejner schvátí, jen tak nevrátí

[esparky]

Děkuji všem za odpověďi To %234, tam je pouze, abych měl v kontejneru různé prvky, z nichž některé se budou opakovat. Nechtěl jsem tím mást:) Opravdu je to tak, že STL si naalokuje paměť a tu potom používá, takže v pokud pole znovu naplním, nová paměť už se nebere...ale pouze na tomhle testovacím prográmku, v mém projektu ne :'(. Zajímalo by mě, zda existuje možnost, jak přinutit SDL aby tu paměť dealokoval (clear() nepomáhá). Zkoušel jsem to exportnutí GLIBCXX_FORCE_NEW, ale nepomáhá to. Nějaká cesta, jak přinutit SDL dealokovat paměť přece musí existovat, protože jinak by jakýkoli program - deamon, co třeba při spuštění potřebuje 100MB RAM a pak už jen 2MB žral celou dobu 100 paměti...to by přece nikdo nemohl přehlédnout:)

[Boris Dušek]

 GLIBCXX_FORCE_NEW je určitě těžce nepřenositelné. Řešení ti popsal "puk" o pár příspěvků výše (aneb např. string(s).swap(s), obdobně pro vector apod.)

[Luboš Doležel (Doli)]

Jenže to, co tu předvádíte, je vcelku nestandardní situace. Pokud někdo maže položky z vektoru a už tam nic pak nedává, děje se tak např. před destrukcí celého objektu, kdy se paměť uvolní. A pokud se ten vektor nelikviduje, tak se do něj pravděpodobně zas něco dá. A pokud se vám tenhle alokátor nelíbí, tak použijte/napište jiný,