Lokalizowanie linii wycieków pamięci C++

W temacie programistyczne wtf pochwaliłem się wynikiem z Fastmm który pokazał mi ogromną ilość wycieków pamięci.
Tylko że teraz muszę ogarnąć te wszystkie wycieki bo aplikacja zżera za dużo pamięci i się wywala przy wczytywaniu bazy (OutOfMemory).

Wiadomo że nie znajdę wszystkiego ręcznie więc szukam narzędzia, które mi pokaże w których linijkach nie jest zwalniana pamięć.
Fastmm ma taką możliwość tylko że przy ustawieniu wszystkiego zgodnie z tym co znalazłem na necie i odpaleniu debugowania wywala mi EAccessViolation na funkcji z pliku FastMM4BCB.cpp

Czy są jakieś proste narzędzia które będą współpracować z Borlandem C++ Builderem 6 i Windowsem, które pokażą mi konkretne nr linii?

Kod ma >20k linii dlatego szukam innego rozwiązania niz recznie wszystko sprawdzać

Kod ma >20k linii dlatego szukam innego rozwiązania niz recznie wszystko sprawdzać

No i co z tego?
Policz sobie ilość słówek new i delete... i w każdej funkcji oddzielnie;
no i to chyba tyle można tak z marszu zahaczyć,
ponieważ można alokować w wielu miejscach a potem zwalniać zbiorowo - w pętli,
a wtedy deletów będzie oczywista mniej.

Debuger może łatwo pokazać miejsca wywalania się programu,
czyli to jest raczej odwrotna sytuacja, gdy czytamy niealokowane obszary, albo poza zakresem - access violation.

Natomiast odwrotnej sytuacji - 'wycieków' żaden debuger nie pokaże... bo wtedy jest zawsze OK... aż do finalnego wyjebania. :)

Podobnie jest z tworzeniem obiektów systemowych wszelkiego rodzaju: pen, brusch, font, file, ect.
Można sobie to tworzyć, no i trzeba usuwać... systematycznie, a nie na odczep.

Valgrind.

Valgrind by był ok tylko, że potrzebuje czegoś na windowsa i borlanda, ew. będę dalej próbować z fastmm

Skorzystaj z BoundsChecker lub GlowCode.

Ewentualnie Purify od IBM.

GlowCode spełnił po części swoje zadanie, jednak i tak będę przerabiać wszystkie wskaźniki na inteligentne zgodnie z pomysłem @Azarien w innym temacie

Wszystkie wskaźniki? To może od razu lepiej pisz w Pythonie albo Rubym - będziesz mieć podobną wydajność, a mniej się namęczysz. Inteligentne wskaźniki zliczające referencje mają pewne zalety, ale co najmniej jedną poważną wadę - są kosztowne. Są znacznie bardziej kosztowne niż GC w szybkich językach zarządzanych, bo każda modyfikacja / przypisanie takiego wskaźnika to kilkadziesiąt-kilka tysięcy taktów CPU w plecy na atomowe zwiększanie/zmniejszanie licznika i potencjalny cache-miss.

Przede wszystkim zaprzyjaźnij się z RAII, STLem, std::move, std::unique_ptr i dopiero na końcu z inteligentnymi wskaźnikami.

@Krolik std::unique_ptr też zalicza się do inteligentnych wskaźników.

@fju Jak piszesz w C++ i potrzebujesz wywoływać new/delete, to robisz to źle. Tym bardziej jeśli masz sparowane new/delete w jednej funkcji. - Krolik

Ja robię takie rzeczy znacznie sprytniej.

A mianowicie:
robię obiekt np. typu TDataList
no i to już samo się alokuje i zwalnia, kiedy potrzeba - i hurtowo, a nie po jednym elemencie.

przykładowo:

struct TList
{
  TList(int siz=10mega, int cnt, int delta=1000)
    { restmem = count = 0; realloc(siz, cnt); }
  
  ~TList() { free(); }

  add(TItem *it, int siz); 

  void *getmem(int siz)
  { if( restmem < siz ) realloc(siz);
    void *p = ptrmem; ptrmem += siz; restmem -= siz; return p; }
  
  void free() { delete pdata; }
 ...  

 int count, // liczba jakichś tam obiektów w liście
     restmem; // ilość ramu do użycia

 void *list, *pdata, *ptrmem;

};

No, czyli alokuję od razu z 10MB na dzień dobry, a potem tylko sobie to używam.
Finalnie zwalniam raz - wszystko naraz, a nie .

Tylko po co, skoro jest std::vector?

Krolik napisał(a):

Tylko po co, skoro jest std::vector?

To nie jest tego typu obiekt... no i nie ma w ogóle tego typu gotowców.

Możesz użyć vector wskaźników, no ale wtedy tam będzie
to alokowane za każdym razem osobno:

add(T *p);
i tu pójdzie:
nowy = new T(*p); no i teraz insert(nowy) - do tej listy wskaźników (dla sortowanej jest najpierw szukanie...).

no a poza tym tyle samo alokujemy dla każdego obiektu, co w praktyce znaczy,
że musimy znać maksymalny rozmiar obiektu... co jest raczej kłopotliwe,
np. baza adresowa:
nazwisko + imię + nip, adres: ulica, miasto, itd.

więc i potem marnujemy z 90% ramu, bo alokujemy zawsze maks - strasznie zawyżony,
zamiast tyle ile potrzeba.

Cool story bro, ale co to ma do tematu?

Specyficzny przypadek nie neguje reguły, że przy normalnym programowaniu w C++ w 99% przypadków nie jest potrzebne new/delete, a wystarczą standardowe kontenery i gdzieniegdzie inteligentne wskaźniki (przy czym te najbardziej inteligentne same zliczające referencje - w ostateczności).

Krolik napisał(a):

Cool story bro, ale co to ma do tematu?

Bardzo dużo.

Porządny kod - wyśrubowany to nie są te std::bzdet, niestety,
dlatego trzeba troch programować - wbrew logice co niektórych zakwaszonych zasrańców - pseudoteoretyków, którzy tu dominują. :)

Krolik napisał(a):

Specyficzny przypadek nie neguje reguły, że przy normalnym programowaniu w C++ w 99% przypadków nie jest potrzebne new/delete, a wystarczą standardowe kontenery i gdzieniegdzie inteligentne wskaźniki (przy czym te najbardziej inteligentne same zliczające referencje - w ostateczności).

Ja nie używam zwykle tych kontenerów, bo jak wiadomo:
co zbyt universalne to i automatycznie będzie szajsem w konkretnych - specyficznych zastosowaniach...
pomijając dzieła niedzielnych programistów, oczywista - tu możesz jechać tym szmelcem śmiało;
no a potem szukać magicznych-inteligentnych debugerów do ratowania. :)

W kinach terminator, na konsole mortal kombat, za kilka lat nowy gorky, programiści z awersją do używania biblioteki standardowej... który mamy rok? - spartanPAGE

Początkujący mogą sobie to używać śmiało... w prostych programikach.

Z tym że to też nie jest takie oczywiste, bowiem biegłe opanowanie
takiej, jakby nie patrzeć, dość rozbudowanej biblioteki, kosztuje trochę czasu.

Ten czas można zainwestować inaczej: np. ucząc się praktycznego programowania. :)

No, w końcu ktoś musi pisać nawet i takie uniwersalne biblioteczki obiektowe... dla niedzielnych programistów (czytaj: studentów),
no a raczej szerze wątpię, aby wzorcowy user myszki i gotowców dałbyś radę coś takiego w ogóle wymyślić, a co dopiero zakodować. P)