Code::Blocks
November 24, 2014, 07:29:00 am *
Welcome, Guest. Please login or register.
Did you miss your activation email?

Login with username, password and session length
News: The new Release 13.12 is out! You can download binaries for windows, mac and many major linux distros from  http://www.codeblocks.org/downloads/26 .
 
   Home   Help Search Login Register  :: WebsiteWiki  
Pages: [1] 2  All   Go Down
  Send this topic  |  Print  
Author Topic: The 18 December 2010 build (6900) is out.  (Read 14991 times)
killerbot
Administrator
Lives here!
*****
Offline Offline

Posts: 4825


« 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:


    Logged
    jens
    Administrator
    Lives here!
    *****
    Offline Offline

    Posts: 6652



    WWW
    « 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).
    Logged

    Regards

    Jens  Debian - nightlies (and release) : http://apt.jenslody.de/ Fedora [18 - 20]- and CentOS/RedHat [5, 6 & 7] - nightlies : http://rpm.jenslody.de/
    oBFusCATed
    Developer
    Lives here!
    *****
    Offline Offline

    Posts: 7733


    « 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.
    Logged

    <debugger plugin maintainer>
    (most of the time I ignore long posts)
    dk
    Advanced newcomer
    *
    Offline Offline

    Posts: 55


    WWW
    « 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.


    Logged

    Denis Kirienko
    C::B maintainer for ALT Linux distribution (http://www.sisyphus.ru/srpm/codeblocks)
    MortenMacFly
    Administrator
    Lives here!
    *****
    Offline Offline

    Posts: 8687



    « 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?!
    Logged

    Compiler logging: Settings->Compiler & Debugger->tab "Other"->Compiler logging="Full command line"
    C::B Manual: http://www.codeblocks.org/docs/main_codeblocks_en.html
    C::B FAQ: http://wiki.codeblocks.org/index.php?title=FAQ
    Zadirion
    Advanced newcomer
    *
    Offline Offline

    Posts: 10


    « 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 » Logged
    dk
    Advanced newcomer
    *
    Offline Offline

    Posts: 55


    WWW
    « Reply #6 on: December 19, 2010, 08:18:57 pm »

    Cannot reproduce - works as expected on Windows.

    On Windows I can't reproduce too.
    Logged

    Denis Kirienko
    C::B maintainer for ALT Linux distribution (http://www.sisyphus.ru/srpm/codeblocks)
    jens
    Administrator
    Lives here!
    *****
    Offline Offline

    Posts: 6652



    WWW
    « 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 » Logged

    Regards

    Jens  Debian - nightlies (and release) : http://apt.jenslody.de/ Fedora [18 - 20]- and CentOS/RedHat [5, 6 & 7] - nightlies : http://rpm.jenslody.de/
    jens
    Administrator
    Lives here!
    *****
    Offline Offline

    Posts: 6652



    WWW
    « 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 » Logged

    Regards

    Jens  Debian - nightlies (and release) : http://apt.jenslody.de/ Fedora [18 - 20]- and CentOS/RedHat [5, 6 & 7] - nightlies : http://rpm.jenslody.de/
    ollydbg
    Developer
    Lives here!
    *****
    Offline Offline

    Posts: 4153


    Interests on OpenCV and Robotics


    WWW
    « 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.  Cheesy Cheesy
    Logged

    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
    Lives here!
    ****
    Offline Offline

    Posts: 1014



    « 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.
    Logged
    jens
    Administrator
    Lives here!
    *****
    Offline Offline

    Posts: 6652



    WWW
    « 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.
    Logged

    Regards

    Jens  Debian - nightlies (and release) : http://apt.jenslody.de/ Fedora [18 - 20]- and CentOS/RedHat [5, 6 & 7] - nightlies : http://rpm.jenslody.de/
    mfmco2
    Newcomer
    *
    Offline Offline

    Posts: 5


    « 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.
    Logged

    windows xp sp3     chinese
    Code::Blocks svn6900 + wmingwm10_gcc441 + wxWidgets 2.8.11.03(Compile the package【wxpack】)
    mfmco2
    Newcomer
    *
    Offline Offline

    Posts: 5


    « 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 » Logged

    windows xp sp3     chinese
    Code::Blocks svn6900 + wmingwm10_gcc441 + wxWidgets 2.8.11.03(Compile the package【wxpack】)
    ollydbg
    Developer
    Lives here!
    *****
    Offline Offline

    Posts: 4153


    Interests on OpenCV and Robotics


    WWW
    « 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.
    Logged

    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.
    Pages: [1] 2  All   Go Up
      Send this topic  |  Print  
     
    Jump to:  

    Powered by MySQL Powered by PHP Powered by SMF 1.1.19 | SMF © 2013, Simple Machines Valid XHTML 1.0! Valid CSS!