HUGE MEMORY LEAK pinpointed!

[mandrav]

I will have a look at this today.

Patch applied, thanks dmoore.

[thomas]

I will have a look at this today.

Patch applied, thanks dmoore.

Something is not good with that, I think... I am getting access violations at startup from within BackgroundThread::Entry with r4170 now, but only if CC is enabled, and if I had a project open when closing Code::Blocks in the previous session.
I'm not sure what it is (something being deleted too early?), but it's strange, and it didn't happen before... 

[Der Meister]

Really strange as the code from the patch doesn't delete anything. It just does not create FileLoader instances in some situations.

[dmoore]

the patch doesn't change the placement of any deletes. the only way this patch could be directly responsible is if (a) the  loader pointer is being acessed when NULL or (b) the Tokenizer class expects to find a loader for a given file, but it hasn't been instantiated because of the new placement of the Load call,  causing unexpected behavior. Trawling through the only other places the loader is accessed: ParserThread::InitTokenizer, Tokenizer::Init, Tokenizer::Read, and ParserThread::~ParserThread, I don't think this is the case.

there has been lots of other CC activity...

[dmoore]

Der Meister: do you have the same problem with the patch (without other recent CC changes)?

[Der Meister]

No, I had no problem with your first version of the patch. I never tested your changed versions.
But I only did a rather small check: Starting Code::Blocks, loading the Code::Blocks workspace, waiting until the parser finished and then closing Code::Blocks. This worked. After that I did the same procedure in valgrind to check whether the memory leak was really gone.

I just did another quick test: Opening and closing several projects without waiting for the parser to finish its work. No crash. But still I use revision 4161 with the first version of your patch on Linux.

[rickg22]

Something is not good with that, I think... I am getting access violations at startup from within BackgroundThread::Entry with r4170 now, but only if CC is enabled, and if I had a project open when closing Code::Blocks in the previous session.
I'm not sure what it is (something being deleted too early?), but it's strange, and it didn't happen before... 

I confirm, it happened to me only once - 1 or 2 days ago. But I couldn't reproduce it . Perhaps it had something to do with some changes i did to CC parsing startup (I don't use a timer anymore). But it's strange indeed (The other times I get segfaults are if i close / open projects TOO FAST and/or close the app before the parser finishes, but i have to be real quick to get them and doesn't happen always).

With Revision 4168 (without the patch applied) I couldn't reproduce the backgroundthread crash. Thomas, can you confirm that the crash does NOT occur if the patch is _NOT_ applied? (i.e. changing it like it was)

Another test: Apply the patch to revision 4163 (before my changes) and test.

I'll test tonight, since i only have 4168 in my machine.
BTW... i have the hunch it has to do with building the class browser. Thomas, here's a quick test. Comment the part that invokes the building of class browser, and see if the crash remains.

EDIT: The code belongs to the loader, not the class browser (class browser is wxThread,not Backgroundthread). Thomas, I recall you saying that you added a Delete part to BackgroundThread, right? Perhaps this new part is the cause of the conflict? i.e. trying to delete something that isn't there, or not initializing the deleted field correctly?
Also, a stack log (codeblocks.RPT) could help.

[rickg22]

...but only if CC is enabled,

with CC you mean the plugin, or the code completion functionality ONLY?

[thomas]

The plugin.

Steps to reproduce:
1. load Code::Blocks
2. click on codeblocks.cbp on the start here page to open it
3. wait a few seconds
4. close Code::Blocks
5. load Code::Blocks ---> access violation
6. load Code::Blocks ---> works fine
7. try (6) any number of times ---> works fine
8. try again from step (2) ---> access violation

Disable the CC plugin, and there is never any crash.

I've been using r4120 before, and never had any visible issues.

[rickg22]

Thanks, I'll test it tonight. OH, btw, can you post a copy of codeblocks.RPT here?

[Der Meister]

Steps to reproduce:
1. load Code::Blocks
2. click on codeblocks.cbp on the start here page to open it
3. wait a few seconds
4. close Code::Blocks
5. load Code::Blocks ---> access violation
6. load Code::Blocks ---> works fine
7. try (6) any number of times ---> works fine
8. try again from step (2) ---> access violation

Disable the CC plugin, and there is never any crash.

I've been using r4120 before, and never had any visible issues.

This has to be a windows issue or it was introduced after revision 4161 as I can't reproduce it here with revision 4161 on Linux.

[rickg22]

Yes, it's a problem that appeared after 4164 or greater (no need to post "me neither", guys). It's either my code or Thomas'. Or perhaps a strange situation where both changes trigger the crash.

[darthdespotism]

My Codeblocks (actual SVN) crashes on each startup /Ubuntu-Linux 7.04

Is this related to the discused bug?

[attachment deleted by admin]

[rickg22]

It's most probable.

Code Select Expand


<stack>
  <frame level="0" function="wxFatalSignalHandler" offset="00000026" />
  <frame level="1" />
  <frame level="2" function="EditorLexerLoader::Load(LoaderBase*)" offset="0000001d" />
  <frame level="3" function="EditorColourSet::LoadAvailableSets()" offset="00000362" />
  <frame level="4" function="EditorColourSet::EditorColourSet(wxString const&)" offset="00000067" />
  <frame level="5" function="EditorManager::EditorManager()" offset="000003e9" />
  <frame level="6" function="Manager::GetEditorManager() const" offset="00000056" />
  <frame level="7" function="MainFrame::OnStartHereLink(wxCommandEvent&)" offset="00000000" />
  <frame level="8" function="MainFrame::OnPluginInstalled(CodeBlocksEvent&)" offset="00000000" />
  <frame level="9" function="MainFrame::OnPluginInstalled(CodeBlocksEvent&)" offset="00000000" />
  <frame level="10" function="CodeBlocksApp::OnAppActivate(wxActivateEvent&)" offset="00000000" />
  <frame level="11" function="CodeBlocksApp::OnBatchBuildDone(CodeBlocksEvent&)" offset="00000000" />
  <frame level="12" function="wxAppConsole::CallOnInit()" offset="00000000" />
  </stack>


LoaderBase* seems to be the culprit, but having the source line numbers would be better.

Can you do us a favor? On your codeblocks directory, there should be a file called "codeblocks.RPT".
Open it with a text editor and browse to the latest entry. Can you copy and paste the lines here, please? Thanks!

[dmoore]

i can't replicate at all with latest svn on win32. did you guys clear out your devel dir?

correction

copied output dir back to my main install location and reran cb: what do you know -- crash

C:\Codeblocks\codeblocks.exe caused an Access Violation at location 00000011 Reading from location 00000011.

Registers:
eax=00000011 ebx=00c02e00 ecx=00000001 edx=00fcbe2c esi=00f12444 edi=ffffffff
eip=00000011 esp=01cafec4 ebp=01cafed0 iopl=0         nv up ei pl nz na pe nc
cs=001b  ss=0023  ds=0023  es=0023  fs=003b  gs=0000             efl=00010202

Call stack:
00000011
606C3CF1  C:\Codeblocks\codeblocks.dll:606C3CF1  _ZN16BackgroundThread5EntryEv
100BF5CB  C:\Codeblocks\wxmsw28u_gcc_custom.dll:100BF5CB  _ZN11wxSemaphore7TryWaitEv
100BF6DD  C:\Codeblocks\wxmsw28u_gcc_custom.dll:100BF6DD  _ZN11wxSemaphore7TryWaitEv
77C3A3B0  C:\WINDOWS\system32\msvcrt.dll:77C3A3B0  _endthreadex
7C80B683  C:\WINDOWS\system32\kernel32.dll:7C80B683  GetModuleFileNameA