Developer forums (C::B DEVELOPMENT STRICTLY!) > Development

HUGE MEMORY LEAK pinpointed!

<< < (21/21)

dmoore:
sorry i had to dash yesterday guys. i didn't test thoroughly, but didn't have any crashes with the abstractjob code reverted. i'm now trying latest svn on my home win32 and linux boxes without troubles so far... (I haven't had time to compile contrib plugins. I did clean out devel, also it might help to check out a pristine copy or fully revert any local changes: svn revert -R *).

rickg22:

--- Quote from: thomas on June 26, 2007, 10:57:26 am ---I can't reproduce it reliably, seems to happen randomly opening the same project... no idea what it is now. But no crashes with CC disabled, again.

--- End quote ---

Well, now that the workerthread code is gone, at least it'll be easier for us to identify the culprit. After some deductions, the only possibility left is that it's my fault, and I have understood why  :oops:. I wasn't still not sure why, until the crash was reproduced without Thomas' code.

K, here goes...

In my latest change to Code Completion, to fix the class browser not being updated, i moved the code that parses the active projects, from a wxTimerEvent handler, to the OnWorkspaceLoaded event handler. After looking at the app.cpp code a few minutes ago, I noticed that the parsing starts BEFORE it should, making these random crashes appear. Since it's multithreaded, the error only gets triggered either on very fast machines, or on very slow machines.

(The problem is that these 3 changes took place in the same build - from 4165 to 4169: 1) Thomas' workerthread change, 2) dmoore's memleak fix, and 3) My apparently-harm change to the parsing)

Anyway...


--- Code: ---bool CodeBlocksApp::OnInit()
{
 ...
        MainFrame* frame = 0; frame = InitFrame();
        m_Frame = frame;
...
        Manager::Get()->GetMessageManager()->DebugLog(_T("Initializing plugins..."));
        CodeBlocksEvent event(cbEVT_APP_STARTUP_DONE);
        Manager::Get()->ProcessEvent(event);
        Manager::ProcessPendingEvents();
        splash.Hide();
}

--- End code ---
The problem is that m_Frame isn't set in the middle of InitFrame, and guess what happens in there:

--- Code: ---MainFrame* CodeBlocksApp::InitFrame()
{
...
            Manager::Get()->GetProjectManager()->LoadWorkspace();
...
}

--- End code ---

And in LoadWorkspace...

--- Code: ---        CodeBlocksEvent event(cbEVT_WORKSPACE_LOADED);
        Manager::Get()->GetPluginManager()->NotifyPlugins(event);

--- End code ---

So, Thomas, you were both right and wrong: The error was triggered by Code Completion because it's the ONLY plugin yet that uses the new EVT_WORKSPACE_LOADED; but the fault lies within my changes to ProjectManager, because I didn't take into account that the app hadn't been initialized yet in all workspace loads.

And *THIS* is why it happened *ONLY* if you had a workspace open beforehand.

I'll fix ProjectManager so that it only sends the event after the main frame has been initialized. But please don't re-commit your backgroundthread change until we have tested my change... just to be on the safe side :mrgreen:

Edit: I modified the code and am compiling, but I have to go to the job now :( I'll commit in around 10 hours, sorry...

Pecan:
Twice, I got the crash described but I have CC disabled.
It occurred after the splash and just as the CB window appeared.
I have no auto loading of files. So how could this be a CC crash?

I'll run under gdb from now on. See If I can catch it.

SVN4169 XpSp2


--- Code: --- Tuesday, June 26, 2007 at 09:32:52.

c:\Usr\Proj\cbBeta\trunk\src\devel\codeblocks.exe caused an Access Violation at location 00000011 Reading from location 00000011.

Registers:
eax=00000011 ebx=01725b00 ecx=00000001 edx=01759d0c esi=015e8194 edi=ffffffff
eip=00000011 esp=0202fec4 ebp=0202fed0 iopl=0         nv up ei pl nz na po nc
cs=001b  ss=0023  ds=0023  es=0023  fs=003b  gs=0000             efl=00010206

Call stack:
00000011
606C34C1  c:\Usr\Proj\cbBeta\trunk\src\devel\codeblocks.dll:606C34C1  _ZN16BackgroundThread5EntryEv
100BE97B  c:\Usr\Proj\cbBeta\trunk\src\devel\wxmsw28u_gcc_custom.dll:100BE97B  _ZN11wxSemaphore7TryWaitEv
100BEA8D  c:\Usr\Proj\cbBeta\trunk\src\devel\wxmsw28u_gcc_custom.dll:100BEA8D  _ZN11wxSemaphore7TryWaitEv
77C3A3B0  C:\WINDOWS\system32\msvcrt.dll:77C3A3B0  _endthreadex
7C80B50B  C:\WINDOWS\system32\kernel32.dll:7C80B50B  GetModuleFileNameA




--- End code ---

rickg22:
Pecan: Thanks for clearing that up!

Anyway.

I tested my fix, and this is what happens:


--- Code: ---[09:08:28.875]: Initializing plugins...
[09:08:28.890]: Add project Code::Blocks in parsing queue

--- End code ---

This proves that the parsing doesn't start until the plugins have been correctly initialized. In other words, it works! :)

I'm committing the changes right now... done. Revision 4185.

David Perfors:
Those 10 hours did passed by verry quickly :P

Navigation

[0] Message Index

[*] Previous page