The 15 August 2011 build (7385) is out.

[Loaden]

Hi, All, If you found some hangs with CB, please disable the symbols browser.
If the hang still there, please let's me know.
Sorry for this troubles.

[fubo]

Hi,
  I use .cbp generated from cmake-2.8.5 (win32),
and opened by C::B r7385, then the files does not show out all and just some like
-Workspace
- myPrj
   - ..
     - ..
     - app
       + src
   + CMake Files

By using r7288 is OK.
What does I miss on new release?
Thanks

     

Same here. Really ugly!

[spectre]

Hi, All, If you found some hangs with CB, please disable the symbols browser.

Loaden, do you mean closing symbol browser "window" or something else should be done?
When I closed that window while some project was open and tried to open some other .c file, C::B still hung, similar to what Zanzicas and I described earlier.

BTW, menu item "View"->"Symbols Browser" seems to have no visible effect.

Checked on C::B built from svn rev. 7406 on Ubuntu 10.04 x86-64.

[Folco]

Micool -> I don't know, I absolutely don't know the code of C::B...

[Zanzicas]

Hi, All, If you found some hangs with CB, please disable the symbols browser.
If the hang still there, please let's me know.
Sorry for this troubles.

Went to <Settings><Editor...><Code Completion><Symbols Browser page> and checked "Disable Symbols Browser" <Ok>.

Still early in testing but have not had a lockup yet.  Before lockup was always immediate.

[Jenna]

I do not (yet) get lockups with the debugger-branch from my repo (7386), nor with actual trunk.

Both 64-bit linux and build against wx 2.8.10, dbg with gcc 4.3 and trunk with 4.6.
It doesn't matter whether I use one parser per workspace or per project.

What are your settings for codecompletion (parser) and symbols browser ?

[Folco]

If you talk that about my post (CC crash, described previous page), I use default settings, I don't change anything.

[spectre]

Went to <Settings><Editor...><Code Completion><Symbols Browser page> and checked "Disable Symbols Browser" <Ok>.

Ah, I see now.
Well, this time, I disabled symbols browser this way, opened a project (a trivial C++ console application) then again tried to open a .c file that does not belong to this project. C::B hung, like it did before. I tried this both with and without ThreadSanitizer being active, the results are the same.

The log of C::B (cb04.log) and a part of ThreadSanitizer report (tsan-cb04-hybrid.log) are in the attached archive. The race detector still reports some possible data races that could be related to code completion component. I cannot say whether they are real races or whether they are related to this very problem.

What are your settings for codecompletion (parser) and symbols browser ?

Jens, I use the default settings. Except for disabling symbols browser, I have not changed the settings since I have build C::B (rev. 7406, built on Ubuntu 10.04 x86-64) the first time. default.conf from my system is also in the attached archive, just in case (it is a copy of ~/.codeblocks/default.conf, there were no other .conf files there).

[oBFusCATed]

spectre: Is C::B usable, when run under the control of ThreadSanitizer?

[spectre]

spectre: Is C::B usable, when run under the control of ThreadSanitizer?

It is quite slow but still it is usable.

It took several minutes only to load C::B on my machine under the control of ThreadSanitizer. I suppose it is common with heavyweight Valgrind-based tools (the slowdown factor of MemCheck, for example, can be as high as 20x-50x if I am not mistaken).

I think adjusting ThreadSanitizer settings (enabling sampling, for example) along with providing the machine with more RAM (my box has only 1G) could mitigate this performance issue.

[Loaden]

Annoying hang should have been fixed in rev7408.

[oBFusCATed]

Confirmed...
Now you should fix the ctrl+shift+. deadlock and CC will be usable, again

[Loaden]

Confirmed...
Now you should fix the ctrl+shift+. deadlock and CC will be usable, again

Fixed in rev7413.

[ollydbg]

Confirmed...
Now you should fix the ctrl+shift+. deadlock and CC will be usable, again

Fixed in rev7413.

Great work Loaden, I noticed that you have add the some debug logger like:

Code Select Expand


+        TRACK_THREAD_LOCKER(s_TokensTreeCritical);
+        wxCriticalSectionLocker locker(s_TokensTreeCritical);
+        THREAD_LOCKER_SUCCESS(s_TokensTreeCritical);

Quite Good!!

[teto]

I like the doubleclick on a projet that makes it the main project of the workspace.

I've discovered a bug: you can add twice the same file to a project. It will try to link it twice and cause a bug during the linking process.