When closing the project (by using "close workspace"), the 50% of the memory used is returned. The same behavior happen without code completion, only that the used memory is much less.This is normal behaviour. About 50% of the memory belongs to block allocated objects, these are never freed. Thus it always looks like there is a massive leak at first glance.
When closing the project (by using "close workspace"), the 50% of the memory used is returned. The same behavior happen without code completion, only that the used memory is much less.This is normal behaviour. About 50% of the memory belongs to block allocated objects, these are never freed. Thus it always looks like there is a massive leak at first glance.
You cannot find out about memory leaks as simple as this (see my above post with the memory diagram). If you want to detect a memory leak by observing the total memory consumption, then you have to open/close the same project many times (10-20 times) as tiwag did.
If there are no memory leaks, you will still see that only 50% of the memory is freed, but if there is a leak (as it is the case), 50% of the peak will be freed every time, but the base will grow linearly.
... but it is a lot easier to recompile wxWidgets in debug mode
Interesting is that after closing it and do some work with another application (e.g., IE, Word) and later checking the memory consumption of C::B, the value is of only 2-4 MB.This is a Windows malfunction. The Windows marketing FUD for this is "working set optimization" or something, but it is really a malfunction.
Quote... but it is a lot easier to recompile wxWidgets in debug mode
to build CB with wx-debug libs is easy, but it doesn't run,
i've done this already but couldn't solve the never ending assertions ...
it seems, that any eventhandler inside CB throws assertions all the time - if this could be solved, we can debug the memory leaks
Quote... but it is a lot easier to recompile wxWidgets in debug mode
to build CB with wx-debug libs is easy, but it doesn't run,
i've done this already but couldn't solve the never ending assertions ...
it seems, that any eventhandler inside CB throws assertions all the time - if this could be solved, we can debug the memory leaks
Strange, I have removed all the assertions I could find (last week, IIRC). Maybe it's been some time since you tried it?
but it is a lot easier to recompile wxWidgets in debug modeWell, I may have been a bit hasty in my judgement here. In fact, it is not easy to get it to work, at all. :lol:
EDIT: when I mean that debugger is crashy, I mean, I only do a right-click on the watches panel (even without the debugger running), click on Add watch, and "it just disappears. No error message (windows or otherwise), nothing."
Is this just me, or is code-completion crashy today?...the only crash i got today related to codecompletion was when i ran the wxdebug-version of CB ;-)
For this, you should update more often before complaining ;)Mm, I'm at Rev.1887 which is the latest. That means that anonymous SVN is lagging?
Thomas, I have a request... are you sure you can't make a way to free VERY LARGE unused blocks of memory with your blockallocator? i.e. we have tokens allocated in groups of 10,000. Could you make it so that when all the tokens of a specific block have been freed, the block would be released automatically? This would spare us having 600Megs of unused memory making up space after we close the contribs workspace... ¬¬sizeof(Token) == 140, thus 600 MB == 4,491,264 Tokens. If you really allocate that many tokens, then you should think about looking for a serious bug in the parser ;)
Code::Blocks loading CodeBlocks.cbp with code completion turned on: 85.6 MB
In my case it goes up to more than 120 MB (around 110000 tokens in a bit more than 1100 files).That's 14.68 MB in tokens versus 108 MB in "something else", so it is even worse.
In my case it goes up to more than 120 MB (around 110000 tokens in a bit more than 1100 files).That's 14.68 MB in tokens versus 108 MB in "something else", so it is even worse.
Thomas, are you POSITIVELY sure about the space used per token? Because each token includes an amount of of strings, and the space used by the strings is not insignificant... I may, however, delete an extra search tree on the tokens' fullnames...The space used by strings is allocated separately, it is not part of the Token object, and the block allocator has no control over it. In fact, if the string buffer were part of the object, the block allocator would crash, as it can only handle objects of fixed size with no derived virtual descendants.
Maybe the reason for CB not crashing on my machine is that I have a single-core... :-/My AMD64 is single-core as well, but I saw several crashes this afternoon, too. I can't reproduce them now in 1888, but I get a constant freeze when changing the parser settings (turning off "follow includes").
Yiannis: I haven't noticed crashes with codecompletion, please post stack traces
Hello,
I have remarked something about memory leaks. I have tried to open/close several times the C::B project with all the plugins and I have remarked that each time I lose around 2MB. For example if at beginning I have X=2MB, then after opening and closing C::B project I have X=4MB. If I repeat I will have X=6MB and so on. Then I have tried without plugins. I have switched off all the plugins in the 2menage plugins". I have observed the same behavior. X=2MB, then X=4MB, then X=5MB, then X=7MB and so on. Practically, the memory needed to open the C::B project is not released when I close the workspace.
Hope this could help :).
Michael
[EDIT] Sorry I have forgotten to say that I have used rev1889.
I thought thomas siad it was the start here page or something.Well, that does not mean there can't be others...
Index: sdk/cbproject.cpp
===================================================================
--- sdk/cbproject.cpp (revision 1889)
+++ sdk/cbproject.cpp (working copy)
@@ -989,24 +989,18 @@
return false;
// now free the rest of the project files
- int count = m_Files.GetCount();
Manager::Get()->GetEditorManager()->HideNotebook();
FilesList::Node* node = m_Files.GetFirst();
while(node)
{
ProjectFile* f = node->GetData();
- if (Manager::Get()->GetEditorManager()->Close(f->file.GetFullPath(),true))
- {
- FilesList::Node* oldNode = node;
- node = node->GetNext();
- m_Files.DeleteNode(oldNode);
- --count;
- }
- else
- node = node->GetNext();
+ Manager::Get()->GetEditorManager()->Close(f->file.GetFullPath(),true);
+ delete f;
+ delete node;
+ node = m_Files.GetFirst();
}
Manager::Get()->GetEditorManager()->ShowNotebook();
- return count == 0;
+ return true;
}
bool cbProject::SaveAllFiles()IMHO, there is still something that keeps the memory and does not or not always return it to the OS.Lol, at the risk of repeating myself... the block allocator never returns allocated memory to the OS, this is normal.
QuoteIMHO, there is still something that keeps the memory and does not or not always return it to the OS.Lol, at the risk of repeating myself... the block allocator never returns allocated memory to the OS, this is normal.
Only objects that are allocated via standard operator new are returned to the OS when they are deleted. That is for example the case for classes like wxFileName, or wxTextCtrl, but it is not true for cbEvent, Token, ProjectFile, ProjectBuildtarget, and maybe a couple of others.
Thus, it is correct that not all memory is freed, it must not be. The important point, however, is that the memory is reused, so if you open the same project 20 times (and even if you open/close different projects several times), the total amount of memory has to stay the same as long as your total memory requirement is not higher.
Another thing is: valgrind reported much more memory leaks than my patch solved. At least one more should be removed by thomas' patch (I did not test it yet - using valgrind needs some time; for example Code::Blocks needs about three minutes to start on my 2,4GHz Pentium 4) but others remain and I fear that we can't solve all of them. Some seem to be the fault of wxGTK or even gtk or Xlib...
Anyway, as long as they are not too big and only appear once in the complete livetime of the Code::Blocks process they should not be a real problem.
Good news people, i got rid of that nasty fullnames tree, and the contribplugins uses max 290 MB :)