User forums > Nightly builds
The 15 August 2011 build (7385) is out.
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:
--- Quote from: Zanzicas on August 23, 2011, 06:17:20 pm ---Went to <Settings><Editor...><Code Completion><Symbols Browser page> and checked "Disable Symbols Browser" <Ok>.
--- End quote ---
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.
--- Quote from: jens on August 23, 2011, 06:31:59 pm ---What are your settings for codecompletion (parser) and symbols browser ?
--- End quote ---
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:
--- Quote from: oBFusCATed on August 24, 2011, 10:22:47 am ---spectre: Is C::B usable, when run under the control of ThreadSanitizer?
--- End quote ---
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.
Navigation
[0] Message Index
[#] Next page
[*] Previous page
Go to full version