Author Topic: The 18 December 2010 build (6900) is out.  (Read 33540 times)

Offline killerbot

  • Administrator
  • Lives here!
  • *****
  • Posts: 5490
The 18 December 2010 build (6900) is out.
« 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.

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:



    Offline Jenna

    • Administrator
    • Lives here!
    • *****
    • Posts: 7255
    Re: The 18 December 2010 build (6900) is out.
    « Reply #1 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.
    Reviosion is 6898 (6899 and 6900) are changes to debugger-branch).

    Offline oBFusCATed

    • Developer
    • Lives here!
    • *****
    • Posts: 13413
      • Travis build status
    Re: The 18 December 2010 build (6900) is out.
    « Reply #2 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.
    (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!]

    Offline dk

    • Multiple posting newcomer
    • *
    • Posts: 55
      • Code::Blocks for ALT Linux Sisyphus
    Re: The 18 December 2010 build (6900) is out.
    « Reply #3 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.


    Denis Kirienko
    C::B maintainer for ALT Linux distribution (http://www.sisyphus.ru/srpm/codeblocks)

    Offline MortenMacFly

    • Administrator
    • Lives here!
    • *****
    • Posts: 9694
    Re: The 18 December 2010 build (6900) is out.
    « Reply #4 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?!
    Compiler logging: Settings->Compiler & Debugger->tab "Other"->Compiler logging="Full command line"
    C::B Manual: https://www.codeblocks.org/docs/main_codeblocks_en.html
    C::B FAQ: https://wiki.codeblocks.org/index.php?title=FAQ

    Offline Zadirion

    • Multiple posting newcomer
    • *
    • Posts: 10
    Re: The 18 December 2010 build (6900) is out.
    « Reply #5 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
    « Last Edit: December 19, 2010, 06:29:29 pm by Zadirion »

    Offline dk

    • Multiple posting newcomer
    • *
    • Posts: 55
      • Code::Blocks for ALT Linux Sisyphus
    Re: The 18 December 2010 build (6900) is out.
    « Reply #6 on: December 19, 2010, 08:18:57 pm »
    Cannot reproduce - works as expected on Windows.

    On Windows I can't reproduce too.
    Denis Kirienko
    C::B maintainer for ALT Linux distribution (http://www.sisyphus.ru/srpm/codeblocks)

    Offline Jenna

    • Administrator
    • Lives here!
    • *****
    • Posts: 7255
    Re: The 18 December 2010 build (6900) is out.
    « Reply #7 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.
    « Last Edit: December 19, 2010, 08:51:52 pm by jens »

    Offline Jenna

    • Administrator
    • Lives here!
    • *****
    • Posts: 7255
    Re: The 18 December 2010 build (6900) is out.
    « Reply #8 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.
    « Last Edit: December 20, 2010, 01:20:35 am by jens »

    Offline ollydbg

    • Developer
    • Lives here!
    • *****
    • Posts: 5910
    • OpenCV and Robotics
      • Chinese OpenCV forum moderator
    Re: The 18 December 2010 build (6900) is out.
    « Reply #9 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
    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.

    Offline Loaden

    • Lives here!
    • ****
    • Posts: 1014
    Re: The 18 December 2010 build (6900) is out.
    « Reply #10 on: December 20, 2010, 03:15:52 am »
    I think I found the reason for the crash.
    Thanks!
    This patch should fix this issue.

    Offline Jenna

    • Administrator
    • Lives here!
    • *****
    • Posts: 7255
    Re: The 18 December 2010 build (6900) is out.
    « Reply #11 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.

    Offline mfmco2

    • Single posting newcomer
    • *
    • Posts: 5
    Re: The 18 December 2010 build (6900) is out.
    « Reply #12 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.
    windows xp sp3     chinese
    Code::Blocks svn6900 + wmingwm10_gcc441 + wxWidgets 2.8.11.03(Compile the package【wxpack】)

    Offline mfmco2

    • Single posting newcomer
    • *
    • Posts: 5
    Re: The 18 December 2010 build (6900) is out.
    « Reply #13 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.
    « Last Edit: December 22, 2010, 07:00:10 am by MortenMacFly »
    windows xp sp3     chinese
    Code::Blocks svn6900 + wmingwm10_gcc441 + wxWidgets 2.8.11.03(Compile the package【wxpack】)

    Offline ollydbg

    • Developer
    • Lives here!
    • *****
    • Posts: 5910
    • OpenCV and Robotics
      • Chinese OpenCV forum moderator
    Re: The 18 December 2010 build (6900) is out.
    « Reply #14 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.
    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.