Code::Blocks Forums

User forums => Nightly builds => Topic started by: killerbot on December 19, 2010, 09:54:30 am

Title: The 18 December 2010 build (6900) is out.
Post by: killerbot on December 19, 2010, 09:54:30 am
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 (http://forums.codeblocks.org/index.php/topic,3232.0.html).

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:


Regressions/Confirmed/Annoying/Common bugs:


Title: Re: The 18 December 2010 build (6900) is out.
Post by: Jenna on December 19, 2010, 11:31:38 am
Debian packages (binaries and sources) for 32-bit and 64-bit systems can be found in my repo (http://apt.jenslody.de/).
Reviosion is 6898 (6899 and 6900) are changes to debugger-branch).
Title: Re: The 18 December 2010 build (6900) is out.
Post by: oBFusCATed on December 19, 2010, 12:39:27 pm
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.
Title: Re: The 18 December 2010 build (6900) is out.
Post by: dk on December 19, 2010, 12:54:28 pm
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.


Title: Re: The 18 December 2010 build (6900) is out.
Post by: MortenMacFly on December 19, 2010, 01:54:33 pm
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?!
Title: Re: The 18 December 2010 build (6900) is out.
Post by: Zadirion on December 19, 2010, 02:01:56 pm
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
Title: Re: The 18 December 2010 build (6900) is out.
Post by: dk on December 19, 2010, 08:18:57 pm
Cannot reproduce - works as expected on Windows.

On Windows I can't reproduce too.
Title: Re: The 18 December 2010 build (6900) is out.
Post by: Jenna on December 19, 2010, 08:25:57 pm
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.
Title: Re: The 18 December 2010 build (6900) is out.
Post by: Jenna on December 20, 2010, 01:12:58 am
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.
Title: Re: The 18 December 2010 build (6900) is out.
Post by: ollydbg on December 20, 2010, 01:47:07 am
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.  :D :D
Title: Re: The 18 December 2010 build (6900) is out.
Post by: Loaden on December 20, 2010, 03:15:52 am
I think I found the reason for the crash.
Thanks!
This patch should fix this issue.
Title: Re: The 18 December 2010 build (6900) is out.
Post by: Jenna on December 20, 2010, 07:22:15 am
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.
Title: Re: The 18 December 2010 build (6900) is out.
Post by: mfmco2 on December 21, 2010, 09:00:54 am
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.
Title: Re: The 18 December 2010 build (6900) is out.
Post by: mfmco2 on December 22, 2010, 06:02:41 am
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.
Title: Re: The 18 December 2010 build (6900) is out.
Post by: ollydbg on December 22, 2010, 06:12:08 am
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.
Title: Re: The 18 December 2010 build (6900) is out.
Post by: mfmco2 on December 22, 2010, 07:44:36 am
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.

Thank you very much!
I use SVN6454 version "EditorTweaks.dll", replace the current version.
Solve the problem.

Title: Re: The 18 December 2010 build (6900) is out.
Post by: danselmi on December 22, 2010, 04:43:49 pm
This patch should stop the crashes of EditorTweaks. (mainly the FindMenu(_("Edit")); has to be replaced by FindMenu(_("&Edit")); but the other checks won't hurt)
Code
Index: EditorTweaks.cpp
===================================================================
--- EditorTweaks.cpp (revision 6904)
+++ EditorTweaks.cpp (working copy)
@@ -174,7 +174,7 @@
 
 void EditorTweaks::OnRelease(bool /*appShutDown*/)
 {
-    m_tweakmenu = 0;
+    m_tweakmenu = NULL;
 
 //    EditorHooks::UnregisterHook(m_EditorHookId, true);
     EditorManager* em = Manager::Get()->GetEditorManager();
@@ -208,7 +208,7 @@
 void EditorTweaks::BuildMenu(wxMenuBar* menuBar)
 {
     Manager::Get()->GetLogManager()->DebugLog(_("Editor Tweaks plugin: Building menu"));
-    int i=menuBar->FindMenu(_("Edit"));
+    int i=menuBar->FindMenu(_("&Edit"));
     if(i==wxNOT_FOUND)
     {
         Manager::Get()->GetLogManager()->DebugLog(_("Editor Tweaks plugin: edit menu not found"));
@@ -298,6 +298,8 @@
 
 void EditorTweaks::UpdateUI()
 {
+    if ( !m_tweakmenu )
+        return;
     cbEditor* ed = Manager::Get()->GetEditorManager()->GetBuiltinActiveEditor();
     if(!ed || !ed->GetControl())
     {
@@ -414,7 +416,7 @@
     //TIP: for consistency, add a separator as the first item...
 
     //make sure we have an editor
-    if(type!=mtEditorManager)
+    if(type!=mtEditorManager || !m_tweakmenu)
         return;
     cbEditor* ed = Manager::Get()->GetEditorManager()->GetBuiltinActiveEditor();
     if(!ed || !ed->GetControl())
Title: Re: The 18 December 2010 build (6900) is out.
Post by: killerbot on December 22, 2010, 05:45:03 pm
applied the suggestions
Title: Re: The 18 December 2010 build (6900) is out.
Post by: Folco on December 23, 2010, 04:10:40 pm
Thanks for this nightly, thanks for A68k lexer intergration. :)
Title: Re: The 18 December 2010 build (6900) is out.
Post by: mamtoug on December 23, 2010, 09:30:05 pm
somethings that I wish to add to codeblocks, I hope:
when I create a new project I really need to create a workspace file also (like MS visual studio), so it will be easy to add a second project.
 
Title: Re: The 18 December 2010 build (6900) is out.
Post by: Jenna on December 23, 2010, 09:40:13 pm
somethings that I wish to add to codeblocks, I hope:
when I create a new project I really need to create a workspace file also (like MS visual studio), so it will be easy to add a second project.

Just open one or more projects and right-click on "Workspace" in the management pane or use the "File"-menu and chose "Save workspace as".