Author Topic: HUGE MEMORY LEAK pinpointed!  (Read 63224 times)

Offline darthdespotism

  • Almost regular
  • **
  • Posts: 163
    • Coder's Nemesis
Re: HUGE MEMORY LEAK pinpointed!
« Reply #90 on: June 25, 2007, 10:08:27 pm »

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! :)


If I could locate the file I would post it.
Can you guide me to the location with Ubuntu/Linux?

EDIT://
I'll be off for today.
Trying to locate it tomorrow
« Last Edit: June 25, 2007, 10:20:58 pm by darthdespotism »

Offline Ceniza

  • Developer
  • Lives here!
  • *****
  • Posts: 1441
    • CenizaSOFT
Re: HUGE MEMORY LEAK pinpointed!
« Reply #91 on: June 25, 2007, 10:33:04 pm »
Useless to locate it... it's NOT created on *nix, only Windows. The XML file is what you get on *nix.

Offline dmoore

  • Developer
  • Lives here!
  • *****
  • Posts: 1576
Re: HUGE MEMORY LEAK pinpointed!
« Reply #92 on: June 25, 2007, 10:43:37 pm »
line 170 of backgroundthread.h causes the problem (delete job), so presumably job is being deleted twice...

Code
class BackgroundThread ...
    ExitCode Entry()
    {
        AbstractJob* job;
        for(;;)
        {
            semaphore->Wait();
            if(die)
                break;

            job = queue->Pop();

            if(job->deleted)
            {
                delete job;
                continue;
            }

            (*job)();
            job->done = true;

            if(job->deleted || ownsJobs)
            {
******         delete job; // CRASH
            }
        }
        return 0;
    };

The recent svn history for that file might help:

http://svn.berlios.de/wsvn/codeblocks/trunk/src/include/backgroundthread.h?op=diff&rev=0&sc=0
« Last Edit: June 25, 2007, 10:46:52 pm by dmoore »

Offline rickg22

  • Lives here!
  • ****
  • Posts: 2283
Re: HUGE MEMORY LEAK pinpointed!
« Reply #93 on: June 25, 2007, 10:49:41 pm »
dmoore, if you turn off codecompletion, the crash goes away? Because i hadn't modified that code yet after those changes in LoaderBase were introduced, and there's a part in Code completion that does a Delete( ... ). But then again, what about that crash reported by darthdespotism?
« Last Edit: June 25, 2007, 10:56:20 pm by rickg22 »

Offline Der Meister

  • Regular
  • ***
  • Posts: 307
Re: HUGE MEMORY LEAK pinpointed!
« Reply #94 on: June 25, 2007, 10:53:56 pm »
Well, I don't think that this is the cause for the crash here but I think we have a possible race condition here: After the job has finished and job->done is set to true it is possible to delete the job using AbstractJob::Delete() (which will be called from a different thread). This will set AbstractJob::deleted to true which in case allows the BackgroundThread to delete the job. Now we have two deletes for just one piece of memory.
Real Programmers don't comment their code. If it was hard to write, it should be hard to understand.
Real Programmers don't write in BASIC. Actually, no programmers write in BASIC, after the age of 12.

Offline dmoore

  • Developer
  • Lives here!
  • *****
  • Posts: 1576
Re: HUGE MEMORY LEAK pinpointed!
« Reply #95 on: June 25, 2007, 11:01:37 pm »
dmoore, if you turn off codecompletion, the crash goes away? Because i hadn't modified that code yet after those changes in LoaderBase were introduced, and there's a part in Code completion that does a Delete( ... ). But then again, what about that crash reported by darthdespotism?

i can't get it to crash consistently even with the CC plugin switched on. I haven't had any crashes with the CC plugin turned off.

I reverted the backgroundthread changes and testing...

Offline rickg22

  • Lives here!
  • ****
  • Posts: 2283
Re: HUGE MEMORY LEAK pinpointed!
« Reply #96 on: June 26, 2007, 02:01:36 am »
dmoore, any news?

Offline rickg22

  • Lives here!
  • ****
  • Posts: 2283
Re: HUGE MEMORY LEAK pinpointed!
« Reply #97 on: June 26, 2007, 04:24:13 am »
I've tried to analyze the Abstractjob code, but it's too complicated for me to understand the program flow. I don't even know if the ORIGINAL code is correct!  :?

I vote for a revert. I'm compiling the reverted code and see if there are any problems. If I don't find any crashes, I'll commit.
Edit: Everything seems fine. I'll commit after dinner :)
Edit: Done.
« Last Edit: June 26, 2007, 06:14:53 am by rickg22 »

Offline thomas

  • Administrator
  • Lives here!
  • *****
  • Posts: 3979
Re: HUGE MEMORY LEAK pinpointed!
« Reply #98 on: June 26, 2007, 09:46:36 am »
Reverting the code because you don't understand it sounds like the way to go :)

I think DerMeister is right, but we will now never find out.
"We should forget about small efficiencies, say about 97% of the time: Premature quotation is the root of public humiliation."

Offline thomas

  • Administrator
  • Lives here!
  • *****
  • Posts: 3979
Re: HUGE MEMORY LEAK pinpointed!
« Reply #99 on: June 26, 2007, 10:57:26 am »
And this is what r4182 has to say about opening a project with CC enabled:
Error occured on Tuesday, June 26, 2007 at 10:52:40.

C:\CodeBlocks\codeblocks.exe caused an Access Violation at location 6199d7cb in module C:\CodeBlocks\codeblocks.dll Writing to location 77d5624f.

Registers:
eax=77d5624f ebx=06545a00 ecx=00000000 edx=0022f2a8 esi=05059ef0 edi=ffffffff
eip=6199d7cb esp=0831fd40 ebp=0831fd40 iopl=0         nv up ei pl nz ac po nc
cs=001b  ss=0023  ds=0023  es=0023  fs=003b  gs=0000             efl=00010216

Call stack:
6199D7CB  C:\CodeBlocks\codeblocks.dll:6199D7CB  _ZN7SQLexer6ReadIDEv
61A4CA9D  C:\CodeBlocks\codeblocks.dll:61A4CA9D  _ZNSt4listIN12cbThreadPool21cbThreadedTaskElementESaIS1_EE8_M_eraseESt14_List_iteratorIS1_E
61A4CB1E  C:\CodeBlocks\codeblocks.dll:61A4CB1E  _ZNSt4listIN12cbThreadPool21cbThreadedTaskElementESaIS1_EE9pop_frontEv
617EDEF9  C:\CodeBlocks\codeblocks.dll:617EDEF9  _ZN12cbThreadPool11GetNextTaskEv
617EE63F  C:\CodeBlocks\codeblocks.dll:617EE63F  _ZN12cbThreadPool14cbWorkerThread5EntryEv
627BF82B  C:\CodeBlocks\wxmsw28u_gcc_custom.dll:627BF82B  _ZN11wxSemaphore7TryWaitEv
627BF93D  C:\CodeBlocks\wxmsw28u_gcc_custom.dll:627BF93D  _ZN11wxSemaphore7TryWaitEv
77C0A3B0  C:\WINDOWS\system32\msvcrt.dll:77C0A3B0  _endthreadex
7C80B683  C:\WINDOWS\system32\kernel32.dll:7C80B683  GetModuleFileNameA


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.
"We should forget about small efficiencies, say about 97% of the time: Premature quotation is the root of public humiliation."

Offline dmoore

  • Developer
  • Lives here!
  • *****
  • Posts: 1576
Re: HUGE MEMORY LEAK pinpointed!
« Reply #100 on: June 26, 2007, 01:23:41 pm »
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 *).

Offline rickg22

  • Lives here!
  • ****
  • Posts: 2283
I FOUND THE CAUSE!
« Reply #101 on: June 26, 2007, 03:23:10 pm »
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.

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();
}
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();
...
}

And in LoadWorkspace...
Code
        CodeBlocksEvent event(cbEVT_WORKSPACE_LOADED);
        Manager::Get()->GetPluginManager()->NotifyPlugins(event);

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...
« Last Edit: June 26, 2007, 03:59:57 pm by rickg22 »

Offline Pecan

  • Plugin developer
  • Lives here!
  • ****
  • Posts: 2750
Re: HUGE MEMORY LEAK pinpointed!
« Reply #102 on: June 26, 2007, 04:05:13 pm »
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



« Last Edit: June 26, 2007, 04:07:30 pm by Pecan »

Offline rickg22

  • Lives here!
  • ****
  • Posts: 2283
Re: HUGE MEMORY LEAK pinpointed!
« Reply #103 on: June 26, 2007, 04:11:24 pm »
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

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.
« Last Edit: June 26, 2007, 04:16:01 pm by rickg22 »

Offline David Perfors

  • Developer
  • Lives here!
  • *****
  • Posts: 560
Re: HUGE MEMORY LEAK pinpointed!
« Reply #104 on: June 26, 2007, 04:46:59 pm »
Those 10 hours did passed by verry quickly :P
OS: winXP
Compiler: mingw
IDE: Code::Blocks SVN WX: 2.8.4 Wish list: faster code completion, easier debugging, refactoring