Code::Blocks

Developer forums (C::B DEVELOPMENT STRICTLY!) => Development => Topic started by: kipade on November 22, 2019, 05:37:54 am

Title: Symbols browser issue of CC has been fixed for my Linux
Post by: kipade on November 22, 2019, 05:37:54 am
Since wx3.x, symbols browser of CC was disabled because of crash.
However, I think I need this basic function, so, I re-open the function code of CC and do a two hours test,
and found the problem of CC plugin:
1) It do GUI operations within worker thread although there is some protection, which will make it crashing
     in xcb library.
>> For this issue, I just rebuild the symbols tree with GUI main thread simply, then, the xcb crash disappear.
     but it still would crash frequently.
I took two hours to do a black-box test, and found it crashed only for some files, so, i create such a simple
project only included some files might cause the issue. And found the crash just because sort the symbols
tree node. tree->SortChildren, which is the standard interface of wx!
    I traced the crash and found the issue in std::sort. My OS is GNU/Slackware, with gcc-9.2, and the crash
point located in: /usr/include/c++/9.2.0/bits/stl_algo.h
Code: [Select]
  /// This is a helper function for the sort routine.
  template<typename _RandomAccessIterator, typename _Compare>
    void
    __unguarded_linear_insert(_RandomAccessIterator __last,
      _Compare __comp)
    {
      typename iterator_traits<_RandomAccessIterator>::value_type
__val = _GLIBCXX_MOVE(*__last);
      _RandomAccessIterator __next = __last;
      --__next;
      while (__comp(__val, __next))  ---->ISSUE: might go ahead of the first iterator
{
  *__last = _GLIBCXX_MOVE(*__next);
  __last = __next;
  --__next;
}
      *__last = _GLIBCXX_MOVE(__val);
    }
and found the other issue:
2) the non-deterministic compares will make std::sort(Introspective Sort)'s second step will go ahead the the head of the
vector array, which lead a invalid reference.
Code: [Select]
    if (!lhs || !rhs)
        return 1;
    if (lhs->m_SpecialFolder != sfToken || rhs->m_SpecialFolder != sfToken)
        return -1;
    if (!lhs->m_Token || !rhs->m_Token)
        return 1;
the code slice above is cited from CCTreeCtrl's treenode compare function, that will got some  non-deterministic order
of some items. I simple fixed by expanding the || operation.

Because my locale code is different with the svn code, I just packaged my changed in a tarball and uploaded it here.
I submitted my simple solution at: https://github.com/kipade/codeblocks_sf/commit/f607bfb8e2f23645ba3f2e1900d41bea488fb081

I tested the solution on my computer. My environment is:
GNU/Slackware X86_64, current, with wx3.1.3
You are welcome to test it. And I home some developers can make a professional fix the release the right version.
Title: Re: Symbols browser issue of CC has been fixed for my Linux
Post by: oBFusCATed on November 22, 2019, 10:28:17 am
Good but what is the performance of this change?
What happens if you open a big project?
How much time does it take to execute the ClassBrowser::SyncBuildTree function?

Keep in mind that everything above 50-100msec is unacceptable.
Title: Re: Symbols browser issue of CC has been fixed for my Linux
Post by: kipade on November 22, 2019, 12:21:33 pm
Good question. Yes, I have not done enough pressure test.
but, as i said this just a simple solution and expect the right professional fix. also is a proof of the bug issue
Another word, I had tested using some of my big projects, it work fine, working at least.
Title: Re: Symbols browser issue of CC has been fixed for my Linux
Post by: oBFusCATed on November 22, 2019, 09:06:29 pm
We know what the problem is.
There is no single person willing to spend the time to do the correct fix.
I don't have the time nor interest in doing this any time soon.

ollydbg had a similar fix in some of the topics about this issue.
Title: Re: Symbols browser issue of CC has been fixed for my Linux
Post by: kipade on November 23, 2019, 04:22:55 pm
If so, I think do it by myself.
Fortunately, I will have some time slices in dutu
y days.I will do my best to improve it, If I can, an If I can do.
Title: Re: Symbols browser issue of CC has been fixed for my Linux
Post by: RRomano001 on November 24, 2019, 12:28:36 pm
We know what the problem is.
There is no single person willing to spend the time to do the correct fix.
I don't have the time nor interest in doing this any time soon.

ollydbg had a similar fix in some of the topics about this issue.
Hi, your word scary me a lot about this.

 I feel this scenario:
 Bug was known but none is interested to fix it?
 Leaving this bug fire a dangling reference to somewhere in memory, this seems work on windows where memory leakage come mainly from OS than application and ignored. Linux/Unixes caught it and abort the offending program when it try access memory area without owner right.

 A similar fix was proposed but never applied to.. This is again exposing C::B to dangling code endangering reliability of a great program.

 Am I wrong about?
Title: Re: Symbols browser issue of CC has been fixed for my Linux
Post by: oBFusCATed on November 24, 2019, 01:17:08 pm
Am I wrong about?
The feature is disabled when it leads to problems, so users don't hit the problem.

And yes every software is full of bugs, many of them are known to the developers, but they don't have time to fix all of them. That's life.
Title: Re: Symbols browser issue of CC has been fixed for my Linux
Post by: kipade on November 25, 2019, 02:59:16 am
I think I can realize the reality.
The fact is, CB just an opensource project and with only few volunteers working for it using their free time with no pay. I also think ALL the developing users of CB will have the obligation to fix its bugs and improve it, only this can make CB become better and better.
We know what the problem is.
There is no single person willing to spend the time to do the correct fix.
I don't have the time nor interest in doing this any time soon.

ollydbg had a similar fix in some of the topics about this issue.
However, I don't agree this.  If there were some known bugs with potential solution, someone should share the issue with others even though he or she was no interest in fixing it, instead leaving other users to wasting time to re-work for it.

And, as I said before, I will take some time within every duty day to learning and improve CB, do what I can do to improve CB. I hope it can be better.
I also hope everyone here, not only tying your king fingers but also open your arms to improve such an opensource product.
Regards.
Title: Re: Symbols browser issue of CC has been fixed for my Linux
Post by: ollydbg on November 25, 2019, 06:16:14 am
ollydbg had a similar fix in some of the topics about this issue.
This is the direction I would like to go if I have time, but it looks like this is quite complex.
Especially if we have a lot of tokens to shown in the tokentree.
See here:
Any method to build a big wxTreeCtrl progressively in GUI thread? (https://forums.wxwidgets.org/viewtopic.php?f=1&t=43221)
Title: Re: Symbols browser issue of CC has been fixed for my Linux
Post by: Miguel Gimenez on November 25, 2019, 09:46:02 am
I am currently working on a solution and it is almost complete (it needs some polishing and testing).

I create the tree in a thread (ThreadedBuildTree() lasts 30 ms) using a non-GUI tree class, and then use the creation end event to dump the tree to the wxTreeCtrl in the main thread. This part, of course, is time critical, but dumping a ready made tree is way faster than creating it.

Once created the two trees are in sync, and both expand and collapse dynamically and quickly.

I have attached the current (not final) patch, so it can be tested/commented/used as reference or rejected.
Title: Re: Symbols browser issue of CC has been fixed for my Linux
Post by: oBFusCATed on November 25, 2019, 08:18:15 pm
Do you have some time measurements how much does it take to do the copy from CCTree to wxTreeCtrl? I'm interested to see the numbers for C::B's project/workspace for example.
10ms is something like the maximum allowed for this process. Anything else would cause bad pauses. :( So you should prepare the code to do this copy operation in batches in multiple on-idle/call-after events.

I've just taken a quick look at the patch, some comments:
1. I don't like std::lists; they are slow, really slow (https://www.youtube.com/watch?v=YQs6IC-vgmo). If you really need a linked list this should be your last resort and you should use intrusive lists.
2. Even more I don't like putting lists/vectors as members in tree item objects. This is massive performance disaster, because your algorithm would be dominated by calls to new/delete and the memory access pattern would be a disaster from CPU's point of view! If you want to be fast you want to use linear arrays as much as possible! And your nodes must be minimal in size.
3. The use of CCTree seems rather complex and it is a lot of code :( Generally I think the whole SymbolBrowser code should be redone. Currently it is linked/coupled too much to the implementation of the C/C++ CC plugin. Last time I've looked the fortran plugin had a copy of this code. :(
Title: Re: Symbols browser issue of CC has been fixed for my Linux
Post by: Miguel Gimenez on November 25, 2019, 08:32:39 pm
Quote
The use of CCTree seems rather complex
It has exactly the same interface of wxTreeCtrl without the GUI part, the only visible difference are the use of pointers to items and the FindFirstChild() cookie type.

I'll measure the performance tomorrow and will look for a list replacement.
Title: Re: Symbols browser issue of CC has been fixed for my Linux
Post by: New Pagodi on November 25, 2019, 11:21:16 pm
You can build a n-ary tree structure without the need to use a list/vector structure for the child nodes using a structure like this:

Code: [Select]
struct NaryTreeNode
{
    void* data;
    NaryTreeNode* nextSibling;
    NaryTreeNode* firstChild;
};

You can iterate over the children of a NaryTreeNode n like so:

Code: [Select]
for ( NaryTreeNode* i = n->firstChild; i!=NULL; i=i->nextSibling )
{...

The main drawback of this approach is that that you can't get an arbitrary child of a node without iterating over the necessary number of nodes.

I don't know if this is of any help, but I thought I'd mention it.  Sorry if it's not of any help.
Title: Re: Symbols browser issue of CC has been fixed for my Linux
Post by: Miguel Gimenez on November 26, 2019, 09:44:56 am
@New Pagodi, thank you for your suggestion.

I have just made some measurements with CB project:

- Current projects symbols
    - tree creation 36 ms
    - top tree dump 227 ms
    - bottom tree (creation+dump)
        - Global functions 172+132
        - Global typedefs 45+29
        - Global variables 129+97
        - Macro definitions 1483+1093

- Everything
    - tree creation 427 ms
    - top tree dump 452 ms
    - bottom tree (creation+dump)
        - Global functions 9422+7702
        - Global typedefs 2637+2003
        - Global variables 709+526
        - Macro definitions 39111+26790

I will try a list replacement, hopefully it will reduce the tree creation parts. The dumping part needs more thinking.
Title: Re: Symbols browser issue of CC has been fixed for my Linux
Post by: oBFusCATed on November 26, 2019, 07:54:42 pm
Which of these happen on the main UI thread?
Title: Re: Symbols browser issue of CC has been fixed for my Linux
Post by: Miguel Gimenez on November 26, 2019, 08:14:17 pm
The second (dump)


Edit: both are executed in the main thread, and the first number was mistakenly including the second. In my next message the numbers are corrected and compared with the new version
Title: Re: Symbols browser issue of CC has been fixed for my Linux
Post by: Miguel Gimenez on November 27, 2019, 12:31:51 pm
I have changed the std::list to a kind of intrusive list (each element has pointers to parent, previous and next siblings and first child).

I still have to adapt the quicksort algorithm, but the timings with CB project look better. Below are the old times (tree creation times revised) wth the new ones at the right side (remember, no sort).

- Current projects symbols
    - tree creation 36 ms, now 8 ms
    - top tree dump 227 ms, now 15 ms
    - bottom tree (creation+dump)
        - Global functions 40+132, now 21+105
        - Global typedefs 16+29, now 13+26
        - Global variables 32+97, now 17+77
        - Macro definitions 390+1093, now 167+707

- Everything
    - tree creation 427 ms, now 241 ms
    - top tree dump 452 ms, now 159 ms
    - bottom tree (creation+dump)
        - Global functions 1720+7702, now 838+2264
        - Global typedefs 634+2003, now 329+1496
        - Global variables 183+526, now 114+435
        - Macro definitions 12321+26790, now 5803+14174

The top tree creation is made in the worker thread, while the dump and the bottom tree work are made in the main thread.
Title: Re: Symbols browser issue of CC has been fixed for my Linux
Post by: Miguel Gimenez on November 28, 2019, 11:23:01 am
Quicksort reactivated; the timings for tree creation have increased, but not much

21 -> 30
13 -> 14
17 -> 23
167 -> 215
838 -> 978
329 -> 384
114 -> 143
5803 -> 6211
Title: Re: Symbols browser issue of CC has been fixed for my Linux
Post by: oBFusCATed on November 30, 2019, 10:33:20 am
The posts you're making aren't very clear.
As I've said earlier we're interested only/mostly in the timings in the main thread.
How long does it take to execute the workers is not that important (it is, but it is secondary).
The question is what is taking the time? You'll have to use a profiler. Try either vtune or perf.
VTune is easier to setup for stack-gathering and it recently switched to be free instead of being mightily expensive.

As I've said previously the main thread must not pause for more than 10ms during this operation.
After you know what is slow you could decide what is best course of action. I won't be surprised that the tree-ctrl api is slow.
Title: Re: Symbols browser issue of CC has been fixed for my Linux
Post by: ollydbg on November 30, 2019, 10:41:22 am
One idea: why not creating the whole tree, is there any optimized way we can build some part of the tree which are shown to the user. That's only a very small part of the whole tree. If user scroll up and down the tree, we have to build the tree gradually.
Title: Re: Symbols browser issue of CC has been fixed for my Linux
Post by: oBFusCATed on November 30, 2019, 10:43:44 am
For lists this concept/mode is called virtual list. We use this to make opening the alt-g dialog to be really fast no matter the size of the project (the dialog opens in <100ms even on the linux kernel project (40+k files)).

I'm not sure this is available for trees though :( Probably we could do create-children-on-expand thing, but I'm not sure if this would benefit us.

As I've said we first need to know what is slow then we could find a solution. And more importantly why it is slow. Then we'll be able to find a solution. Guessing about performance is never a good idea.
Title: Re: Symbols browser issue of CC has been fixed for my Linux
Post by: Miguel Gimenez on November 30, 2019, 11:59:10 am
I was using wxStopWatch.

The code works the same as before, only the dump parts have been added, and they use the main thread because it is the only one allowed to access the CCTreeCtrl.

- The top tree creation is made in the worker thread as before.
- The worker thread only activates (now and before) when the top tree changes due to a code completion token tree change.
- The top tree dump is made by the main thread when the tree is finished (this part is new).
- The bottom tree creation and dump are made by the main thread in the OnSelect event (just like before). Of course, the dump adds delay.

The tree leaves are created dynamically when expanding their parent, and deleted when the parent is collapsed, just like in the original code. This work is (and was) made by the main thread.

I find it quite usable if you don't use the Everything option.

I have attached my final changes, just in case anybody wants to test/profile/modify or reuse parts.
Title: Re: Symbols browser issue of CC has been fixed for my Linux
Post by: earlgrey on November 30, 2019, 09:00:20 pm
Seems to work, thank you.
Title: Re: Symbols browser issue of CC has been fixed for my Linux
Post by: ollydbg on December 02, 2019, 03:57:36 pm
I was using wxStopWatch.

The code works the same as before, only the dump parts have been added, and they use the main thread because it is the only one allowed to access the CCTreeCtrl.

- The top tree creation is made in the worker thread as before.
- The worker thread only activates (now and before) when the top tree changes due to a code completion token tree change.
- The top tree dump is made by the main thread when the tree is finished (this part is new).
- The bottom tree creation and dump are made by the main thread in the OnSelect event (just like before). Of course, the dump adds delay.

The tree leaves are created dynamically when expanding their parent, and deleted when the parent is collapsed, just like in the original code. This work is (and was) made by the main thread.

I find it quite usable if you don't use the Everything option.

I have attached my final changes, just in case anybody wants to test/profile/modify or reuse parts.
I try to apply the patch file "symbol_browser.patch" in my local git repo.

But it looks like I have no way to apply the patch. :(

Code: [Select]
$ patch -p0 ../symbol_browser.patch

This will make the patch command hangs without  returning, I have to press the "CTRL+C" to halt the patch command. (I'm using the shell from git-for-windows)


EDIT:
There is another issue, I see this patch contains some changes like:
Code: [Select]
-            const TokenIdxSet* tokens = tree->GetTokensBelongToFile(*itf);
+            const TokenIdxSet *tokens = tree->GetTokensBelongToFile(*itf);
I would still prefer the old styling.  :)
Title: Re: Symbols browser issue of CC has been fixed for my Linux
Post by: Miguel Gimenez on December 02, 2019, 06:40:03 pm
Here you have a revised copy with the coding standard restored. I prefer the other way, but obviously the existing standard must be respected.

The patch is generated with svn (svn diff > symbol_browser.patch), I can generate it with svn diff --git if you need it.
in the next message you have a version generated with --git option.

I have been testing timings in Symbol Browser with 17.12, and the delays in main thread are similar (as I said above, most of the work in the bottom tree is, and was, made by the main thread).

Edit 22-10-2020: published new patch correcting an uninitialized pointer, see http://forums.codeblocks.org/index.php/topic,23580.msg164959.html#msg164959 (http://forums.codeblocks.org/index.php/topic,23580.msg164959.html#msg164959)
Title: Re: Symbols browser issue of CC has been fixed for my Linux
Post by: Miguel Gimenez on December 02, 2019, 06:45:56 pm
I have attached a patch file generated with svn diff --git
Title: Re: Symbols browser issue of CC has been fixed for my Linux
Post by: kipade on December 10, 2019, 04:04:19 am
I have attached a patch file generated with svn diff --git
after several busy days, I tried this patch and it works find for me.
I use git, use this command to do:
Code: [Select]
git apply ~/Downloads/symbol_browser_git.patch  -p2
Thanks for this perfect work and patch.
Title: Re: Symbols browser issue of CC has been fixed for my Linux
Post by: oBFusCATed on December 10, 2019, 09:24:41 am
Thanks for this perfect work and patch.
I guess your project is either small or you could tolerate long UI pauses.
Title: Re: Symbols browser issue of CC has been fixed for my Linux
Post by: Miguel Gimenez on December 10, 2019, 02:03:10 pm
Most of the pauses are already in the original code, the greatest one is in the OnSelect() event due to full bottom tree creation in main thread.
Title: Re: Symbols browser issue of CC has been fixed for my Linux
Post by: kipade on December 11, 2019, 02:24:25 am
Most of the pauses are already in the original code, the greatest one is in the OnSelect() event due to full bottom tree creation in main thread.
Yes, you are right. there are some short pauses when click the top tree items.
Since it have to be done in the main UI thread, I think no way to avoid that if did not keep all parsed symbols tree item in memory.
Title: Re: Symbols browser issue of CC has been fixed for my Linux
Post by: ollydbg on December 19, 2019, 04:29:38 pm
Miguel Gimenez's patch works OK for my self build C::B.
Thanks!
I would suggest this for the next release.
I will take more time to test it in the future days.
Title: Re: Symbols browser issue of CC has been fixed for my Linux
Post by: Miguel Gimenez on December 19, 2019, 06:24:56 pm
Thank you for testing
Title: Re: Symbols browser issue of CC has been fixed for my Linux
Post by: oBFusCATed on December 19, 2019, 08:34:50 pm
I would suggest this for the next release.
Do you get UI pauses? Because this is a major no-go...
Title: Re: Symbols browser issue of CC has been fixed for my Linux
Post by: tigerbeard on February 01, 2020, 10:39:19 am
Amazing! Just saw this thread. I have never dreamt that this issue is going to find such a progress so soon.
BIG Thanks to all involved!   :D :D :D :D :D

The symbol tree is the only reason I am still stuck with V16. In Linux I actually have used a compiled V17 version with the inhibit switch enabled, so I could use it. I use it quite regulary despite a few crashes  :-[.  Now I understood there is a working version, maybe a bit slower but not crashing. Am I correct that there is not binary for Linux, but I need to get the master, apply the patch and compile it?

I would suggest this for the next release.
+1+1+1+1+1

Do you get UI pauses? Because this is a major no-go...
I can fully understand that someone not using that feature must have reservations about adding a not fully performant piece of UI. But I beg you to re-consider your position. Unless there is no safe way to protect the UI performance when the Symbol browser is diabled, I think this is a special situation. We have the choice between a very useful function (but slow yet) or no useful function at all. As a C::B user I would not like to be locked out of that decision.

And yes I do have quite large projects where a lagging SB might be an issue. But yes I also have a lot of small ones. If if can be safely disabled any time, what are we loosing? Also there are chances to find solutions the old version did not have, e.g. a filter that ignores Macro, Defines, Globals etc that i would hide most of the time (if any of that adds up).

Maybe it would be a compromise to enable the SymbolBrowser switch in the Preferences again, but set it to Off and add a dialog saying "Warning! Feature in Development - this is not fully tested and not profiled yet. Not recommended for production, it will slow down you UI".


Title: Re: Symbols browser issue of CC has been fixed for my Linux
Post by: oBFusCATed on February 01, 2020, 11:21:44 am
I can fully understand that someone not using that feature must have reservations about adding a not fully performant piece of UI. But I beg you to re-consider your position.
You'll have the right to beg after you try it with your bigger projects. :)
But this won't help anyway, pauses larger than 10ms are unacceptable.
So if you need the feature start looking at the code with a profiler and try to limit the main thread execution to 10ms.

I'll get to it someday, but at the moment this is very low priority.
Title: Re: Symbols browser issue of CC has been fixed for my Linux
Post by: tigerbeard on February 03, 2020, 01:17:33 am
You'll have the right to beg after you try it with your bigger projects. :)

OK got it running in windows (thanks for the new updated User Manual, btw  8)! ). So that is Windows feedback only (yet, hope I get Linux to compile it as well soon).

For better coparison I just used the C::B source tree with all addons for a large test project (1200 files. 250k LOC).
So I really can not confirm any performance impacts, sorry. Whatever you can measure might be something different, but a negative impact on a fluent work flow could not be seen in this test.   

There is one severe problem for practical use:
 The browser often closes the opened class and jumps to the first entry. It looks like its loosing its postition. It does not happen every time, possibly it has to do with windows not yet loaded. Here is how to Reproduce
     1. open CodeBlocks workspace and switch to Symbols tab. No windows should be open in the editor
     2 scroll to ClassBrowser and open
     3. double click on first memeber var "m_activeFilename: wxString"
    => The header file will open. The class browser closes the class and jumps to the top entry. This closing was on my system delayed by about 1-2secs.
    => It also happens sometimes if the header is open but not the cpp.
    => This does not happen any more if the header file is already open.

Title: Re: Symbols browser issue of CC has been fixed for my Linux
Post by: oBFusCATed on February 03, 2020, 08:56:00 am
So I really can not confirm any performance impacts, sorry. Whatever you can measure might be something different, but a negative impact on a fluent work flow could not be seen in this test.   
The negative impact is when you're not using it and you're just typing and your typing is interrupted by this feature.
Title: Re: Symbols browser issue of CC has been fixed for my Linux
Post by: tigerbeard on February 03, 2020, 03:38:30 pm
The negative impact is when you're not using it and you're just typing and your typing is interrupted by this feature.
Now I understand why you are mainly interested in the main thread timing. Thanks for clarifying.

Since the tree is built in the main thread (i.e. at initial load) there are two cases for the timing. One when the tree is being actively used (e.g. it just opens a new branch) and the other when its idle/or just displaying its structure unchanged.  A third one could be if its disabled, but I guess its considered unacceptable design if that would still use up performance.
Do the 10ms apply for the first two cases or for the second case only?

 
Title: Re: Symbols browser issue of CC has been fixed for my Linux
Post by: oBFusCATed on February 03, 2020, 07:28:41 pm
Sort of it applies. If something is interacted by the user and there is no feedback that something is happening then this is a problem of the application.
Title: Re: Symbols browser issue of CC has been fixed for my Linux
Post by: tigerbeard on February 04, 2020, 03:57:01 pm
There is one severe problem for practical use:
 The browser often closes the opened class and jumps to the first entry. It looks like its loosing its postition. It does not happen every time, possibly it has to do with windows not yet loaded. Here is how to Reproduce
     1. open CodeBlocks workspace and switch to Symbols tab. No windows should be open in the editor
     2 scroll to ClassBrowser and open
     3. double click on first memeber var "m_activeFilename: wxString"
    => The header file will open. The class browser closes the class and jumps to the top entry. This closing was on my system delayed by about 1-2secs.
    => It also happens sometimes if the header is open but not the cpp.
    => This does not happen any more if the header file is already open.

Update: the error seems to be only applicable when the bottom tree is switched off.
Title: Re: Symbols browser issue of CC has been fixed for my Linux
Post by: AZ on February 23, 2020, 04:45:25 am
hello,
 any plans to add this patch to nightly build ?
Title: Re: Symbols browser issue of CC has been fixed for my Linux
Post by: oBFusCATed on February 23, 2020, 01:48:00 pm
No, nothing has changed recently and I've stated many times why the current patch is not acceptable.
Title: Re: Symbols browser issue of CC has been fixed for my Linux
Post by: tigerbeard on February 24, 2020, 02:21:52 pm
hello,
 any plans to add this patch to nightly build ?

Sort summary for future readers of this thread:


Title: Re: Symbols browser issue of CC has been fixed for my Linux
Post by: AZ on April 12, 2020, 02:19:50 am
@tiger,
  How do i enable symbols browser with wx3 ?  or, as the warning states, it will crash and burn the app?
I really would not want to go back to wx2 - the look&feel is so dated :(

I applied the patch to latest nightly  12040

Title: Re: Symbols browser issue of CC has been fixed for my Linux
Post by: oBFusCATed on April 12, 2020, 02:33:01 am
Read the topic from the beginning. :)
Title: Re: Symbols browser issue of CC has been fixed for my Linux
Post by: AZ on April 12, 2020, 05:48:22 am
Read the topic from the beginning. :)
//scratching my head
i did, that's why i applied the patch to see if it would work "good enough" on my small projects. Not sure how to enable the browser..
Title: Re: Symbols browser issue of CC has been fixed for my Linux
Post by: stahta01 on April 12, 2020, 12:56:45 pm
Read the topic from the beginning. :)
//scratching my head
i did, that's why i applied the patch to see if it would work "good enough" on my small projects. Not sure how to enable the browser..

Did you see if the plugin manager list the plugin?

Plugins -> Manage Plugins

If listed, try to enable if disabled.

Tim S.
Title: Re: Symbols browser issue of CC has been fixed for my Linux
Post by: oBFusCATed on April 12, 2020, 01:26:32 pm
If the option is disabled after the patch application, you need to search for the text in the code, then find the code which disables it and remove it...
Title: Re: Symbols browser issue of CC has been fixed for my Linux
Post by: tigerbeard on April 12, 2020, 03:07:25 pm
@tiger,
  How do i enable symbols browser with wx3 ?  or, as the warning states, it will crash and burn the app?
I really would not want to go back to wx2 - the look&feel is so dated :(

I applied the patch to latest nightly  12040
In my builds I used wx3.1.3 compiler with gcc.8.1.0._64bit . In Linux same wx version, compiler I just used the default one. The most complex part was to compile the special version of wx for Codeblocks.
I can not recall any compile errors. Once it started it went though ok. Also I can not remember any evil warnings, but I did not check the build log really.
 
In my case the symbol browser was enabled already. If not check Menu/Settings/Editor/CodeCompletion/SymbolBrowser. If you do not have an enabled checkbox to enable/disable Symbol browser, something might have gone wrong when applying the patch to the sources before compiling.
It did not crash and the only things I found I listed above. Not sure what you mean with "burn the app".

To be honest, I did not note a big difference between CB with wx2.8/wx3.0.

Help it helps.



Title: Re: Symbols browser issue of CC has been fixed for my Linux
Post by: oBFusCATed on April 12, 2020, 03:11:21 pm
To be honest, I did not note a big difference between CB with wx2.8/wx3.0.
His wxgtk3 is probably using gtk3 and that is why he is seeing this "non-dated" look. :)
Title: Re: Symbols browser issue of CC has been fixed for my Linux
Post by: AZ on April 12, 2020, 09:06:56 pm
@tiger,
  How do i enable symbols browser with wx3 ?  or, as the warning states, it will crash and burn the app?
I really would not want to go back to wx2 - the look&feel is so dated :(

I applied the patch to latest nightly  12040
In my builds I used wx3.1.3 compiler with gcc.8.1.0._64bit . In Linux same wx version, compiler I just used the default one. The most complex part was to compile the special version of wx for Codeblocks.
I can not recall any compile errors. Once it started it went though ok. Also I can not remember any evil warnings, but I did not check the build log really.
 
In my case the symbol browser was enabled already. If not check Menu/Settings/Editor/CodeCompletion/SymbolBrowser. If you do not have an enabled checkbox to enable/disable Symbol browser, something might have gone wrong when applying the patch to the sources before compiling.
It did not crash and the only things I found I listed above. Not sure what you mean with "burn the app".

To be honest, I did not note a big difference between CB with wx2.8/wx3.0.

Help it helps.


Gents,
 thank you for trying to help.
The plugin is enabled according to the plugin manager.

BUT, in the Editor setting, the "enable" option is unavailable.

I didn't examine the build log. Let me check what i can find there.
see update below.

grep for gtk:
Code: [Select]
rpm -qa | grep gtk
PackageKit-gtk3-module-1.1.12-8.fc30.x86_64
libindicator-gtk3-12.10.1-14.fc30.x86_64
bluebird-gtk3-theme-1.3-2.fc30.noarch
clutter-gtk-1.8.4-5.fc30.x86_64
compat-wxGTK3-gtk2-devel-3.0.4-8.fc30.x86_64
greybird-gtk2-theme-3.22.10-1.fc30.noarch
ibus-gtk2-1.5.20-5.fc30.x86_64
gtk2-2.24.32-6.fc30.x86_64
gtk2-devel-2.24.32-6.fc30.x86_64
gtkmathview-0.8.0-27.fc30.x86_64
webkit2gtk3-jsc-2.28.0-6.fc30.x86_64
gtkspell-2.0.16-18.fc30.x86_64
compat-wxGTK3-gtk2-3.0.4-8.fc30.x86_64
bluebird-gtk2-theme-1.3-2.fc30.noarch
lightdm-gtk-2.0.5-3.fc30.x86_64
greybird-gtk3-theme-3.22.10-1.fc30.noarch
albatross-gtk3-theme-1.7.4-6.fc30.noarch
webkit2gtk3-2.28.0-6.fc30.x86_64
gtk3-devel-3.24.11-1.fc30.x86_64
libreoffice-gtk3-6.2.8.2-2.fc30.x86_64
gstreamer1-plugins-good-gtk-1.16.0-1.fc30.x86_64
libpeas-gtk-1.22.0-10.fc30.x86_64
libcanberra-gtk3-0.30-19.fc30.x86_64
gtk-xfce-engine-3.2.0-9.fc30.x86_64
transmission-gtk-2.94-6.fc30.x86_64
albatross-gtk2-theme-1.7.4-6.fc30.noarch
libreport-gtk-2.12.0-1.fc30.x86_64
gtk-unico-engine-1.0.3-0.13.20140109bzr152.fc30.x86_64
pygtk2-2.24.0-25.fc30.x86_64
gtk-murrine-engine-0.98.2-16.fc30.x86_64
gtksourceview3-3.24.11-1.fc30.x86_64
gtk-update-icon-cache-3.24.11-1.fc30.x86_64
libappindicator-gtk3-12.10.0-24.fc30.x86_64
compat-wxGTK3-gtk2-gl-3.0.4-8.fc30.x86_64
adwaita-gtk2-theme-3.28-5.fc30.x86_64
gtkmm30-3.24.2-1.fc30.x86_64
gtk3-3.24.11-1.fc30.x86_64
ibus-gtk3-1.5.20-5.fc30.x86_64
colord-gtk-0.1.26-11.fc30.x86_64
libdbusmenu-gtk3-16.04.0-11.fc30.x86_64
compat-wxGTK3-gtk2-media-3.0.4-8.fc30.x86_64
gtk2-engines-2.20.2-18.fc30.x86_64
xdg-user-dirs-gtk-0.10-15.fc30.x86_64

Here is the relevant section from the mock's build:
Code: [Select]
<skipped>
Building target platforms: x86_64
Building for target x86_64
Wrote: /builddir/build/SRPMS/codeblocks-20.03.svn.12045-1.fc30.src.rpm
Child return code was: 0
ENTER ['do_with_status'](['bash', '--login', '-c', '/usr/bin/rpmbuild -bb --target x86_64 --nodeps /builddir/build/SPECS/codebloc
ks.spec'], chrootPath='/var/lib/mock/fedora-30-x86_64/root'env={'TERM': 'vt100', 'SHELL': '/bin/bash', 'HOME': '/builddir', 'HOST
NAME': 'mock', 'PATH': '/usr/bin:/bin:/usr/sbin:/sbin', 'PROMPT_COMMAND': 'printf "\\033]0;<mock-chroot>\\007"', 'PS1': '<mock-ch
root> \\s-\\v\\$ ', 'LANG': 'en_US.utf8'}shell=Falselogger=<mockbuild.trace_decorator.getLog object at 0x7fa39c1c5c50>timeout=0ui
d=1000gid=135user='mockbuild'nspawn_args=['--capability=cap_ipc_lock', '--bind=/tmp/mock-resolv.t9ehylqn:/etc/resolv.conf', '--bi
nd=/dev/loop-control', '--bind=/dev/loop0', '--bind=/dev/loop1', '--bind=/dev/loop2', '--bind=/dev/loop3', '--bind=/dev/loop4', '
--bind=/dev/loop5', '--bind=/dev/loop6', '--bind=/dev/loop7', '--bind=/dev/loop8', '--bind=/dev/loop9', '--bind=/dev/loop10', '--
bind=/dev/loop11']unshare_net=TrueprintOutput=True)
Using nspawn with args ['--capability=cap_ipc_lock', '--bind=/tmp/mock-resolv.t9ehylqn:/etc/resolv.conf', '--bind=/dev/loop-contr
ol', '--bind=/dev/loop0', '--bind=/dev/loop1', '--bind=/dev/loop2', '--bind=/dev/loop3', '--bind=/dev/loop4', '--bind=/dev/loop5'
, '--bind=/dev/loop6', '--bind=/dev/loop7', '--bind=/dev/loop8', '--bind=/dev/loop9', '--bind=/dev/loop10', '--bind=/dev/loop11']
Executing command: ['/usr/bin/systemd-nspawn', '-q', '-M', 'c6daa95895f642f298141ca5a7752a01', '-D', '/var/lib/mock/fedora-30-x86
_64/root', '-a', '--capability=cap_ipc_lock', '--bind=/tmp/mock-resolv.t9ehylqn:/etc/resolv.conf', '--bind=/dev/loop-control', '-
-bind=/dev/loop0', '--bind=/dev/loop1', '--bind=/dev/loop2', '--bind=/dev/loop3', '--bind=/dev/loop4', '--bind=/dev/loop5', '--bi
nd=/dev/loop6', '--bind=/dev/loop7', '--bind=/dev/loop8', '--bind=/dev/loop9', '--bind=/dev/loop10', '--bind=/dev/loop11', '--set
env=TERM=vt100', '--setenv=SHELL=/bin/bash', '--setenv=HOME=/builddir', '--setenv=HOSTNAME=mock', '--setenv=PATH=/usr/bin:/bin:/u
sr/sbin:/sbin', '--setenv=PROMPT_COMMAND=printf "\\033]0;<mock-chroot>\\007"', '--setenv=PS1=<mock-chroot> \\s-\\v\\$ ', '--seten
v=LANG=en_US.utf8', '-u', 'mockbuild', 'bash', '--login', '-c', '/usr/bin/rpmbuild -bb --target x86_64 --nodeps /builddir/build/S
PECS/codeblocks.spec'] with env {'TERM': 'vt100', 'SHELL': '/bin/bash', 'HOME': '/builddir', 'HOSTNAME': 'mock', 'PATH': '/usr/bi
n:/bin:/usr/sbin:/sbin', 'PROMPT_COMMAND': 'printf "\\033]0;<mock-chroot>\\007"', 'PS1': '<mock-chroot> \\s-\\v\\$ ', 'LANG': 'en
_US.utf8'} and shell False
Building target platforms: x86_64
Building for target x86_64
Executing(%prep): /bin/sh -e /var/tmp/rpm-tmp.7JoSBB
 umask 022
+ cd /builddir/build/BUILD
+ cd /builddir/build/BUILD
+ rm -rf codeblocks-17.12.svn/trunk
+ /usr/bin/gzip -dc /builddir/build/SOURCES/codeblocks-20.03.svn.12045.tar.bz2
+ /usr/bin/tar -xof -
+ STATUS=0
+ '[' 0 -ne 0 ']'
+ cd codeblocks-17.12.svn/trunk
+ /usr/bin/chmod -Rf a+rX,u+w,g-w,o-w .
Patch #0 (symbol_browser.patch):
+ echo 'Patch #0 (symbol_browser.patch):'
+ /usr/bin/patch --no-backup-if-mismatch -p0 --fuzz=0
(Stripping trailing CRs from patch; use --binary to disable.)
patching file src/plugins/codecompletion/ccoptionsdlg.cpp
(Stripping trailing CRs from patch; use --binary to disable.)
patching file src/plugins/codecompletion/cctreectrl.h
(Stripping trailing CRs from patch; use --binary to disable.)
patching file src/plugins/codecompletion/classbrowser.cpp
(Stripping trailing CRs from patch; use --binary to disable.)
patching file src/plugins/codecompletion/classbrowserbuilderthread.cpp
(Stripping trailing CRs from patch; use --binary to disable.)
patching file src/plugins/codecompletion/classbrowserbuilderthread.h
(Stripping trailing CRs from patch; use --binary to disable.)
patching file src/plugins/codecompletion/codecompletion.cpp
(Stripping trailing CRs from patch; use --binary to disable.)
patching file src/plugins/codecompletion/nativeparser.cpp
+ ./bootstrap
Found revision: '0' ''
rm: missing operand
Try 'rm --help' for more information.
libtoolize: putting auxiliary files in '.'.
libtoolize: copying file './ltmain.sh'
libtoolize: putting macros in AC_CONFIG_MACRO_DIRS, 'm4'.
libtoolize: copying file 'm4/libtool.m4'
libtoolize: copying file 'm4/ltoptions.m4'
libtoolize: copying file 'm4/ltsugar.m4'
libtoolize: copying file 'm4/ltversion.m4'
libtoolize: copying file 'm4/lt~obsolete.m4'
configure.ac:26: installing './compile'
configure.ac:7: installing './config.guess'
configure.ac:7: installing './config.sub'
configure.ac:22: installing './install-sh'
configure.ac:22: installing './missing'
src/base/tinyxml/Makefile.am: installing './depcomp'
+ find . -type f -and -not -name '*.cpp' -and -not -name '*.h' -and -not -name '*.png' -and -not -name '*.bmp' -and -not -name '*
.c' -and -not -name '*.cxx' -and -not -name '*.ico' -exec dos2unix -q --keepdate '{}' ';'
+ exit 0
Executing(%build): /bin/sh -e /var/tmp/rpm-tmp.rfi2F2
 umask 022
+ cd /builddir/build/BUILD
+ cd codeblocks-17.12.svn/trunk
<skipped>
checking whether to use gtk-notebook as default notebook... yes
checking which (if any) contrib plugins to build... all
checking if the compiler supports precompiled headers... yes
checking for wx-config... /usr/bin/wx-config
checking for wxWidgets version >= 2.8.12... yes (version 3.0.4)
checking for wxWidgets static library... no
checking for wxWidgets platform... wxGTK
checking for GLIB2... yes
checking for HUNSPELL... yes
configure: gtk3 used
checking for GTK... yes
configure: gdk3 used
checking for GDK... yes
checking for GAMIN... yes
checking for FONTCONFIG... yes
checking for boostlib >=  (102000)... yes
checking whether the Boost::System library is available... yes
checking for exit in -lboost_system... yes
checking for X... libraries , headers
checking for gethostbyname... yes
checking for connect... yes
checking for remove... yes
checking for shmat... yes
checking for IceConnectionNumber in -lICE... yes
checking gcc version... 9
checking for wxWidgets >= 2.9.0... yes (version 3.0.4)
configure: (Re)setting libs for wxWidgets 3.0.4
checking for PIC flags... "-fPIC -DPIC"
checking whether g++ supports C++11 features by default... yes
configure: Configuring Code::Blocks...
configure: SVN revision 20.03svn0 ()
checking that generated files are newer than configure... done
configure: creating ./config.status
<skip>
config.status: creating src/plugins/codecompletion/Makefile
config.status: creating src/plugins/codecompletion/resources/Makefile
<skip>
make[3]: Entering directory '/builddir/build/BUILD/codeblocks-17.12.svn/trunk/src/plugins/codecompletion'
Making all in resources
make[4]: Entering directory '/builddir/build/BUILD/codeblocks-17.12.svn/trunk/src/plugins/codecompletion/resources'
<skip>
make[4]: Leaving directory '/builddir/build/BUILD/codeblocks-17.12.svn/trunk/src/plugins/codecompletion/resources'
make[4]: Entering directory '/builddir/build/BUILD/codeblocks-17.12.svn/trunk/src/plugins/codecompletion'
<skip>
In file included from parser/parserthread.h:21,
                 from parser/parser.h:22,
                 from cctreectrl.h:13,
                 from cctreectrl.cpp:20:
parser/parserthread.h: In member function 'virtual int ParserThread::Execute()':
parser/cclogger.h:161:18: warning: unused variable 'result' [-Wunused-variable]
  161 |             auto result = M.Lock();             \
      |                  ^~~~~~
parser/parserthread.h:190:9: note: in expansion of macro 'CC_LOCKER_TRACK_TT_MTX_LOCK'
  190 |         CC_LOCKER_TRACK_TT_MTX_LOCK(s_TokenTreeMutex)
      |         ^~~~~~~~~~~~~~~~~~~~~~~~~~~
parser/cclogger.h:167:18: warning: unused variable 'result' [-Wunused-variable]
  167 |             auto result = M.Unlock();           \
      |                  ^~~~~~
parser/parserthread.h:194:9: note: in expansion of macro 'CC_LOCKER_TRACK_TT_MTX_UNLOCK'
  194 |         CC_LOCKER_TRACK_TT_MTX_UNLOCK(s_TokenTreeMutex)
      |         ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~
/bin/sh ../../../libtool  --tag=CXX   --mode=compile g++ -DHAVE_CONFIG_H -I. -I../../../src/include  -I/usr/lib64/wx/include/gtk3
-unicode-3.0 -I/usr/include/wx-3.0 -D_FILE_OFFSET_BITS=64 -DWXUSINGDLL -D__WXGTK__ -pthread -I../../../src/include -I../../../src
/sdk/wxscintilla/include -DCB_AUTOCONF  -DCB_PRECOMP -DPIC -DTIXML_USE_STL=YES   -O2 -g -pipe -Wall -Werror=format-security -Wp,-
D_FORTIFY_SOURCE=2 -Wp,-D_GLIBCXX_ASSERTIONS -fexceptions -fstack-protector-strong -grecord-gcc-switches -specs=/usr/lib/rpm/redh
at/redhat-hardened-cc1 -specs=/usr/lib/rpm/redhat/redhat-annobin-cc1 -m64 -mtune=generic -fasynchronous-unwind-tables -fstack-cla
sh-protection -fcf-protection -Winvalid-pch -fPIC -fexceptions -c -o classbrowserbuilderthread.lo classbrowserbuilderthread.cpp
libtool: compile:  g++ -DHAVE_CONFIG_H -I. -I../../../src/include -I/usr/lib64/wx/include/gtk3-unicode-3.0 -I/usr/include/wx-3.0
-D_FILE_OFFSET_BITS=64 -DWXUSINGDLL -D__WXGTK__ -pthread -I../../../src/include -I../../../src/sdk/wxscintilla/include -DCB_AUTOC
ONF -DCB_PRECOMP -DPIC -DTIXML_USE_STL=YES -O2 -g -pipe -Wall -Werror=format-security -Wp,-D_FORTIFY_SOURCE=2 -Wp,-D_GLIBCXX_ASSE
RTIONS -fexceptions -fstack-protector-strong -grecord-gcc-switches -specs=/usr/lib/rpm/redhat/redhat-hardened-cc1 -specs=/usr/lib
/rpm/redhat/redhat-annobin-cc1 -m64 -mtune=generic -fasynchronous-unwind-tables -fstack-clash-protection -fcf-protection -Winvali
d-pch -fPIC -fexceptions -c classbrowserbuilderthread.cpp  -fPIC -DPIC -o .libs/classbrowserbuilderthread.o
In file included from parser/parserthread.h:21,
                 from parser/parser.h:22,
                 from nativeparser.h:10,
                 from ccoptionsprjdlg.h:12,
                 from ccoptionsprjdlg.cpp:27:
parser/parserthread.h: In member function 'virtual int ParserThread::Execute()':
parser/cclogger.h:161:18: warning: unused variable 'result' [-Wunused-variable]
  161 |             auto result = M.Lock();             \
      |                  ^~~~~~
parser/parserthread.h:190:9: note: in expansion of macro 'CC_LOCKER_TRACK_TT_MTX_LOCK'
  190 |         CC_LOCKER_TRACK_TT_MTX_LOCK(s_TokenTreeMutex)
      |         ^~~~~~~~~~~~~~~~~~~~~~~~~~~
parser/cclogger.h:167:18: warning: unused variable 'result' [-Wunused-variable]
  167 |             auto result = M.Unlock();           \
      |                  ^~~~~~
parser/parserthread.h:194:9: note: in expansion of macro 'CC_LOCKER_TRACK_TT_MTX_UNLOCK'
  194 |         CC_LOCKER_TRACK_TT_MTX_UNLOCK(s_TokenTreeMutex)
      |         ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~
/bin/sh ../../../libtool  --tag=CXX   --mode=compile g++ -DHAVE_CONFIG_H -I. -I../../../src/include  -I/usr/lib64/wx/include/gtk3
-unicode-3.0 -I/usr/include/wx-3.0 -D_FILE_OFFSET_BITS=64 -DWXUSINGDLL -D__WXGTK__ -pthread -I../../../src/include -I../../../src
/sdk/wxscintilla/include -DCB_AUTOCONF  -DCB_PRECOMP -DPIC -DTIXML_USE_STL=YES   -O2 -g -pipe -Wall -Werror=format-security -Wp,-
D_FORTIFY_SOURCE=2 -Wp,-D_GLIBCXX_ASSERTIONS -fexceptions -fstack-protector-strong -grecord-gcc-switches -specs=/usr/lib/rpm/redh
at/redhat-hardened-cc1 -specs=/usr/lib/rpm/redhat/redhat-annobin-cc1 -m64 -mtune=generic -fasynchronous-unwind-tables -fstack-cla
sh-protection -fcf-protection -Winvalid-pch -fPIC -fexceptions -c -o codecompletion.lo codecompletion.cpp
libtool: compile:  g++ -DHAVE_CONFIG_H -I. -I../../../src/include -I/usr/lib64/wx/include/gtk3-unicode-3.0 -I/usr/include/wx-3.0
-D_FILE_OFFSET_BITS=64 -DWXUSINGDLL -D__WXGTK__ -pthread -I../../../src/include -I../../../src/sdk/wxscintilla/include -DCB_AUTOC
ONF -DCB_PRECOMP -DPIC -DTIXML_USE_STL=YES -O2 -g -pipe -Wall -Werror=format-security -Wp,-D_FORTIFY_SOURCE=2 -Wp,-D_GLIBCXX_ASSE
RTIONS -fexceptions -fstack-protector-strong -grecord-gcc-switches -specs=/usr/lib/rpm/redhat/redhat-hardened-cc1 -specs=/usr/lib
/rpm/redhat/redhat-annobin-cc1 -m64 -mtune=generic -fasynchronous-unwind-tables -fstack-clash-protection -fcf-protection -Winvali
d-pch -fPIC -fexceptions -c codecompletion.cpp  -fPIC -DPIC -o .libs/codecompletion.o
n file included from parser/parserthread.h:21,
                 from parser/parser.h:22,
                 from cctreectrl.h:13,
                 from classbrowser.h:15,
                 from classbrowser.cpp:43:
parser/parserthread.h: In member function 'virtual int ParserThread::Execute()':
parser/cclogger.h:161:18: warning: unused variable 'result' [-Wunused-variable]
  161 |             auto result = M.Lock();             \
      |                  ^~~~~~
parser/parserthread.h:190:9: note: in expansion of macro 'CC_LOCKER_TRACK_TT_MTX_LOCK'
  190 |         CC_LOCKER_TRACK_TT_MTX_LOCK(s_TokenTreeMutex)
      |         ^~~~~~~~~~~~~~~~~~~~~~~~~~~
parser/cclogger.h:167:18: warning: unused variable 'result' [-Wunused-variable]
  167 |             auto result = M.Unlock();           \
      |                  ^~~~~~
parser/parserthread.h:194:9: note: in expansion of macro 'CC_LOCKER_TRACK_TT_MTX_UNLOCK'
  194 |         CC_LOCKER_TRACK_TT_MTX_UNLOCK(s_TokenTreeMutex)
      |         ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~
classbrowser.cpp: In member function 'void ClassBrowser::OnTreeItemDoubleClick(wxTreeEvent&)':
parser/cclogger.h:161:18: warning: unused variable 'result' [-Wunused-variable]
  161 |             auto result = M.Lock();             \
      |                  ^~~~~~
classbrowser.cpp:558:13: note: in expansion of macro 'CC_LOCKER_TRACK_TT_MTX_LOCK'
  558 |             CC_LOCKER_TRACK_TT_MTX_LOCK(s_TokenTreeMutex)
      |             ^~~~~~~~~~~~~~~~~~~~~~~~~~~
parser/cclogger.h:167:18: warning: unused variable 'result' [-Wunused-variable]
  167 |             auto result = M.Unlock();           \
      |                  ^~~~~~
classbrowser.cpp:563:13: note: in expansion of macro 'CC_LOCKER_TRACK_TT_MTX_UNLOCK'
  563 |             CC_LOCKER_TRACK_TT_MTX_UNLOCK(s_TokenTreeMutex)
      |             ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~
classbrowser.cpp: In member function 'void ClassBrowser::OnSearch(wxCommandEvent&)':
parser/cclogger.h:161:18: warning: unused variable 'result' [-Wunused-variable]
  161 |             auto result = M.Lock();             \
      |                  ^~~~~~
...
The warnings about unused variables continue for a while. But nothing i can see results in the error.
I attached the build.log for the reference.

[/code]
Title: Re: Symbols browser issue of CC has been fixed for my Linux
Post by: AZ on April 12, 2020, 09:32:14 pm
build log attached
Title: Re: Symbols browser issue of CC has been fixed for my Linux
Post by: stahta01 on April 12, 2020, 09:35:01 pm
Why did you post a picture of Code Completion plugin status?
Did you even check the status of the Symbol Table plugin?

Tim S.
Title: Re: Symbols browser issue of CC has been fixed for my Linux
Post by: tigerbeard on April 12, 2020, 09:56:38 pm
Why did you post a picture of Code Completion plugin status?
Did you even check the status of the Symbol Table plugin?
I'm afraid that is not really helpful. In CB16.0 the Symbol Table Plugin is version 1.0, in my patched 17 version it is still 1.0. Thats not really a surprise, when the only difference is some changed functions. It has not been an official plugin update, so so surprise that the version number was not touched, is it?

When the disable function is greyed out I would say the code patch did not work. @AZ did you check if your code has actually contains the new lines from the patch file?

If you like you could post the steps you actually did (right from the start step by step). Maybe I can spot something I did differently.



Title: Re: Symbols browser issue of CC has been fixed for my Linux
Post by: stahta01 on April 12, 2020, 10:08:19 pm
tigerbeard: If the symbol table plugin is disabled it will not work!
Title: Re: Symbols browser issue of CC has been fixed for my Linux
Post by: oBFusCATed on April 12, 2020, 10:20:18 pm
@stahta01: Please stop causing confusion! The Symbol browser is part of the Code completion plugin! Settings -> Editor -> Code completion -> Symbols browser -> Disable symbols browser.
Title: Re: Symbols browser issue of CC has been fixed for my Linux
Post by: AZ on April 13, 2020, 04:53:51 am
Gents, hold on. i think i messed up somewhere ...
hmm. not sure.
this is from the mocked buildroot after patch was applied:
Code: [Select]
<mock-chroot> sh-5.0# ls -l  ../BUILD/codeblocks-17.12.svn/trunk/src/plugins/codecompletion/ccoptionsdlg.cpp
-rw-r--r-- 1 mockbuild mock 23731 Apr 11 19:11 ../BUILD/codeblocks-17.12.svn/trunk/src/plugins/codecompletion/ccoptionsdlg.cpp
this is from the source:
Code: [Select]
tar -tzvf codeblocks-20.03.svn.12045.tar.bz2 | grep ccoptionsdlg.cpp
-rw-rw-r-- az/az         24356 2019-11-24 13:58 ./codeblocks-17.12.svn/trunk/src/plugins/codecompletion/ccoptionsdlg.cpp


the spec looks like this :
Code: [Select]
# %%global svnrev             @[email protected]
%global svnrev             12045

%global VERSION 20.03

Name:       codeblocks
Version: %{VERSION}.svn.%{svnrev}
Release: 1%{?dist}
Summary: An open source, cross platform, free C++ IDE
License:    GPLv3+
URL:        http://www.codeblocks.org/
Source0: %{name}-%{VERSION}.tar.bz2
# Source0: %%{name}-17.12.svn.tar.bz2
Patch0: symbol_browser.patch

BuildRequires: libtool
BuildRequires: wxGTK3-devel
<skip>
%prep
%setup -q -n %{name}-17.12.svn/trunk
# %%setup -q -n %{name}[email protected]@
%patch0 -p0

./bootstrap

# convert EOLs
find . -type f -and -not -name "*.cpp" -and -not -name "*.h" -and -not -name "*.png" -and -not -name "*.bmp" -and -not -name "*.c
" -and -not -name "*.cxx" -and -not -name "*.ico" -exec dos2unix -q --keepdate {} \;

%build

%configure \
    --with-contrib-plugins=all \
    --with-boost-libdir=%{_libdir}

let me do the clean rebuild.

Yep, there was some old code somewhere. Now i can see the browser. Excellent.
Title: Re: Symbols browser issue of CC has been fixed for my Linux
Post by: tigerbeard on April 13, 2020, 01:07:24 pm
Yep, there was some old code somewhere. Now i can see the browser. Excellent.
Glad it worked.
Should you have feedback or additional findings on the patch please collect it in this thread.
Title: Re: Symbols browser issue of CC has been fixed for my Linux
Post by: AZ on April 13, 2020, 03:58:02 pm
Yep, there was some old code somewhere. Now i can see the browser. Excellent.
Glad it worked.
Should you have feedback or additional findings on the patch please collect it in this thread.

Gents,
 thank you for the help and getting the browser working.
Quote
Status

    A volunteer is neeed to run a profiler and to do the initial measurements in CodeBlocks.
    The total timing of the SymbolBrowser in the mean thread (and only in the main thread) is needed. All timings of the threads may be ignored. As I understaood the measurement should cover the times if SymbolBrowser is active and well as when it is not active (e.g. another management tab is open). Please post the results in this thead.

If somebody is willing to write up what exactly needs to be done, i'll try to help.

Full disclosure : i'm not a CPP programmer.
Title: Re: Symbols browser issue of CC has been fixed for my Linux
Post by: AZ on April 19, 2020, 12:44:17 am
After i recompiled for FC31 the window disappeared again. I see nothing in the logs. (attached).
It seems that it attempts to open the window, but then it fails. It doesn't matter, if i have a project open or not.

Is there a way to get more debug information from the app?
Title: Re: Symbols browser issue of CC has been fixed for my Linux
Post by: AZ on April 19, 2020, 12:48:52 am
build.log
Title: Re: Symbols browser issue of CC has been fixed for my Linux
Post by: AZ on April 19, 2020, 12:56:47 am
now , if i use a previously working version for FC30. I still do not get the window. But in console i observe:
Code: [Select]
(codeblocks:126954): Gtk-CRITICAL **: 18:52:31.070: gtk_tree_model_iter_nth_child: assertion 'n >= 0' failed
18:52:48: Debug: window wxScintilla(0x56207fc408a0, ) lost focus even though it didn't have it
18:52:48: Debug: window wxScintilla(0x56207fc408a0, ) lost focus even though it didn't have it
18:52:48: Debug: window wxScintilla(0x56207fc408a0, ) lost focus even though it didn't have it
18:52:48: Debug: window wxScintilla(0x56207fc408a0, ) lost focus even though it didn't have it
18:52:48: Debug: window wxScintilla(0x56207fc408a0, ) lost focus even though it didn't have it
18:52:48: Debug: window wxScintilla(0x56207fc408a0, ) lost focus even though it didn't have it
18:52:48: Debug: window wxScintilla(0x56207fc408a0, ) lost focus even though it didn't have it
18:52:48: Debug: window wxScintilla(0x56207fc408a0, ) lost focus even though it didn't have it
18:52:48: Debug: window wxScintilla(0x56207fc408a0, ) lost focus even though it didn't have it



-- terminating the app and i see the below
18:53:22: Debug: 3 threads were not terminated by the application.
Title: Re: Symbols browser issue of CC has been fixed for my Linux
Post by: oBFusCATed on April 19, 2020, 10:51:45 am
If the application is crashing you have to use a debugger to see where.
Title: Re: Symbols browser issue of CC has been fixed for my Linux
Post by: AZ on April 19, 2020, 10:58:44 pm
If the application is crashing you have to use a debugger to see where.

It is not terminating. I was terminating it ( alt-F4) . Bad wording.
Title: Re: Symbols browser issue of CC has been fixed for my Linux
Post by: AZ on May 14, 2020, 11:41:55 pm
the symbol browser "hid" in the "management" window. //don't ask  ::)

The browser has been working perfectly fine for my basic needs ( 5/20 files, up to 200 lines of code in each), for the past 2 months with CB been compiled weekly ( from nighties) 
Title: Re: Symbols browser issue of CC has been fixed for my Linux
Post by: ChristophMS on October 22, 2020, 01:32:55 pm
Hi folks,

I applied that patch from above to my CB::20.03 (on M$ Windows) and at first I got an segmentation fault in void ClassBrowserBuilderThread::SelectItem(CCTreeCtrl* tree, wxTreeItemId item ) where data->m_MirrorNode is accessed. The address of m_MirrorNode looked strange to me (sth. like 0xbnnn nnnn) which seemed to be a kind of random address. I found out that this class member is not initialized in the constructor which should now look like

CCTreeCtrlData::CCTreeCtrlData(SpecialFolder sf, Token* token, short int kindMask, int parentIdx) :
    m_Token(token),
    m_KindMask(kindMask),
    m_SpecialFolder(sf),
    m_TokenIndex(token ? token->m_Index : -1),
    m_TokenKind(token ? token->m_TokenKind : tkUndefined),
    m_TokenName(token ? token->m_Name : _T("")),
    m_ParentIndex(parentIdx),
    m_Ticket(token ? token->GetTicket() : 0),
    m_MirrorNode( nullptr )

{
}

Kind regards

Christoph MS
Title: Re: Symbols browser issue of CC has been fixed for my Linux
Post by: Miguel Gimenez on October 22, 2020, 02:56:54 pm
Thank you for testing. I have modified the patch to include your change.