User forums > Nightly builds
The 18 December 2010 build (6900) is out.
Zadirion:
Hi and thanks for the nightly.
Found the following issues:
1) in a workspace with multiple projects, right click a project and select Activate from the context menu.
The project is now written in bold. However, so is the previous active project that now isn't active anymore. The font style is not updating itself.
2) The workspace got corrupted (read: codeblocks crashed when trying to launch) after I added:
--- Code: ---NAMESPACE_BEGIN(CryptoPP) -> namespace CryptoPP {
--- End code ---
to the Code Completion's replacement tokens. This is because the default.conf ends up looking like this:
--- Code: ---<NAMESPACE_BEGIN(CryptoPP)>
<![CDATA[namespace CryptoPP {]]>
</NAMESPACE_BEGIN(CryptoPP)>
--- End code ---
note '<NAMESPACE_BEGIN(CryptoPP)>' is not a valid xml element.
This is a rather unfortunate situation, as it prevents code completion from properly parsing the CryptoPP library.
Can anyone provide a workaround until this is fixed?
Many thanks!
Using Kubuntu 10.10 with CB r6898
dk:
--- Quote from: MortenMacFly on December 19, 2010, 01:54:33 pm ---Cannot reproduce - works as expected on Windows.
--- End quote ---
On Windows I can't reproduce too.
Jenna:
--- Quote from: dk on December 19, 2010, 08:18:57 pm ---
--- Quote from: MortenMacFly on December 19, 2010, 01:54:33 pm ---Cannot reproduce - works as expected on Windows.
--- End quote ---
On Windows I can't reproduce too.
--- End quote ---
Works here (more or less).
After the closing bracket, C::B uses 125 to 138 % of CPU (Core2Duo) and about 1.2 GB of memory, but after some time (about 5-10 sec) the CPU and memory usage is normal again and it shows me a bunch of preprocessor symbols in the symbols browser (even if there is no valid include).
EDIT:
It's still open and memory usage increases again.
System starts to become unresponsive, so it surely is in an endless-loop and eats up more an more memory.
Will see if I can debug it later.
Jenna:
--- Quote from: jens on December 19, 2010, 08:25:57 pm ---
--- Quote from: dk on December 19, 2010, 08:18:57 pm ---
--- Quote from: MortenMacFly on December 19, 2010, 01:54:33 pm ---Cannot reproduce - works as expected on Windows.
--- End quote ---
On Windows I can't reproduce too.
--- End quote ---
Works here (more or less).
After the closing bracket, C::B uses 125 to 138 % of CPU (Core2Duo) and about 1.2 GB of memory, but after some time (about 5-10 sec) the CPU and memory usage is normal again and it shows me a bunch of preprocessor symbols in the symbols browser (even if there is no valid include).
EDIT:
It's still open and memory usage increases again.
System starts to become unresponsive, so it surely is in an endless-loop and eats up more an more memory.
Will see if I can debug it later.
--- End quote ---
I think I found the reason for the crash.
It happens, because if a new empty file is created and is not saved, it has the name "Untitledx", where x is a digit.
In NativeParser::OnEditorActivatedTimer, the directory of the active editor os added to the search-directories, if the editor contains a header-file.
The name is (e.g.) Untitled0, this is treated as header by CCFileTypeOf, because the extension is empty, but Untitled0 is just a dummy-name, because the editor is not yet saved, so it has an empty path.
This empty path is added to the include-dirs.
The SystemHeadersThread creates a HeaderDirTraverser and parses all include-dirs.
If an include-dir does not end with a path-seperator, it is added in CodeCompletion::GetSystemIncludeDirs.
And the empty path of Untitled0 suddenly is the root-path (at least on linux), just a single path-seperator.
ANd now after typing #include <> the HeaderDirTraverser starts searching for a file starting with a ">" in the whole file-system, and this can be really, really large, so C::B uses more and more memory and can crash or (at least) make the system unresponsive, because of extensive swapping.
If we check for an empty path in OnEditorActivatedTimer (or later), we can avoid such issues.
I hope this helps the CC specíalists to fix this issue.
ollydbg:
--- Quote from: jens on December 20, 2010, 01:12:58 am ---
--- Quote from: jens on December 19, 2010, 08:25:57 pm ---
--- Quote from: dk on December 19, 2010, 08:18:57 pm ---
--- Quote from: MortenMacFly on December 19, 2010, 01:54:33 pm ---Cannot reproduce - works as expected on Windows.
--- End quote ---
On Windows I can't reproduce too.
--- End quote ---
Works here (more or less).
After the closing bracket, C::B uses 125 to 138 % of CPU (Core2Duo) and about 1.2 GB of memory, but after some time (about 5-10 sec) the CPU and memory usage is normal again and it shows me a bunch of preprocessor symbols in the symbols browser (even if there is no valid include).
EDIT:
It's still open and memory usage increases again.
System starts to become unresponsive, so it surely is in an endless-loop and eats up more an more memory.
Will see if I can debug it later.
--- End quote ---
I think I found the reason for the crash.
It happens, because if a new empty file is created and is not saved, it has the name "Untitledx", where x is a digit.
In NativeParser::OnEditorActivatedTimer, the directory of the active editor os added to the search-directories, if the editor contains a header-file.
The name is (e.g.) Untitled0, this is treated as header by CCFileTypeOf, because the extension is empty, but Untitled0 is just a dummy-name, because the editor is not yet saved, so it has an empty path.
This empty path is added to the include-dirs.
The SystemHeadersThread creates a HeaderDirTraverser and parses all include-dirs.
If an include-dir does not end with a path-seperator, it is added in CodeCompletion::GetSystemIncludeDirs.
And the empty path of Untitled0 suddenly is the root-path (at least on linux), just a single path-seperator.
ANd now after typing #include <> the HeaderDirTraverser starts searching for a file starting with a ">" in the whole file-system, and this can be really, really large, so C::B uses more and more memory and can crash or (at least) make the system unresponsive, because of extensive swapping.
If we check for an empty path in OnEditorActivatedTimer (or later), we can avoid such issues.
I hope this helps the CC specíalists to fix this issue.
--- End quote ---
Nice catch, the include patch auto completion feature is implemented by Loaden, hope he can fix it. :D :D
Navigation
[0] Message Index
[#] Next page
[*] Previous page
Go to full version