About the Class browser crash....

[rickg22]

void ClassBrowserBuilderThread::BuildTree()
{
...
    RemoveInvalidNodes(m_pTreeBottom, m_pTreeBottom->GetRootItem());
...
}

void ClassBrowserBuilderThread::RemoveInvalidNodes(wxTreeCtrl* tree, wxTreeItemId parent)
{
...
    CollapseItem( ... )
...
}

void ClassBrowserBuilderThread::CollapseItem(...)
{
...
    m_pTreeTop->DeleteChildren(item);
...
}

OK can anyone explain me how did m_pTreeBottom became m_pTreeTop in there? 

[Biplab]

Does changing this code prevents the crash?

[rickg22]

No
But  I didn't add a mutex. I'll try with the mutex and come back with an answer.

Edit: With the mutex, it crashes much less often but it still crashes.

[rickg22]

After more than 5 hours examining and testing the code, I'm noticing many problems with the classbrowserbuilderthread...

1) wxMutexGuiEnter and wxMutexGuiLeave aren't used at all for windows platforms. And they should be used for atomic operations, not to build the whole tree. Of course, if we're accessing every single item for this, it could get really slow.

2) There isn't any signal to make the running thread stop.

3) It appears that on Windows, the tree construction is done (at least once) on the main thread?? How to debug that and keep cross-platform compatibility???

Fixing this bug could take several weeks... why not resort to using wxTimer events and use atomic operations for the tree construction? We could make sure that the classbrowserbuilderthread module would be the only one with write access to the tree... and since only one instance of the "thread" would be running at the same time, there would be no risks of lockups or crashes.

Otherwise I have no idea of how to fix this bug... IMHO using threads to build a GUI component is a very bad idea.

[mandrav]

...

Rick, I keep seeing you mentioning crashes/bugs/whatnot in symbols browser but I haven't had one of those for the last few months. So I was wondering, instead of trying to fix something that is possibly NOT there, could you just write down a procedure for me to recreate whatever issues you 're seeing?
(same goes for code-completion and other "sensitive" parts of the code: noone's been complaining about them for quite a while now)

[rickg22]

Yiannis: It's just one bug... 11433.
The bug I reported is well, related to it.
My frustrations are about trying to fix it. Sorry if I got mad above... I spent too much time with that bug.

[mandrav]

Yiannis: It's just one bug... 11433.
The bug I reported is well, related to it.
My frustrations are about trying to fix it. Sorry if I got mad above... I spent too much time with that bug.

OK, assign this bug to me. I will fix it, if it needs fixing.

[Biplab]

Yiannis,

This bug can be reproduced very easily. Please follow the following steps.

1) Open a project with two or more cpp files and open each of the source files in editor.
2) Let the Code-Completion complete parsing and build the class-browser.
3) Switch to Symbols tab.
4) Select Current file's symbols.
5) Select an item from the tree. Please see the following picture where I've marked the selection in Red.

6) Now click and activate another editor page. C::B will crash.

Please Note that Step 5 is vital. If you don't select anything, C::B will NOT crash.

Best Regards,

Biplab

[mandrav]

Thanks for the info Biplab.

[rickg22]

Yiannis: I'm doing some experiments in my local copy with the class browser. I replaced the builder thread with a wxTimer-based state machine (it works on the main thread, 50 iterations every 5 milliseconds), and it works wonderful - the crash is completely gone! , but I haven't implemented the adding of topmost nodes this way, so building the tree is actually slower right now). I think I'll have it 100% optimized by the end of the week.

Mind opening an experimental branch for me to try out?
Thanks!

Oh, btw... about fixing the bug, here are some things you could try...

1) Change the thread from detached to joinable.
2) Don't set m_pParser, m_pTreeTop and m_pTreeBottom to 0 on finish.
3) Check for nulls on all auxiliary functions
4) Fix The m_pTreeTop and m_pTreeBottom confusion that I exposed on the top of this thread.

Good luck! 

[mandrav]

Yiannis,

This bug can be reproduced very easily. Please follow the following steps.

1) Open a project with two or more cpp files and open each of the source files in editor.
2) Let the Code-Completion complete parsing and build the class-browser.
3) Switch to Symbols tab.
4) Select Current file's symbols.
5) Select an item from the tree.
6) Now click and activate another editor page. C::B will crash.

Please Note that Step 5 is vital. If you don't select anything, C::B will NOT crash.

Best Regards,

Biplab

As expected, it works fine here for me (Linux).

[Biplab]

As expected, it works fine here for me (Linux).

Try the same on Windows. I've reproduced it on Windows.

Edit 1: AFAIR, I couldn't reproduce this on Linux. But I'll confirm it after some time.

[Der Meister]

I could not reproduce it on Linux. Sounds like a Windows-only problem to me.

[Biplab]

Could not reproduce it on Linux. 

But I've tried several times on Windows and it crashes every time I try.

[eckard_klotz]

Hello together.

I'm a user of C::B and I can confirm both statments about the class browser crash:
C::B works under linux (Suse 10.1)
C::B crashes under winXP (Service-Pack 2)

If you take a look to the file codeblocks.rpt you will find following (Where "%C::B_ROOT%" is a longer path with 75 windows-allowed ansi-characters and 7 sud-directory levels):

Error occured on Wednesday, June 27, 2007 at 08:02:45.

%C::B_ROOT%\codeblocks.exe caused an Access Violation at location 6cde42ec in module %C::B_ROOT%\wxmsw28u_gcc_cb.dll Reading from location 00000028.

Registers:
eax=00000000 ebx=00000003 ecx=00000000 edx=ffff0000 esi=ffffffff edi=0307fb30
eip=6cde42ec esp=0307faf8 ebp=0307fb50 iopl=0         nv up ei pl zr na po nc
cs=001b  ss=0023  ds=0023  es=0023  fs=003b  gs=0000             efl=00010246

Call stack:
6CDE42EC  %C::B_ROOT%\wxmsw28u_gcc_cb.dll:6CDE42EC  _ZNK10wxTreeCtrl12GetItemParamERK12wxTreeItemId
6CDE44D8  %C::B_ROOT%\wxmsw28u_gcc_cb.dll:6CDE44D8  _ZNK10wxTreeCtrl11GetItemDataERK12wxTreeItemId
6CE8B18D  %C::B_ROOT%\wxmsw28u_gcc_cb.dll:6CE8B18D  _ZN11wxTreeEventC1EiP14wxTreeCtrlBaseRK12wxTreeItemId
6CDE62D6  %C::B_ROOT%\wxmsw28u_gcc_cb.dll:6CDE62D6  _ZN10wxTreeCtrl8DoExpandERK12wxTreeItemIdi
6CDE6601  %C::B_ROOT%\wxmsw28u_gcc_cb.dll:6CDE6601  _ZN10wxTreeCtrl16CollapseAndResetERK12wxTreeItemId
65EA0A61  %C::B_ROOT%\share\codeblocks\plugins\codecompletion.dll:65EA0A61
65E9E749  %C::B_ROOT%\share\codeblocks\plugins\codecompletion.dll:65E9E749
65E9E487  %C::B_ROOT%\share\codeblocks\plugins\codecompletion.dll:65E9E487
65E9DFBF  %C::B_ROOT%\share\codeblocks\plugins\codecompletion.dll:65E9DFBF
6CCFF82B  %C::B_ROOT%\wxmsw28u_gcc_cb.dll:6CCFF82B  _ZN11wxSemaphore7TryWaitEv
6CCFF93D  %C::B_ROOT%\wxmsw28u_gcc_cb.dll:6CCFF93D  _ZN11wxSemaphore7TryWaitEv
77C3A3B0  C:\WINDOWS\system32\msvcrt.dll:77C3A3B0  _endthreadex
7C80B683  C:\WINDOWS\system32\kernel32.dll:7C80B683  GetModuleFileNameA

Perhaps you call a wx-functionality which is implemnted as call to the operation-system. Under linux it works and under winXP not.


It may be a solution to implement the "change the current-file operation" like the "reparse function" if you have chosen "active project" or "workspace" .

Regards,
             Eckard Klotz

[rickg22]

I just noticed something.


m_pTreeTop->Expand(root);
if(platform::gtk)
{
     // seems like the "expand" event comes too late in wxGTK,
     // so make it happen now
     ExpandItem(root);
}

Maybe this is the cause of the crash... ExpandItem seems to be called by the main thread in Windows, while in Linux is called by the worker thread. But I can't really be sure, there are other places where the code changes in the Windows platform.

[thomas]

The crash is reproducible under Windows XP here, but it does not occur when running in the debugger, so it will be next to impossible to find it (other than by sheer luck).

[Biplab]

The crash is reproducible under Windows XP here, but it does not occur when running in the debugger, so it will be next to impossible to find it (other than by sheer luck).

The crash can be reproduced in Debugger, too.

Please see the backtrace generated using GDB in the following thread.

https://developer.berlios.de/bugs/?func=detailbug&bug_id=11433&group_id=5358

[thomas]

I found the reason:   You delete or Release() the pointer at some point, but you don't invalidate it.

Commenting out the code accessing m_pTreeTop around line 640 in classbrowserbuilderthread.cpp fixes the crash. Thus, the first logical conclusion is that the pointer is null.
However, adding a check for null-ness does not fix the crash. Ergo: the pointer in non-null and non-valid.

Find a delete without m_pTreeTop = 0, or a Release() without, and you have your bug.

[mandrav]

I found the reason:   You delete or Release() the pointer at some point, but you don't invalidate it.

Close but wrong. Anyway, the bug has been closed.

[rickg22]

Yay! 

So, how many bugs till RC3?