Cannot reproduce - works as expected on Windows.
On Windows I can't reproduce too.
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.
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.
, 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.
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.