A problem when copying the default.conf file from one computer to another

[courage]

Because BerliOS can't submit files, I post it here.

This problem is that when I copy the default.conf file from one computer to another,
then Code::Blocks uses the greater part of CPU usage and can't finish starting.

The attached 7z file is the one I consider cause this problem.
I use svn 4091. Thank you!

[attachment deleted by admin]

[thomas]

The attached config file works without any problems in my standard, non-bloat everyday working copy (standard Windows build) of Code::Blocks.
Could you try disabling all but the core plugins and see if the problem persists, please?

I have the following plugins installed on my system:
autosave, code completion, compiler, debugger, file extension handler, scripted wizard, source code formatter, windows xp look-and-feel.

[courage]

Hi thomas:

I do a little tracing and find the unfinished loop could be caused in the environment variable plugin.
(Please see the attached pictures)
If I just keep the plugins what you also used, Code::Blocks can finish the starting.
Then I add envvars.dll, the problem happens again.

The default.conf file I copy form an old laptop(but it also was copied form desk-top computer before),
and it works correctly in the old laptop, but incorrectly in the desk-top computer.
I also install masm32 in two computers.

I use official windows nightly built, svn 4093 now.
Thanks for replying my question. 

[attachment deleted by admin]

[MortenMacFly]

Then I add envvars.dll, the problem happens again.

Please have a look here: http://forums.next.codeblocks.org/index.php/topic,5906.msg45166.html#msg45166 and see if that helps - I'll do some further investigation on that topic...
With regards, Morten.

Edit: The reason is not the envvars plugin - it works properly and the setup in the conf - file is correct. So we are back at the beginning...

[courage]

I think I am very close to the reason of the problem.

The two computers have different configurations in environment variable.
One has 'INCLUDE' and 'LIB' variables, but another doesn't.
And the one has 'INCLUDE' and 'LIB' variables may cause Code::Blocks into unfinished loop.
(In default.conf file,
I also set 'INCLUDE' and 'LIB' variables for masm in Code::Blocks' environment configuration.)

It's strange to me.  :?
I also set 'PATH' variable in Code::Blocks and Code::Blocks works well.
Does Code::Blocks use different way to handle 'PATH' beyond other variables?

[MortenMacFly]

And the one has 'INCLUDE' and 'LIB' variables may cause Code::Blocks into unfinished looping.

I can't reproduce: I tried many ways: having setup LIB only, having setup INCLUDE only, having setup both and having setup nothing. It just works as expected and in the case the variable already exists it is expanded as expected.

I also set 'PATH' variable in Code::Blocks and Code::Blocks works well.
Does Code::Blocks use different way to handle 'PATH' beyond other variables?

No it's the very same piece of code.

If you want to you could try to debug into this yourself. Do you have any global compiler variables and/or custom variables setup that could conflict (although they actually shouldn't)...?!

With regards, Morten.

[courage]

Hello Morten:

I found if Code::Blocks and windows both have the 'INCLUDE' variable that has '%INCLUDE%',
that will go into unfinished loop.

Well... Hmm... could it be considered as a bug? :oops:

[MortenMacFly]

I found if Code::Blocks and windows both have the 'INCLUDE' variable that has '%INCLUDE%',
that will go into unfinished loop.

So you mean your Windows variable is something like:

Code Select Expand


INCLUDE=C:\include;%INCLUDE%

??? That would be a good reason for a loop... ;-)

Will check and properly fix that (although I don't see a good reason for doing such things...?!)...

With regards, Morten.

[MortenMacFly]

Hmmm... looking at the code:

Code Select Expand


  // Value: First, expand stuff like:
  //        set PATH=%PATH%;C:\NewPath OR export PATH=$PATH:/new_path
  //        After, replace all macros the user might have used in addition
  wxString the_value = value;
  wxString value_set;
  bool     is_set    = wxGetEnv(the_key, &value_set);
  if (is_set)
  {
    wxString recursion;
    if (platform::windows) recursion = _T("%")+the_key+_("%");
    else                   recursion = _T("$")+the_key;

    if (the_value.Contains(recursion))
      the_value.Replace(recursion.c_str(), value_set.c_str());
  }
  Manager::Get()->GetMacrosManager()->ReplaceMacros(the_value);

I don't see a reason for such a loop except wxString's Replace method and/or MacrosManager... Thomas: (Because you are the macro expert:) Could this be an issue?!

With regards, Morten.

[MortenMacFly]

Code Select Expand


  Manager::Get()->GetMacrosManager()->ReplaceMacros(the_value);


That line is the culprit - phew... so it's probably not my fault. ;-)
Thomas: To reproduce setup an envvar in Windows (not C::B) like:

Code Select Expand


  RECURSION=C:\WhatEver;%RECURSION%

Then (re) start C::B and build a variable (e.g. an envvar) like: RECURSION=D:\WhoEver;%RECURSION% in C::B, apply it and restart C::B -> it freezes.
Now the funny part: If I apply the envvar (before restarting) the same steps are involved but it works properly. Is there anything different in MacrosManager on startup???

With regards, Morten.

[MortenMacFly]

Fixed in SVN r4097. Thanks for spotting this.
With regards, Morten.

[courage]

Thank you, Morten! Really Tanks!