Developer forums (C::B DEVELOPMENT STRICTLY!) > Development
HUGE MEMORY LEAK pinpointed!
Der Meister:
Bad news: Just putting a delete[] data; in in front of data = new char[len+1]; didn't solve the memory leak. I don't know if it changed anything as I didn't save the ouput of the valgrind run before this patch - shame on me. But still, just starting Code::Blocks, opening codeblocks.cbp, waiting until CC-plugin finished parsing and closing Code::Blocks left about 10MB non-freed memory behind just because of this function. According to this I would guess that the destrcutor of LoaderBase never gets called.
rickg22:
Der Meister: Try doing the following experiment.
Open and close the Code::Blocks project several times, open it again and close the app. That should leave us with 70 or so megabytes of data floating around. That'll be much easier to locate in the valgrind logs.
Biplab:
--- Quote from: rickg22 on June 22, 2007, 06:12:44 pm ---Der Meister: Try doing the following experiment.
Open and close the Code::Blocks project several times, open it again and close the app. That should leave us with 70 or so megabytes of data floating around. That'll be much easier to locate in the valgrind logs.
--- End quote ---
Repeating valgrind tests can be painful. ;)
Valgrind runs the app approx. 10-20x times slower. I ran that test in a Virtual Machine. So it took a lot of time to get one complete log.
Der Meister:
No, I really don't want to do this. As Biplab said, valgrind runs are painful.
Anyway, I *hope* I found the reason for this. TDragon's post pointed me to the right direction: The BackgroundThread instance does not delete the jobs as it does not own them. Therefore the caller of FileManager::Load has to free the memory but it looks like this was never done. I just pachted a few places and will start another valgrind run to check if it works.
thomas:
--- Quote from: rickg22 on June 22, 2007, 04:43:30 am ---There's the culprit! According to the report, there is a new[] without delete[] in FileLoader::operator()().
--- End quote ---
No, this is just like it has to be.
--- Quote from: rickg22 on June 22, 2007, 04:58:32 am ---There's a Delete( ) operation done.
But I can't find ANYWHERE the function "Delete" (with uppercase).
--- End quote ---
It is a function that has been in globals.h for many months, and which is now in prep.h (so it's available everywhere).
What it does is, it calls the C++ delete operator on a pointer-to-object and (within thread scope) atomically zeroes the pointer.
I added this many months ago in response to the crashes that were caused by code like
if(pointer)
delete pointer;
...which does not only contain an unnecessary if() but which was also the reason for regular mysterious crashes when a pointer was not set to zero after being delted, and subsequently was deleted a second time.
Except for member pointers that are deleted in class destructors, Delete() should always be used in preference to delete.
Using Delete() in a class destructor is of course possible, but since the members are invalid after this, there is unnecessary overhead in zeroing the pointer.
Navigation
[0] Message Index
[#] Next page
[*] Previous page
Go to full version