[F]Memory Leaks

SALOMON

Ich habe den Artikel noch einmal gelesen uns schon mal ein paar Fehler ausgemerzt.

Nun zu dir Jester:

Dein Vorschlag ist ja schon mal nicht schlecht!
Das Problem ist nur, dass USE_MEMORY_MANAGER ein Makro ist, dass irgentwo in deinem Programm mit #define festgelegt wurde.

Die Klasse, die new und delete überläd befindet sich aber in einer schon kompilierten und verlinkten DLL, daher würde diese Möglichkeit ausscheiden.

Die einzige Möglichkeit soetwas zu implementieren ist, dass ich vllt. eine statische Variable einbaue, die regelt, ob der Manager benutzt wird oder nicht.

Wofür meinst du brauche ich noch ein Beispiel. Sag mir das bitte noch einmal genauer, damit ich weiß, welche Funktionen du meinst.

Jester

SALOMON schrieb:

Nun zu dir Jester:

Dein Vorschlag ist ja schon mal nicht schlecht!
Das Problem ist nur, dass USE_MEMORY_MANAGER ein Makro ist, dass irgentwo in deinem Programm mit #define festgelegt wurde.

Die Klasse, die new und delete überläd befindet sich aber in einer schon kompilierten und verlinkten DLL, daher würde diese Möglichkeit ausscheiden.

Die einzige Möglichkeit soetwas zu implementieren ist, dass ich vllt. eine statische Variable einbaue, die regelt, ob der Manager benutzt wird oder nicht.

Okay, das Problem sehe ich ein. Wie gesagt, ich hab's auch nur überflogen und das paßt dann wohl wirklich nicht zu dem Konzept was Du hier vorstellst.

Wofür meinst du brauche ich noch ein Beispiel. Sag mir das bitte noch einmal genauer, damit ich weiß, welche Funktionen du meinst.

Du hast doch am Anfang dieses Beispiel mit dem Speicherloch wo Du ein new char[1024] machst. Um einen schnellen Überblick zu kriegen, was Du mit Deinem Artikel erreichen willst wäre es cool, genau dieses Beispiel mit der Funktionalität Deiner Lib implementiert zu sehen.

Btw. fände ich eine Funktion, die ich fragen kann ob noch Speicher freizugeben ist interessant. So könnte ich prüfen, ob ich sauber gearbeitet habe und sonst ne Fehlermeldung rausgeben.

Ein letztes, der Header von list heißt <list> und nicht <list.h>.

Bis auf das letzte ist aber alles kein Muß. Der Artikel liest sich auch so sehr schön.

SALOMON

Jester schrieb:

Ein letztes, der Header von list heißt <list> und nicht <list.h>.

Klar werde ich ändern.

Das Beispiel vom Anfang werde ich auch nochmal ans Ende schreiben. Natürlich mit Benutzung der Funktionen.

Implementieren, dass du nachher eine Liste bekommst, wie viele MemoryLeaks vorhanden sind, ist auch kein Problem. Du kannst sie ja in der MMFreeAllMemory()
zählen. Aber ich bin mir nicht ganz sicher, ob es das ist, was du haben möchtest.

CStoll

Der Artikel sieht nicht schlecht aus, nur ob die Makros wirklich eleganter sind als die direkten Funktionsaufrufe, wage ich zu bezweifeln.

Eventuell wäre es ja nicht schlecht, aus deinen Funktionen einen geeigneten Alloicator zu bauen - damit ließen sich auch die STL-Container in die Speicherverwaltung einbauen.

PS:

void MMObject::operator delete(void* rawMemory)
{
    if(rawMemory==NULL) throw std::invalid_argument("MMObject::operator delete: rawMemory = NULL");

    MMFreeMemory(rawMemory);
}

Afaik ist "delete NULL;" im Standard explizit erlaubt, sollte also keinen Fehler verursachen.

volkard

welches problem löst dein code?
bitte nicht das "speicherloch" in der main, das war gar keins.
nach prozessende ist dein speicher wieder freigegeben. du hast mit schrecklichen methoden ein nicht-loch gestopft.

echte speicherlöcher gehen so:

int main(){
   for(;;){
      int* p=new int;
   }
}

und da hast nichtmal andeutungsweise dran gebohrt.

mein server kackt nach wenigen minuten ab. probier ihn doch mal aus. langsamere löscher sorgen dafüpr, daß ein server erst nach 2 wochen abkackt. ein server ist dabei ein prozess, keine maschine.

wenn du lösungen zu speicherlöchern anbieten magst, dann bitte welche, die es erleichtern, den fehlerhaften code, der das speicherloch verursacht hat, zu finden und den fehler zu korrigieren.

//size_t arraysize
if(arraysize <= 0)

es ist eigentlich nicht job eines debug-heaps, zu gucken, ob der benutzer da minuszahlen reinmacht. aber size_t ist eh nichtnegativ. warum ist 0 als size verboten?

Vector<string>* pVec (vector<string>*)MMAllocMemory(sizeof(vector<string>));

geht fein mit

//#include <new>
Vector<string>* pVec=new(MMAllocMemory(sizeof(vector<string>))) vector<string>);

nur wird innerhalb des vectors dann new benutzt und nicht dein kram. einen fehler in vector wirste nicht finden. auch keinen nichtvirtuellen destruktor einer klasse mit new-benutzendem member (böses loch).

du solltest vielleicht den globalen operator new mit einem debug-new überladen und

#define new new(__FILE__,__LINE__)

machen. und bei programmende nur die probleme anzeigen, nämlich speicher, der nicht deleted wurde, und zwar vor allem die position im quellcode, damit man die löcher jagen und vernichten kann.

den aktuellen weg brauchste nicht weiterzuverfolgen.

Korbinian

Ich faende es sinnvoller in einem C++ Artikel ueber mem leaks ueber smartpointer zu sprechen als selbst eine dll zu implementieren die a) betriebssystem abhaengig, b) nicht objektorientiert, c) nicht thread-safe, d)umstaendlich da ohne templates und schliesslich e) eine funktionalitaet bietet, die von smartpointern deutlich besser bereit gestellt wird.

Sorry das ist hart, aber lieber wenig gute Artikel als einen haufen schlechter.

edit: ich sehe, dass cstoll einen Artike ueber Speicherverwaltung geschrieben hat, der deckt das eigentlich ab...

CStoll

Korbinian schrieb:

edit: ich sehe, dass cstoll einen Artike ueber Speicherverwaltung geschrieben hat, der deckt das eigentlich ab...

Nur mit der Entdeckung von Speicherlecks habe ich mich dort nicht beschäftigt.

(und bei genauem Betrachten hat Volkard recht - der Code erledigt nur Aufräumarbeiten, die das System bei Programmende sowieso machen würde (und wie du selbst bemerkt hast, ist er C++-untauglich), ohne etwas gegen echte Speicherlecks zu unternehmen)

Jester

Aber ist ja alles nicht schlimm. Volkard hat ja auch wunderbare Ideen aufgezeigt, was man stattdessen machen könnte. Dadraus kriegt man sicher nen schönen Artikel hin.

SALOMON

Ja gut, dann werde ich das evntl. machen. Ich werde aber warscheilich so schnell eh keine Zeit finden (ist momentan knapp bemessen).

Jochen Kalmbach

Nur so als Anmerkung: Ich hab da mal einen Artikel geschrieben (aber Englisch):
http://www.codeproject.com/tools/leakfinder.asp