The 18 December 2010 build (6900) is out.

[killerbot]

Get quick announcements through the RSS feed http://www.codeblocks.org/nightly/CodeBlock_RSS.xml

Before you use a nightly make sure you understand how it works.

A link to the unicode windows wxWidget dll for Code::Blocks : http://prdownload.berlios.de/codeblocks/wxmsw28u_gcc_cb_wx2810_gcc441.7z

For those who might need this one (when no MingW installed on your system) : the mingw10m.dll : http://prdownload.berlios.de/codeblocks/mingwm10_gcc441.7z

The 18 December 2010 build is out.
  - Windows :
   http://prdownload.berlios.de/codeblocks/CB_20101218_rev6900_win32.7z
  - Linux :
   none

Resolved Fixed:

• Fixed: [Bug #17715] Scripted Wizard for wxSmith Author fails on some chars
• build wxscintilla as static library, see http://forums.codeblocks.org/index.php/topic,13538.0.html for more information
• apply patch to fixed get stripped arguments error, thank ollydbg!
• fixed cc search bug, see http://forums.codeblocks.org/index.php/topic,13746.0.html for more information
• fixed bug reported here: http://forums.codeblocks.org/index.php/topic,13778.0.html
• Fixed: A bug where Project wizard overwrites existing files without notice if project name already exists.
• Also added svn properties, fixed inconsistent line endings.
• personalize unix-socket for ipc-connection on linux by adding the username, to avoid possible problems on multiuser-systems
• Fixed: [Bug #17583] wxFILE_SEP_PATH does not work with BeforeLast
• don't create unneeded directories, if flat objects are used; fix an issue described here: http://forums.codeblocks.org/index.php/topic,13818.msg93003.html#msg93003
• a little improved for dtor code-completion
• pumped wxScintilla component to 2.23 (including interface optimisations) -> untested on 64 bit OS so far!
• added A68k lexer provided by Folco
• rewritten parser switcher, enhance the performance and accuracy
• fix for the new copy and paste bug on wxGTK, described here: http://forums.codeblocks.org/index.php/topic,13833.msg93079.html#msg93079
• Build fixes: for wx-2.9.
• wxscintilla: make A68K lexer actually available through WX interface (thanks danselmi)
• Added: wxScitilla as a dependency of sdk target.
• add the ability to show tooltips on cbAuiNotebook tabs; show full filename and Project in tooltip for editor tabs; no tooltips on other tabs (at the moment)
• add more comments for CC, thank ollydbg!
• fix crash on linux in nativeparser.cpp, if default compiler is msvc* (cross-build project), see here for details: http://forums.codeblocks.org/index.php/topic,13766.msg93390.html#msg93390

Regressions/Confirmed/Annoying/Common bugs:

[Jenna]

Debian packages (binaries and sources) for 32-bit and 64-bit systems can be found in my repo.
Reviosion is 6898 (6899 and 6900) are changes to debugger-branch).

[oBFusCATed]

There is something strange in this release: all my non c/cpp files are syntax highlighted as Squirrel files.
I've tried with Lua files (*.lua), OpenGL GLSL files (*.glsl) and another non-programming file type.

Could this problem be caused by the new Scintilla?
I've checked my file masks and they are OK.

[dk]

I found a bug in Code Completion.

1. Run Code::Blocks nightly.
2. Create new file: File -> New -> Empty file.
3. Save it: File -> Save file as -> "test.cpp"
4. In the editor type:

Code

#include <>

When you press a closing angle bracket ">", Code::blocks begin to use all available memory, and will crashed at the end.

Bug in not reproducible when CodeComplition is Disabled.

I am using own build of Code::Blocks for ALT Linux, SVN 6900 and SVN 6846.

[MortenMacFly]

I am using own build of Code::Blocks for ALT Linux, SVN 6900 and SVN 6846.

Cannot reproduce - works as expected on Windows. However, the list it shows includes a lot folders that might be questionable... i.e. folders above the compiler directories?!

[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 {

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)>

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]

Cannot reproduce - works as expected on Windows.

On Windows I can't reproduce too.

[Jenna]

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.

[Jenna]

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.

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]

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.

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.

Nice catch, the include patch auto completion feature is implemented by Loaden, hope he can fix it. 

[Loaden]

I think I found the reason for the crash.

Thanks!
This patch should fix this issue.

[Jenna]

I think I found the reason for the crash.

Thanks!
This patch should fix this issue.

Fix confirmed, but it has a side-effect: the file will not be parsed if it gets saved, because m_LastEditor and curEditor are the same. Parsing the file starts after switching to another file and back again.

The attached patch checks for the existance of the file earlier (before m_LastEditor is set to the current editor).
It fixes the issue also, but makes cc parse the file after it is saved with a valid filename.

[mfmco2]

Again:
 From 6454 to the 6900 version after version of any course to crash.
 Open the program file, in the main editing window, click the right mouse button, the program will crash.

[mfmco2]

Again:
 From 6454 to the 6900 version after version of any course to crash.
 Open the program file, in the main editing window, click the right mouse button, the program will crash.

codeblocks.RPT

[Edit:] Removed non-english content.

[ollydbg]

codeblocks.RPT

Please delete the file E:\CodeBlocks\share\codeblocks\plugins\EditorTweaks.dll

and start your C::B again. I think EditorTweaks plugin cause this crash.