News:

As usual while waiting for the next release - don't forget to check the nightly builds in the forum.

Main Menu

The 18 December 2010 build (6900) is out.

Started by killerbot, December 19, 2010, 09:54:30 AM

Previous topic - Next topic

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:


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.
(most of the time I ignore long posts)
[strangers don't send me private messages, I'll ignore them; post a topic in the forum, but first read the rules!]

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:

#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

Quote from: dk on December 19, 2010, 12:54:28 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?!
Compiler logging: Settings->Compiler & Debugger->tab "Other"->Compiler logging="Full command line"
C::B Manual: [url="https://www.codeblocks.org/docs/main_codeblocks_en.html"]https://www.codeblocks.org/docs/main_codeblocks_en.html[/url]
C::B FAQ: [url="https://wiki.codeblocks.org/index.php?title=FAQ"]https://wiki.codeblocks.org/index.php?title=FAQ[/url]

Zadirion

#5
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:
 NAMESPACE_BEGIN(CryptoPP) -> namespace CryptoPP {
to the Code Completion's replacement tokens. This is because the default.conf ends up looking like this:

<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


Jenna

#7
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.

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

#8
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.

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

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.

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
If some piece of memory should be reused, turn them to variables (or const variables).
If some piece of operations should be reused, turn them to functions.
If they happened together, then turn them to classes.

Loaden

Quote from: jens on December 20, 2010, 01:12:58 AM
I think I found the reason for the crash.
Thanks!
This patch should fix this issue.

Jenna

Quote from: Loaden on December 20, 2010, 03:15:52 AM
Quote from: jens on December 20, 2010, 01:12:58 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.

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.
windows xp sp3     chinese
Code::Blocks svn6900 + wmingwm10_gcc441 + wxWidgets 2.8.11.03(Compile the package【wxpack】)

mfmco2

#13
Quote from: 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.

codeblocks.RPT

[Edit:] Removed non-english content.
windows xp sp3     chinese
Code::Blocks svn6900 + wmingwm10_gcc441 + wxWidgets 2.8.11.03(Compile the package【wxpack】)

ollydbg

Quote from: mfmco2 on December 22, 2010, 06:02:41 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.
If some piece of memory should be reused, turn them to variables (or const variables).
If some piece of operations should be reused, turn them to functions.
If they happened together, then turn them to classes.