The 11 May 2021 build (12446) is out.

[nenin]

I got first RPT (see attachment) on close C::B after usage with new project.

Steps to reproduce?
Does it happen every time?
Does it happen with older night builds?

It was like this:
I  installed this build in clear folder.
I opened some old project to check is everything OK- it looks OK  (compiler recognition, default settings, etc.)
I started new console project, work with it for some time (few hours) including debug sessions, than I did "Save all" and on exit and it generated RPT.
I did not tried to reproduce it in 100%, simple tests like create project- debug- "save all"- close C::B - does not lead to crash on exit.
With last few years nighties I did not face such problem.
I`m on Win7 64b, gcc- winlibs 10.2 32b, gdb: GNU gdb (ssbssa-1) 10.1.90.20201024-git

[oBFusCATed]

@nenin: We need something that is more reproducible in order to fix the problem. It seems something somewhere is corrupting memory, but where - hard to tell. Please lets us know if this persists or the frequency of the crashes increases.

[oBFusCATed]

Yesterday I have tried out your new nightly 12446 from May the 11th. The latest version I used was a self build SVN 12240 from December 2020

1. Can you try to find the night build which changed behaviour?
2. What is the exact command line you use to start CB?

[nenin]

@nenin: We need something that is more reproducible in order to fix the problem. It seems something somewhere is corrupting memory, but where - hard to tell. Please lets us know if this persists or the frequency of the crashes increases.

Of course.

[gd_on]

@eckard_klotz

If you compare both build-reports you will see that the binaries called for the compilation are different

    The new nightly calls : mingw32-g++.exe
    The old nightly calls : x86_64-w64-mingw32-g++.exe

Why did you change that ? May be an installer (or Auto-detect) has done this for you, but you can revert this.
In a standard tdm-64 installation, mingw32-g++.exe does not exist, but x86_64-w64-mingw32-g++.exe (or simply g++.exe which is the same executable) exists. If you want to use the same compiler version as previously, the same configuration path should work. Take care of the order in your path variable !
So, may be you have an other mingw32 in your path, a 32 bits one, so this can give such problem.
This is just a supposition ...

[eckard_klotz]

Hello oBFusCATed and gd_on

Thanks for your fast response

@gd_on
You wonder why I have changed the called binary.

• But the answer is I haven't changed it.
• Code::Blocks has done the change by ignoring the content of the conf-file used with the personality chosen wile calling it.
• If you would take a look to the zip-file, I have provided with my first post, you will see 2 images with the version-number 12240 in the name, which show you, what I have configured and how the global variables should be used to define the  compiler toolchain executables.
• The images version-number 12446 in the name show you how my configuration was changed or better ignored and reset by the current nightly. Fortunately this changes was not stored in the conf-file. Thus I could still use my configuration with my old self-build Code::Blocks 1240 from last December.

What you describe about the windows-path variable may be valid as long as you don't configure explicitly what tool-chain and what binaries should be used.

• But If I set up global variables in Code::Blocks for everything and configure the use of this global variables in the compiler toolchain executable settings, I actually expect that Code::Blocks is using my configuration and is not trying to search the tools by itself.
• And if this has worked in the past I actually expect that that this will also work in the newer versions.

I hope my language sounds not to rude, since you mentioned in your reply:

This is just a supposition ...

Please accept my apologize if my words are to rough.

Even I think in this case it is more related to the mechanism how Code::Blocks is handling the global variables, every tip is welcome for me. When I searched in the first step for the error-message sorry, unimplemented: 64-bit mode not compiled in in the forum, I already found diverse topics mentioning the same issue were this hint would be leading in the right direction.
Thus thank you for your supposition.



@oBFusCATed

You ask for the exact command used to call Code::Blocks

• I call Code::Blocks with a shortcut that uses the following destination.
•     C:\Tool\Development\CodeBlocks\Nightlies\2021_05_11\bin\codeblocks.exe --personality="ask"
• 2021_05_11 depends on the nightly I use. If I change it, I change the corresponding working-path of the shortcut also.
• --personality="ask" provides me a list of different conf-files for different build-suites. (I attached a screen shot)

You asked me to test which nightly is still working as desired and which not:

The only working nightly published after my own build Code::Block that is still completely working with the conf-file content is the following one:

• svn build rev 12286 (2021-01-02 14:06:31) gcc 8.1.0 Windows/unicode - 64 bit

All other nightlies I've tested are not recognizing the global variables associated with the gcc and reset the compiler toolchain executable settings.

• svn build rev 12312 (2021-04-03 05:14:39) gcc 8.1.0 Windows/unicode - 64 bit
• svn build rev 12315 (2021-04-30 18:28:46) gcc 8.1.0 Windows/unicode - 64 bit
• svn build rev 12446 (2021-05-09 12:52:18) gcc 8.1.0 Windows/unicode - 64 bit

In the List "Resolved Fixed" of the nightly "25 April 2021 build (12312)" https://forums.codeblocks.org/index.php/topic,24464.0.html I found the following comment

• compiler: Add proper version comparison to compiler's XML parser (ticket #1041, thanks Miguel Gimenez)

Could it be that this way the compiler toolchain executable settings are reset to default values if they contain global variables and not file-names and/or path strings.
But why are the global variables associated with the built-suite not be shown any more?

By the way my Code::Blocks project-file as well as the conf-file I have provided in the zip-file with my post before are now shown as text-files, since forum told me that files with the original attachment could not be posted.

• I have exchanged the dot before the actually file attachment by an underscore.
• In addition I added the new file-attachment .txt.
• KanjiNoKenkyuu.cbp became KanjiNoKenkyuu_cbp.txt.
• MinGW_9_2_0_64bit_TDM.conf became MinGW_9_2_0_64bit_TDM_conf.txt.

Please undo this change.

Thanks for your support.

Please stay well and healthy,
                                          Eckard Klotz.

[Miguel Gimenez]

compiler: Add proper version comparison to compiler's XML parser (ticket #1041, thanks Miguel Gimenez)

That commit allows enabling options (p.e. -std=c++2a or -std=c++20) depending on compiler version, it does not affect compiler selection or variables.

[oBFusCATed]

@eckard_klotz:
Strange...
1. 12286 is working
2. 12312 is broken
3. we don't have night builds in between
4. I don't see anything which might be related.

Would it be possible to do a bisect with own builds and tell us which revision broke it?
There aren't that many revision so finding the broken one shouldn't take that much time.

[eckard_klotz]

Hello oBFusCATed

Would it be possible to do a bisect with own builds and tell us which revision broke it?
There aren't that many revision so finding the broken one shouldn't take that much time.

You are asking me to test more than 20 revisions right?

Usually a build takes half a day on my computer parallel to my work I need at least 20 days or more.
If we would do this discussion in Japanese, I would answer now "chotto....."

However in the meanwhile I found another issue not related to the build-issue but to the conf-file.

• I configured in the menu Tools (not Tools+) an item to open the project-folder (attached image "CB_12240_Tool_OpenProjectFolder.png")
• In the current nightly opened with the conf-file created with the older Code::Blocks version this Tool menu item is not visible any more as well as its configuration i (attached image "CB_12446_Tool_OpenProjectFolder.png")

I think the real problem is located in the evaluation of the conf-file were all this configurations are stored. In my today's first post I have also added the conf-file (ok as txt file but this means for you that you have to change the file-attachment back as already discussed).

We are currently talking about:

the global variable sets

   <gcv>
      <sets>
         <default>
            <wx_64>
               <BASE>
                  <str>
                     <![CDATA[C:\Lib\wxWidgets\wxWidgets-2.8.12]]>
                  </str>
               </BASE>
               <INCLUDE>
                  <str>
                     <![CDATA[C:\Lib\wxWidgets\wxWidgets-2.8.12\include]]>
                  </str>
               </INCLUDE>
               <LIB>
                  <str>
                     <![CDATA[C:\Lib\wxWidgets\wxWidgets-2.8.12\lib]]>
                  </str>
               </LIB>
            </wx_64>
            <wx>
               <BASE>
                  <str>
                     <![CDATA[C:\Lib\wxWidgets\wxWidgets-2.8.12]]>
                  </str>
               </BASE>
               <INCLUDE>
                  <str>
                     <![CDATA[C:\Lib\wxWidgets\wxWidgets-2.8.12\include]]>
                  </str>
               </INCLUDE>
               <LIB>
                  <str>
                     <![CDATA[C:\Lib\wxWidgets\wxWidgets-2.8.12\lib]]>
                  </str>
               </LIB>
            </wx>
            <wx_32bit>
               <BASE>
                  <str>
                     <![CDATA[C:\Lib\wxWidgets\wxWidgets-2.8.12]]>
                  </str>
               </BASE>
               <INCLUDE>
                  <str>
                     <![CDATA[C:\Lib\wxWidgets\wxWidgets-2.8.12\include]]>
                  </str>
               </INCLUDE>
               <LIB>
                  <str>
                     <![CDATA[C:\Lib\wxWidgets\wxWidgets-2.8.12\lib]]>
                  </str>
               </LIB>
            </wx_32bit>
            <wx30>
               <BASE>
                  <str>
                     <![CDATA[C:\Lib\wxWidgets\3_0_4\MinGW_5_1_0_32bit]]>
                  </str>
               </BASE>
               <INCLUDE>
                  <str>
                     <![CDATA[C:\Lib\wxWidgets\3_0_4\MinGW_5_1_0_32bit\include]]>
                  </str>
               </INCLUDE>
               <LIB>
                  <str>
                     <![CDATA[C:\Lib\wxWidgets\3_0_4\MinGW_5_1_0_32bit\lib]]>
                  </str>
               </LIB>
            </wx30>
            <unittest>
               <BASE>
                  <str>
                     <![CDATA[C:\Tool\Development\UnitTest]]>
                  </str>
               </BASE>
               <INCLUDE>
                  <str>
                     <![CDATA[C:\Tool\Development\UnitTest\UnitTest++\src]]>
                  </str>
               </INCLUDE>
               <LIB>
                  <str>
                     <![CDATA[C:\Tool\Development\UnitTest\lib]]>
                  </str>
               </LIB>
            </unittest>
            <wx31_64>
               <BASE>
                  <str>
                     <![CDATA[C:\Lib\wxWidgets\3_1_3]]>
                  </str>
               </BASE>
               <INCLUDE>
                  <str>
                     <![CDATA[C:\Lib\wxWidgets\3_1_3\include]]>
                  </str>
               </INCLUDE>
               <LIB>
                  <str>
                     <![CDATA[C:\Lib\wxWidgets\3_1_3\lib]]>
                  </str>
               </LIB>
            </wx31_64>
            <cb>
               <BASE>
                  <str>
                     <![CDATA[C:\Project\_SVN\CodeBlocks\trunk\src]]>
                  </str>
               </BASE>
            </cb>
            <cb_release_type>
               <BASE>
                  <str>
                     <![CDATA[-o2]]>
                  </str>
               </BASE>
            </cb_release_type>
            <boost>
               <BASE>
                  <str>
                     <![CDATA[C:\Lib\boost\boost_1_57_0]]>
                  </str>
               </BASE>
               <INCLUDE>
                  <str>
                     <![CDATA[C:\Lib\boost\boost_1_57_0]]>
                  </str>
               </INCLUDE>
            </boost>
            <gcc_libs>
               <BASE>
                  <str>
                     <![CDATA[C:\Tool\Development\MinGW\MinGW_8_1_0\bin_64_SJLJ\mingw64]]>
                  </str>
               </BASE>
               <INCLUDE>
                  <str>
                     <![CDATA[$(#gcc.BASE)\include\]]>
                  </str>
               </INCLUDE>
               <LIB>
                  <str>
                     <![CDATA[$(#gcc.BASE)\lib\]]>
                  </str>
               </LIB>
               <LIBSTDCPP_A>
                  <str>
                     <![CDATA[gcc\x86_64-w64-mingw32\9.2.0\libstdc++.a]]>
                  </str>
               </LIBSTDCPP_A>
               <LIBWINPTHREAD_A>
                  <str>
                     <![CDATA[..\x86_64-w64-mingw32\lib\libwinpthread.a]]>
                  </str>
               </LIBWINPTHREAD_A>
               <LIBGCC_S_A>
                  <str>
                     <![CDATA[..\x86_64-w64-mingw32\lib\libgcc_s.a]]>
                  </str>
               </LIBGCC_S_A>
            </gcc_libs>
            <gcc>
               <BASE>
                  <str>
                     <![CDATA[C:\Tool\Development\MinGW\MinGW_9_2_0_TDM\bin_64_SEH]]>
                  </str>
               </BASE>
               <INCLUDE>
                  <str>
                     <![CDATA[$(#gcc.BASE)\include\]]>
                  </str>
               </INCLUDE>
               <LIB>
                  <str>
                     <![CDATA[$(#gcc.BASE)\lib\]]>
                  </str>
               </LIB>
               <COMPILER_C>
                  <str>
                     <![CDATA[x86_64-w64-mingw32-gcc.exe]]>
                  </str>
               </COMPILER_C>
               <COMPILER_CPP>
                  <str>
                     <![CDATA[x86_64-w64-mingw32-g++.exe]]>
                  </str>
               </COMPILER_CPP>
               <COMPILER_RES>
                  <str>
                     <![CDATA[windres.exe]]>
                  </str>
               </COMPILER_RES>
               <LINKER_DYN>
                  <str>
                     <![CDATA[x86_64-w64-mingw32-g++.exe]]>
                  </str>
               </LINKER_DYN>
               <LINKER_STAT>
                  <str>
                     <![CDATA[x86_64-w64-mingw32-gcc-ar.exe]]>
                  </str>
               </LINKER_STAT>
               <MAKE>
                  <str>
                     <![CDATA[mingw32-make.exe]]>
                  </str>
               </MAKE>
               <LIBSTDCPP_A>
                  <str>
                     <![CDATA[gcc\x86_64-w64-mingw32\9.2.0\libstdc++.a]]>
                  </str>
               </LIBSTDCPP_A>
            </gcc>
         </default>
      </sets>
      <ACTIVE>
         <str>
            <![CDATA[default]]>
         </str>
      </ACTIVE>
   </gcv>

the compiler toolchain executables

         <gcc>
            <NAME>
               <str>
                  <![CDATA[GNU GCC Compiler]]>
               </str>
            </NAME>
            <MASTER_PATH>
               <str>
                  <![CDATA[$(#gcc.BASE)]]>
               </str>
            </MASTER_PATH>
            <EXTRA_PATHS>
               <str>
                  <![CDATA[C:\Tool\Development\MinGW\AddOn\bison\bison_2_1\bin;C:\Tool\Development\MinGW\AddOn\flex\flex_2_5_4a_1\bin;C:\Tool\Kompress\Zip\3_0\bin;]]>
               </str>
            </EXTRA_PATHS>
            <C_COMPILER>
               <str>
                  <![CDATA[$(#gcc.COMPILER_C)]]>
               </str>
            </C_COMPILER>
            <CPP_COMPILER>
               <str>
                  <![CDATA[$(#gcc.COMPILER_CPP)]]>
               </str>
            </CPP_COMPILER>
            <LINKER>
               <str>
                  <![CDATA[$(#gcc.LINKER_DYN)]]>
               </str>
            </LINKER>
            <LIB_LINKER>
               <str>
                  <![CDATA[$(#gcc.LINKER_STAT)]]>
               </str>
            </LIB_LINKER>
            <RES_COMPILER>
               <str>
                  <![CDATA[$(#gcc.COMPILER_RES)]]>
               </str>
            </RES_COMPILER>
            <MAKE>
               <str>
                  <![CDATA[$(#gcc.MAKE)]]>
               </str>
            </MAKE>
         </gcc>

the tools-configuration

   <tools>
      <tool00>
         <NAME>
            <str>
               <![CDATA[open project folder]]>
            </str>
         </NAME>
         <COMMAND>
            <str>
               <![CDATA[explorer.exe ]]>
            </str>
         </COMMAND>
         <PARAMS>
            <str>
               <![CDATA[${PROJECT_DIR}]]>
            </str>
         </PARAMS>
         <WORKINGDIR>
            <str>
               <![CDATA[]]>
            </str>
         </WORKINGDIR>
         <LAUNCHOPTION int="2" />
      </tool00>
   </tools>

 
Actually on developer should know this parts of the conf-file and where they are used. I do not.

• I provided you images which show the good case as well as the bad cases. Thus my report should be reproduce able.
• Once you see the same effect wile using my conf-file you just have to figure out where the corresponding xml nodes in the conf-file are processed.

Even I would be able to tell you exactly with which revision the issue was introduced you still have to check this. So why don't you do it just with the current revision?

Please stay well and healthy,
                                          Eckard Klotz.

[oBFusCATed]

You are asking me to test more than 20 revisions right?

More like lg2(20), if you use binary search.

Usually a build takes half a day on my computer parallel to my work I need at least 20 days or more.

Hard to believe. Even my old core2quad could build the core stuff in 2-3 minutes.
You don't have to build the whole workspace. You can only build the core (codeblocks*.cbp).

It is up to you to do it or wait if someone wants to replicate your setup and reproduce this for you.

[eckard_klotz]

Hello oBFusCATed.

I will create an official bug-report regarding this. As you already mentioned it is a core feature of Code::Blocks and all users which are working with global variables are potentially affected. What more augments are necessary to  take a look?

Please stay well and healthy,
                                          Eckard Klotz.

[BlueHazzard]

Hard to believe. Even my old core2quad could build the core stuff in 2-3 minutes.

windows is !significantly! slower then linux when it comes to building codeblocks...
I build codeblocks faster in my linux vm with less cores, then on windows on the same machine (no vm) with all cores of my cpu
My feeling is that gcc is slower on windows and also that our pipe handling is somehow slower, but i never profiled it...

[BlueHazzard]

@Obfuscated regarding the problem of @eckard_klotz
i think he hits the bug where we kill our config file...

I think the real problem is located in the evaluation of the conf-file were all this configurations are stored. In my today's first post I have also added the conf-file (ok as txt file but this means for you that you have to change the file-attachment back as already discussed).

Yes.. i think our config file parsing/saving is broken, prone to create erroneous files... I have this problem from time to time, that the compiler flags are not valid any more. I am not able to reproduce this and that is a big problem...

[oBFusCATed]

windows is !significantly! slower then linux when it comes to building codeblocks...

This is true, but it is not 200 times slower. GCC is damn slow on windows (and buggy).
I don't know why non of the windows devs haven't stepped up to to provide llvm builds.
The dev experience on windows with C::B is something like 2-10x worse compared to the experience on linux.

@Obfuscated regarding the problem of @eckard_klotz
i think he hits the bug where we kill our config file...

I'm not sure what config-kill-problem you're talking about, but as far as I understand it the problem is 100% reproducible - it happens every time. @eckard_klotz could correct me if this is not the case of course.

[eckard_klotz]

Hello oBFusCATed and BlueHazzard

I'm not sure what config-kill-problem you're talking about, but as far as I understand it the problem is 100% reproducible - it happens every time. @eckard_klotz could correct me if this is not the case of course.

Yes you are right it happens always.

• Rename the file MinGW_9_2_0_64bit_TDM_conf.txt back into MinGW_9_2_0_64bit_TDM.conf (provided in my zip-file you will find in my first post yesterday https://forums.codeblocks.org/index.php/topic,24487.msg167084.html#msg167084).
• Place the conf-file in your windows user folderC:\Users\[USER_NAME]\AppData\Roaming\CodeBlocks.
• Start Code::Blocks with "codeblocks.exe --personality="ask"".
• Choose the personality MinGW_9_2_0_64bit_TDM.
• Once Code::Blocks is open check the settings of the global variables, the compiler tool chain executables and the menu "Tool".

In my zip-file, you will find in my first post yesterday https://forums.codeblocks.org/index.php/topic,24487.msg167084.html#msg167084 and in my 3rd post yesterday https://forums.codeblocks.org/index.php/topic,24487.msg167094.html#msg167094, I provided screen shots of the associated Code::Blocks dialogs.

The numbers in the names will allow you to differ between the good case and the bad case:

• Good Case: 12240
• Bad Case :  12446

The good case could be shown until the nightly "svn build rev 12286 (2021-01-02 14:06:31) gcc 8.1.0 Windows/unicode - 64 bit".
The bad case could be shown from  the nightly "svn build rev 12312 (2021-04-03 05:14:39) gcc 8.1.0 Windows/unicode - 64 bit" on.

I know that I repeat, what I have already written yesterday. But I hope that this conclusion is helping you to re-produce the issue.

You all payed so much effort in the development and in updating Code::Blocks. I'm especially appreciated that the symbol-browser is working again.
It would be a pity, if this issue would prevent the users of global variables to change to a newer nightly.

Please stay well and healthy,
                                          Eckard Klotz.