News:

When registered with our forums, feel free to send a "here I am" post here to differ human beings from SPAM bots.

Main Menu

Nasty crash in symbol browser

Started by Agustin, June 28, 2007, 06:38:23 PM

Previous topic - Next topic

Agustin

Hi,

I have been using Codeblocks in Windows for a while, and I keep experiencing this recurring problem over nightly builds. It was supposedly fixed as of late, but it seems this is not the case. The problem can be reproduced in the following manner:

In the Symbols Browser, choose Current File's Symbols.
Then, select Global Functions or Global Variables.
Open a file from the Project Browser, or even switch to another tab if the file is already opened...

That causes a crash, everytime I do it, even between different computers. I assume the problem is caused when Code Completion is parsing the new file. Is this a known problem? If so, I'm sorry for reporting it.

Any help would be greatly appreciated!

Agustin

Biplab

It's a known bug. Hopefully it'll be fixed soon.
Be a part of the solution, not a part of the problem.

rickg22

#2
"Crash" as in lockup-you-cant-do-anything, or "crash" as in "This program has executed an illegal operation and must be shutdown" crash? Because I just tried to do what you said, and my C::B locked up. However,  i checked the task manager and it was on 0%.

Biplab

Here is one crash report.

QuoteProgram received signal SIGSEGV, Segmentation fault.
[Switching to thread 4780.0x108]
0x6cde42ec in wxTreeCtrl::GetItemParam ()
   from F:\cbsource\src\devel\wxmsw28u_gcc_cb.dll
(gdb) bt full
#0  0x6cde42ec in wxTreeCtrl::GetItemParam ()
   from F:\cbsource\src\devel\wxmsw28u_gcc_cb.dll
No symbol table info available.
#1  0x6cde44d8 in wxTreeCtrl::GetItemData ()
   from F:\cbsource\src\devel\wxmsw28u_gcc_cb.dll
No symbol table info available.
#2  0x6ce8b18d in wxTreeEvent::wxTreeEvent ()
   from F:\cbsource\src\devel\wxmsw28u_gcc_cb.dll
No symbol table info available.
#3  0x6cde62d6 in wxTreeCtrl::DoExpand ()
   from F:\cbsource\src\devel\wxmsw28u_gcc_cb.dll
No symbol table info available.
#4  0x6cde6601 in wxTreeCtrl::CollapseAndReset ()
   from F:\cbsource\src\devel\wxmsw28u_gcc_cb.dll
No symbol table info available.
#5  0x65ea0a61 in ClassBrowserBuilderThread::CollapseItem (this=0x24e5ef8,
    item={m_pItem = 0xffff0000})
    at F:/cbsource/src/plugins/codecompletion/classbrowserbuilderthread.cpp:620
        lock = {m_isOk = true, m_mutex = @0x24e5f5c}
#6  0x65e9e749 in ClassBrowserBuilderThread::RemoveInvalidNodes (
    this=0x24e5ef8, tree=0x24e5038, parent={m_pItem = 0xffff0000})
    at F:/cbsource/src/plugins/codecompletion/classbrowserbuilderthread.cpp:249
        parent = {m_pItem = 0xffff0000}
        isLastChild = true
        data = (CBTreeData *) 0x704c710
        existing = {m_pItem = 0x28f978}
#7  0x65e9e487 in ClassBrowserBuilderThread::BuildTree (this=0x24e5ef8)
    at F:/cbsource/src/plugins/codecompletion/classbrowserbuilderthread.cpp:189
        root = {m_pItem = 0x28ada0}
#8  0x65e9dfbf in ClassBrowserBuilderThread::Entry (this=0x24e5ef8)
    at F:/cbsource/src/plugins/codecompletion/classbrowserbuilderthread.cpp:107
No locals.
#9  0x6ccff82b in wxThreadInternal::DoThreadStart ()
   from F:\cbsource\src\devel\wxmsw28u_gcc_cb.dll
No symbol table info available.
#10 0x6ccff93d in wxThreadInternal::WinThreadStart ()
   from F:\cbsource\src\devel\wxmsw28u_gcc_cb.dll
No symbol table info available.
#11 0x77c3a3b0 in msvcrt!_endthreadex () from C:\WINDOWS\system32\msvcrt.dll
No symbol table info available.
#12 0x024e5ef8 in ?? ()
No symbol table info available.
#13 0x00000002 in ?? ()
No symbol table info available.
#14 0x00ffffff in ?? ()
No symbol table info available.
#15 0x0257aff8 in ?? ()
No symbol table info available.
#16 0x00000000 in ?? ()
No symbol table info available.

Rev 4193, Win XP SP2.
Be a part of the solution, not a part of the problem.

rickg22

Is it just me, or this crash is related to Bug 11460?

http://developer.berlios.de/bugs/?func=detailbug&bug_id=11460&group_id=5358


ClassBrowserBuilderThread::RemoveInvalidNodes (
    this=0x24e5ef8, tree=0x24e5038, parent={m_pItem = 0xffff0000})
    at F:/cbsource/src/plugins/codecompletion/classbrowserbuilderthread.cpp:249
        parent = {m_pItem = 0xffff0000}
        isLastChild = true
        data = (CBTreeData *) 0x704c710
        existing = {m_pItem = 0x28f978}
#7  0x65e9e487 in ClassBrowserBuilderThread::BuildTree


Interestingly, both bugs are related to the symbol browser being rewritten.

Anyway... Is anybody *ACTUALLY WORKING* on debugging this?
Because I don't see anyone assigned to that bug.

Because I think i have a solution for this bug, and is to *clear the whole tree* instead of just removing the invalid nodes. However, I haven't examined that particular part of the codecompletion plugin. If nobody's working on it, I volunteer.

Biplab

This bug was discussed in the following thread.

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

This bug is very easy to reproduce. :)

I'll try to reproduce this in Linux, too. BTW, I can't help much other than providing crash reports. :(
Be a part of the solution, not a part of the problem.

rickg22

biplab: The crash reports are *VERY* valuable! :) Just make sure you're running the debug version of C::B and, if you can... use addr2line to find the appropriate lines - if you can and have the time, of course.

Agustin

Yes, sorry about not clarifying, this causes an exception and immediate shutdown of the application. I really can't look into it, but it seems to be something fairly simple... I mean, the Code Completion module is evidently parsing files very well and works. The problem occurs when you try to bring the symbols locally for a single file.

Maybe this helps: if I go back to Workspace Symbols view, and open a new file, the crash evidently doesn't occur. BUT, if I immediately switch to File Symbols, there is a strange lag in the browser, where nothing appears (not even categories, such as preprocessor, etc.)... and sometimes I have to click several times to force the symbols to appear. However, the application doesn't crash - it only does so when you switch files while the File Symbols browser is enabled.

rickg22


mandrav

Quote from: rickg22 on June 28, 2007, 08:13:34 PM
Because I think i have a solution for this bug, and is to *clear the whole tree* instead of just removing the invalid nodes.

Rick, please, don't...
Be patient!
This bug will be fixed soon...

rickg22

Yiannis: I won't commit, but I'm still going to do the experiment on my own machine.

See, I think the culprit is this function...

void ClassBrowserBuilderThread::RemoveInvalidNodes(wxTreeCtrl* tree, wxTreeItemId parent)
{
...
            if (m_pTokens->at(data->m_TokenIndex) != data->m_pToken ||
                data->m_TokenKind != data->m_pToken->m_TokenKind || // need to compare kinds: the token index might have been reused...
                data->m_TokenName != data->m_pToken->m_Name || // same for the token name
                !TokenMatchesFilter(data->m_pToken))
...
}


There's a string comparison for every item in there, and that's the cause of the lag.
Anyway, If I do any changes, I'll post them in the form of a patch.

rickg22

#11
Yiannis: Guess what.

IT WORKS!!!!!!!!!!!  :D :D :D :D :D :D :D :D :D :D :D :D :D :D :D :D

I didn't commit anything, instead, I submitted the fix as patch #2084.

Anyway, my theory is that while the classbrowserbuilderthread is deleting nodes, it's also triggering tons of events. The DeleteChildren method of wxTreeCtrl does not trigger any event. Please try it and tell me if it works for you. I notice a side effect, which is that it rebuilds the tree everytime you change the setting above it. But at least it doesn't crash for me :)


Index: src/plugins/codecompletion/classbrowserbuilderthread.cpp
===================================================================
--- src/plugins/codecompletion/classbrowserbuilderthread.cpp (revision 4196)
+++ src/plugins/codecompletion/classbrowserbuilderthread.cpp (working copy)
@@ -185,8 +185,10 @@
     m_pTreeTop->Freeze();
     m_pTreeBottom->Freeze();

- RemoveInvalidNodes(m_pTreeTop, root);
- RemoveInvalidNodes(m_pTreeBottom, m_pTreeBottom->GetRootItem());

+ m_pTreeTop->DeleteChildren(m_pTreeTop->GetRootItem());
+ m_pTreeBottom->DeleteChildren(m_pTreeBottom->GetRootItem());
+ // RemoveInvalidNodes(m_pTreeTop, root);
+ // RemoveInvalidNodes(m_pTreeBottom, m_pTreeBottom->GetRootItem());

     if (TestDestroy() || Manager::IsAppShuttingDown())
     {

Biplab

Quote from: rickg22 on June 28, 2007, 09:20:25 PM
biplab: The crash reports are *VERY* valuable! :) Just make sure you're running the debug version of C::B and, if you can... use addr2line to find the appropriate lines - if you can and have the time, of course.

I always run a debug version of C::B under GDB. It gives enough information to trace it. :)

QuoteYiannis: Guess what.

IT WORKS!!!!!!!!!!!

I didn't commit anything, instead, I submitted the fix as patch #2082.

It works in my machine. :D
Be a part of the solution, not a part of the problem.

mandrav

Quote from: mandrav on June 28, 2007, 11:05:25 PM
Rick, please, don't...

Quote from: rickg22 on June 29, 2007, 04:24:10 AM
Yiannis: Guess what.

IT WORKS!!!!!!!!!!!  :D :D :D :D :D :D :D :D :D :D :D :D :D :D :D :D

I didn't commit anything, instead, I submitted the fix as patch #2084.

Anyway, my theory is that while the classbrowserbuilderthread is deleting nodes, it's also triggering tons of events. The DeleteChildren method of wxTreeCtrl does not trigger any event. Please try it and tell me if it works for you. I notice a side effect, which is that it rebuilds the tree everytime you change the setting above it. But at least it doesn't crash for me :)

Why is nobody listening to me these days?  :?

Rick, do you have *any* idea why it was implemented like that?
Do you think I would go the hard way of removing each node individually if I had *any* reason to avoid it?
Be patient!
This bug will be fixed soon...

Agustin

That's great to know! This is the *only* bug I have experienced in Codeblocks. Can I download the patch? At least until the problem is properly resolved :D