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

Offline mandrav

  • Project Leader
  • Administrator
  • Lives here!
  • *****
  • Posts: 4315
    • Code::Blocks IDE
Re: HUGE MEMORY LEAK pinpointed!
« Reply #75 on: June 25, 2007, 01:21:45 pm »
I will have a look at this today.

Patch applied, thanks dmoore.
« Last Edit: June 25, 2007, 01:46:27 pm by mandrav »
Be patient!
This bug will be fixed soon...

Offline thomas

  • Administrator
  • Lives here!
  • *****
  • Posts: 3979
Re: HUGE MEMORY LEAK pinpointed!
« Reply #76 on: June 25, 2007, 04:54:51 pm »
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...  :(
"We should forget about small efficiencies, say about 97% of the time: Premature quotation is the root of public humiliation."

Offline Der Meister

  • Regular
  • ***
  • Posts: 307
Re: HUGE MEMORY LEAK pinpointed!
« Reply #77 on: June 25, 2007, 05:38:18 pm »
Really strange as the code from the patch doesn't delete anything. It just does not create FileLoader instances in some situations.
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 #78 on: June 25, 2007, 05:39:01 pm »
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...

Offline dmoore

  • Developer
  • Lives here!
  • *****
  • Posts: 1576
Re: HUGE MEMORY LEAK pinpointed!
« Reply #79 on: June 25, 2007, 05:42:02 pm »
Der Meister: do you have the same problem with the patch (without other recent CC changes)?

Offline Der Meister

  • Regular
  • ***
  • Posts: 307
Re: HUGE MEMORY LEAK pinpointed!
« Reply #80 on: June 25, 2007, 05:51:27 pm »
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.
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 rickg22

  • Lives here!
  • ****
  • Posts: 2283
Re: HUGE MEMORY LEAK pinpointed!
« Reply #81 on: June 25, 2007, 06:22:26 pm »

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.
« Last Edit: June 25, 2007, 07:20:04 pm by rickg22 »

Offline rickg22

  • Lives here!
  • ****
  • Posts: 2283
Re: HUGE MEMORY LEAK pinpointed!
« Reply #82 on: June 25, 2007, 06:48:38 pm »
...but only if CC is enabled,

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

Offline thomas

  • Administrator
  • Lives here!
  • *****
  • Posts: 3979
Re: HUGE MEMORY LEAK pinpointed!
« Reply #83 on: June 25, 2007, 07:48:12 pm »
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.
"We should forget about small efficiencies, say about 97% of the time: Premature quotation is the root of public humiliation."

Offline rickg22

  • Lives here!
  • ****
  • Posts: 2283
Re: HUGE MEMORY LEAK pinpointed!
« Reply #84 on: June 25, 2007, 08:14:39 pm »
Thanks, I'll test it tonight. OH, btw, can you post a copy of codeblocks.RPT here?

Offline Der Meister

  • Regular
  • ***
  • Posts: 307
Re: HUGE MEMORY LEAK pinpointed!
« Reply #85 on: June 25, 2007, 08:27:24 pm »
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.
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 rickg22

  • Lives here!
  • ****
  • Posts: 2283
Re: HUGE MEMORY LEAK pinpointed!
« Reply #86 on: June 25, 2007, 08:31:13 pm »
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.

Offline darthdespotism

  • Almost regular
  • **
  • Posts: 163
    • Coder's Nemesis
Re: HUGE MEMORY LEAK pinpointed!
« Reply #87 on: June 25, 2007, 09:06:35 pm »
My Codeblocks (actual SVN) crashes on each startup /Ubuntu-Linux 7.04

Is this related to the discused bug?

[attachment deleted by admin]

Offline rickg22

  • Lives here!
  • ****
  • Posts: 2283
Re: HUGE MEMORY LEAK pinpointed!
« Reply #88 on: June 25, 2007, 09:17:12 pm »
It's most probable.

Code
<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! :)
« Last Edit: June 25, 2007, 09:20:59 pm by rickg22 »

Offline dmoore

  • Developer
  • Lives here!
  • *****
  • Posts: 1576
Re: HUGE MEMORY LEAK pinpointed!
« Reply #89 on: June 25, 2007, 09:35:45 pm »
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
« Last Edit: June 25, 2007, 09:42:56 pm by dmoore »