The 12 April 2013 build (8982) is out.

[Max]

I'm writing to submit a report of a bug found using the latest nightly build. I switched to the latest nightly build from the previous one (in which the bug was not present) using Win XP SP3 and GCC 4.7 from MinGW.

Setting the option

Explicitly add project's top level direcotory to compiler search dirs

the compiler switch added is

  -I-I<path>

instead of

  -I<path>

With the buggy switch the compiler is no longer adding the top level dir to the list of search dirs.

Because I have several header file in the top level dir I'm using that option to add the dir and find the header. As a workaround I am adding the dir in build option but I think going back to the right behaviour is welcome.

Max

[ambarj2009]

Congratulations, I loved the change.
Thanks for the new version.

[Alpha]

With the buggy switch the compiler is no longer adding the top level dir to the list of search dirs.

Fixed in trunk.

[Ghorgoth]

Hi,
is there any mac build for the nightly over there ? Since i can't use the latest release due to lots of crashes on mac, i would like to test this one.

Thanks!

[stefanos_]

An awkward behavior appeared with the latest revision. I just re-compiled an old wxMSW project and originally consumed no more than 86MB; now it needs 96MB for just starting C::B, and upon loading GUI project it immediately jumps up to 164MB. When I close my project, the memory remains the same without getting released.

I have also tried to debug my application and the debugger crashed the entire C::B.

UPDATE: Ctrl+arrow UP or DOWN does not work; it should supposed to move editor by one line up or down.

OS: Windows XP Pro SP3
C::B revision: svn-9096
Compiler: TDM's GCC latest available version
wxWidgets: wxMSW-2.8.12 + wxWidgets-2.9.4

[Alpha]

An awkward behavior appeared with the latest revision. I just re-compiled an old wxMSW project and originally consumed no more than 86MB; now it needs 96MB for just starting C::B, and upon loading GUI project it immediately jumps up to 164MB. When I close my project, the memory remains the same without getting released.

Are you saying this is the memory usage of Code::Blocks, or your own program?  If it is Code::Blocks, do you have documentation parsing enabled for CC?

UPDATE: Ctrl+arrow UP or DOWN does not work; it should supposed to move editor by one line up or down.

Does this work if you disable EditorTweaks?

[ollydbg]

An awkward behavior appeared with the latest revision. I just re-compiled an old wxMSW project and originally consumed no more than 86MB; now it needs 96MB for just starting C::B, and upon loading GUI project it immediately jumps up to 164MB. When I close my project, the memory remains the same without getting released.

Can you disable CodeCompletion plugin and try again? Thanks.

I have also tried to debug my application and the debugger crashed the entire C::B.

No idea about this issue, I need steps to reproduce this issue.

[oBFusCATed]

C::B revision: svn-9096

Another option is to try rev 9077 and 9078 and report which one works and which doesn't.
I'm talking about Ctrl+arrow issue.
But it works for me in 9094 on linux.

[stefanos_]

I think I have figure out what seems to be the problem. The parser would run endlessly somewhere, either at the current project directory or the entire GUI framework / compiler directory and would stuck in a place that is beyond my wildest imagination (LOL), and after reparsed my project memory returned to normal levels.

Also, when I use the auto completion with Ctrl-Space I get duplicate on top of duplicate for each class member, but class constructors / destructors are appeared only once.

Does this help a bit? Cheers to both of you for your valuable feedback.

@oBFusCATed: I will try this tomorrow on work's laptop, and when I get home tonight, I will try it on Debian too and let you know for sure.

[stefanos_]

This is to let you know that the Ctrl-ArrowUp / Ctrl-ArrowDown issue is resolved, at least under Linux Debian testing (jessie). Tomorrow I will test the same on Windows too.

[stefanos_]

On Windows XP, the issue remains the same even with the latest revision. Is there anything I should check that could possibly disabled this functionality by mistake?

[ollydbg]

I think I have figure out what seems to be the problem. The parser would run endlessly somewhere, either at the current project directory or the entire GUI framework / compiler directory and would stuck in a place that is beyond my wildest imagination (LOL), and after reparsed my project memory returned to normal levels.

Also, when I use the auto completion with Ctrl-Space I get duplicate on top of duplicate for each class member, but class constructors / destructors are appeared only once.

Can you tell me how to reproduce this issue(sample code? steps?), it looks like its a CC bug.

[MortenMacFly]

On Windows XP, the issue remains the same even with the latest revision.

What issue?

[stefanos_]

I think I have figure out what seems to be the problem. The parser would run endlessly somewhere, either at the current project directory or the entire GUI framework / compiler directory and would stuck in a place that is beyond my wildest imagination (LOL), and after reparsed my project memory returned to normal levels.

Also, when I use the auto completion with Ctrl-Space I get duplicate on top of duplicate for each class member, but class constructors / destructors are appeared only once.

Can you tell me how to reproduce this issue(sample code? steps?), it looks like its a CC bug.

The steps are too simple: just create a UI project with wxSmith, edit it according your needs, and have your task manager open to monitor the memory changes. At random moments you will see your parser complaining that still parses unless you interrupt it with Ctrl-Space.

[stefanos_]

On Windows XP, the issue remains the same even with the latest revision.

What issue?

The issue with Ctrl-ArrowUp / Ctrl-ArrowDown to scroll text. On Debian works fine; on XP it does not. Cheers