Build C::B against wx3.02 with gcc 5.2 under Windows

[stahta01]

Turns out that 32 bit MSys2 has only Mingw GCC 4.9.2; so, I downloaded the same mingw-builds as you and am trying to build wxWidgets.
It used to take two+ hours to build; but, something made my computer faster in the last few months.

Edit: My 32 bit MSys2 installation has problem; I think it likely that MinGW GCC 5.2 does exist for it.

Tim S.

[ollydbg]

Here is the steps to reproduce the C::B crash issue with nightly build version from:The 26 September 2015 build (10503) is out.

1,  start c::b with PATH be empty. (only the home page window is opened, no project is opened)
2, open the plugin manager panel, suppose all plugins are enabled
3, disable the open files list plugin
4, enable the open files list plugin
5, close c::B  -> crash

This means the crash may not related to wx3, but wx2.8.12 also has the issue. The only difference is that under wx3, the crash happens in step 3 or step 4, but for wx2.8.12, the crash happens when closing c::b. I'm on WinXP 32 bit.

[ollydbg]

Another crash issue I found is that it looks like my build c::B (against wx3) can't save the configure file correctly.

If I start C::B with those options: (the name "clean-configure" means I let C::B to create a "clean-configure.conf" file)

Code

-p clean-configure

Then when close C::B I get a crash, and actually no clean-configure.conf is saved.

Edit:
When running under GDB, I see a similar crash call stack inside the function FindItemByHWND()

Code

Program received signal SIGSEGV, Segmentation fault.
In wxWindow::FindItemByHWND(HWND__*, bool) const () (F:\cb_sf_git\trunk\src\devel30\wxmsw30u_gcc_cb.dll)

[debug]> bt 30
[debug]#0  0x6474c5e5 in wxWindow::FindItemByHWND(HWND__*, bool) const () from F:\cb_sf_git\trunk\src\devel30\wxmsw30u_gcc_cb.dll
[debug]#1  0x6474dc28 in wxWindow::HandleCtlColor(HBRUSH__**, HDC__*, HWND__*) () from F:\cb_sf_git\trunk\src\devel30\wxmsw30u_gcc_cb.dll
[debug]#2  0x6475911b in wxWindow::MSWHandleMessage(long*, unsigned int, unsigned int, long) () from F:\cb_sf_git\trunk\src\devel30\wxmsw30u_gcc_cb.dll
[debug]#3  0x647497a0 in wxWindow::MSWWindowProc(unsigned int, unsigned int, long) () from F:\cb_sf_git\trunk\src\devel30\wxmsw30u_gcc_cb.dll
[debug]#4  0x64751223 in wxWndProc(HWND__*, unsigned int, unsigned int, long)@16 () from F:\cb_sf_git\trunk\src\devel30\wxmsw30u_gcc_cb.dll
[debug]#5  0x7e418734 in USER32!GetDC () from C:\WINDOWS\system32\user32.dll
[debug]#6  0x0004087e in ?? ()
[debug]#7  0x00000133 in ?? ()
[debug]#8  0x8601148d in ?? ()
[debug]#9  0x00070a62 in ?? ()
[debug]#10 0x647511b0 in wxWindow::SubclassWin(HWND__*) () from F:\cb_sf_git\trunk\src\devel30\wxmsw30u_gcc_cb.dll
[debug]#11 0x7e418816 in USER32!GetDC () from C:\WINDOWS\system32\user32.dll
[debug]#12 0x647511b0 in wxWindow::SubclassWin(HWND__*) () from F:\cb_sf_git\trunk\src\devel30\wxmsw30u_gcc_cb.dll
[debug]#13 0x7e42927b in USER32!GetParent () from C:\WINDOWS\system32\user32.dll
[debug]#14 0x00000000 in ?? ()
[debug]>>>>>>cb_gdb:

[stahta01]

Just noticed that the SVN I am using is 10474 and it did NOT have your problem.
Edit: This is using Git and it sometimes does NOT report the correct SVN under windows for me.

Tim S.

[ollydbg]

Just noticed that the SVN I am using is 10474 and it did NOT have your problem.
Edit: This is using Git and it sometimes does NOT report the correct SVN under windows for me.

Tim S.

OK, but I'll wait to see the result from your result of 32 bit mingw gcc 5.2. 

I'm consider whether it is cause by a broken GCC or it is broken by our C::B's source code....

Oh, I see a design flaw in the open files list plugin:

Code

void OpenFilesListPlugin::OnRelease(bool appShutDown)
{
    if (appShutDown)
        return;
    // remove registered event sinks
    Manager::Get()->RemoveAllEventSinksFor(this);

    // remove tree from docking system
    CodeBlocksDockEvent evt(cbEVT_REMOVE_DOCK_WINDOW);
    evt.pWindow = m_pTree;
    Manager::Get()->ProcessEvent(evt);

    // finally destroy the tree
    m_pTree->Destroy();
    m_pTree = nullptr;
}

Why do we need the two line:

Code

    if (appShutDown)
        return;

This means if we close the app, we don't need to destroy the resource allocated by this plugin?
Sounds like this will cause crashes in either wx2.8 or wx3 supported C::B.
I simply comment these two lines, and the good news is that I don't see the crash now for a simple test, I will do more tests to see whether there are other crashes.  EDIT: it still crashes. 

[ollydbg]

Well, I get confused about the document in cbplugin.h

Code

        /** Any descendent plugin should override this virtual method and
          * perform any necessary de-initialization. This method is called by
          * Code::Blocks (PluginManager actually) when the plugin has been
          * loaded, attached and should de-attach from Code::Blocks.\n
          * Think of this method as the actual destructor...
          * @param appShutDown If true, the application is shutting down. In this
          *         case *don't* use Manager::Get()->Get...() functions or the
          *         behaviour is undefined...
          */
        virtual void OnRelease(cb_optional bool appShutDown){}

I see many plugins are still using the Manager::Get()->Get...() in there OnRelease() function.
Such as:

Code

void CompilerGCC::OnRelease(bool appShutDown)
{
    // disable script functions
    ScriptBindings::gBuildLogId = -1;

    SaveOptions();
    Manager::Get()->GetConfigManager(_T("compiler"))->Write(_T("/default_compiler"), CompilerFactory::GetDefaultCompilerID());
    if (Manager::Get()->GetLogManager())
    {
        // for batch builds, the log is deleted by the manager
        if (!Manager::IsBatchBuild())
        {
            CodeBlocksLogEvent evt(cbEVT_REMOVE_LOG_WINDOW, m_pLog);
            Manager::Get()->ProcessEvent(evt);
        }
        m_pLog = 0;

        CodeBlocksLogEvent evt(cbEVT_REMOVE_LOG_WINDOW, m_pListLog);
        m_pListLog->DestroyControls();
        Manager::Get()->ProcessEvent(evt);
        m_pListLog = 0;
    }

    // let wx handle this on shutdown ( if we return here Valgrind will be sad :'( )
    if (!appShutDown)
        DoClearTargetMenu();

    m_timerIdleWakeUp.Stop();

    FreeProcesses();

    CompilerFactory::UnregisterCompilers();
}

or

Code

void DefaultMimeHandler::OnRelease(cb_unused bool appShutDown)
{
    CodeBlocksDockEvent evt(cbEVT_REMOVE_DOCK_WINDOW);
    evt.pWindow = m_Html;
    Manager::Get()->ProcessEvent(evt);
    m_Html->Destroy();
    m_Html = 0;

    // save configuration
    ConfigManager* conf = Manager::Get()->GetConfigManager(_T("mime_types"));
    wxArrayString list = conf->EnumerateKeys(_T("/"));
    for (unsigned int i = 0; i < list.GetCount(); ++i)
    {
        conf->UnSet(list[i]);
    }
    for (unsigned int i = 0; i < m_MimeTypes.GetCount(); ++i)
    {
        cbMimeType* mt = m_MimeTypes[i];
        wxString txt;
        txt << (mt->useEditor ? _T("true") : _T("false")) << _T(";");
        txt << (mt->useAssoc ? _T("true") : _T("false")) << _T(";");
        txt << (mt->programIsModal ? _T("true") : _T("false")) << _T(";");
        txt << mt->wildcard << _T(";");
        txt << mt->program << _T(' ');
        wxString key;
        key.Printf(_T("MimeType%u"), i);
        conf->Write(key, txt);
    }
    WX_CLEAR_ARRAY(m_MimeTypes);
}

Is the document wrong?

[stahta01]

Still did NOT see the problem; using SVN 10507 the prior one was likely 10506 reported wrong by Git.
I am using wx3.0.2 with no patches and the compiler is i686-5.2.0-release-posix-dwarf-rt_v4-rev0
This last time I used an SVN repo with all old stuff deleted.

Edit: I still had to copy 3 DLLs to get CB to run; if you did NOT then you did something very different from me.
libgcc_s_dw2-1.dll
libstdc++-6.dll
libwinpthread-1.dll


OS Windows 7 32 Bit Ultimate.

wxWidgets built with my new normal options of
CPPFLAGS="-DHAVE_TR1_TYPE_TRAITS"
CXXFLAGS="-Wno-unused-local-typedefs -fno-keep-inline-dllexport"

Tim S.

[ollydbg]

Still did NOT see the problem; using SVN 10507 the last one was likely 10506 reported wrong by Git.
I am using wx3.0.2 with no patches and the compiler is i686-5.2.0-release-posix-dwarf-rt_v4-rev0
This last time I used an SVN repo with all old stuff deleted.

Thanks for the test.

Edit: I still had to copy 3 DLLs to get CB to run; if you did NOT then you did something very different from me.
libgcc_s_dw2-1.dll
libstdc++-6.dll
libwinpthread-1.dll

I did the same thing as you did.

OS Windows 7 32 Bit Ultimate.

This is the only difference(I'm on winXP 32bit), maybe, my OS is broken? 

wxWidgets built with my new normal options of
CPPFLAGS="-DHAVE_TR1_TYPE_TRAITS"
CXXFLAGS="-Wno-unused-local-typedefs -fno-keep-inline-dllexport"

I use different workaround to handle this issue, but I don't think this cause the crash issue.

EDIT: I still have the crash when enable or disable several plugins, and close the c::b.

[ollydbg]

I think I may meet a GCC issue which cause the crash I reported in this thread.
Now, I have just finishing building the wx3 library in debug mode with the command line:

Code

mingw32-make -f makefile.gcc USE_XRC=1 SHARED=1 MONOLITHIC=1 BUILD=debug UNICODE=1 USE_OPENGL=1 VENDOR=cb CXXFLAGS="-Wno-unused-local-typedefs -Wno-deprecated-declarations -fno-keep-inline-dllexport" >log-debug.txt 2>&1

Then I build C::B against this debug version of wx3 library.
By changing the codeblocks_30.cbp like below:

Code

 src/CodeBlocks_wx30.cbp | 3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

diff --git a/src/CodeBlocks_wx30.cbp b/src/CodeBlocks_wx30.cbp
index 2b6a679..43c4e9b 100644
--- a/src/CodeBlocks_wx30.cbp
+++ b/src/CodeBlocks_wx30.cbp
@@ -700,7 +700,7 @@
 			</Target>
 			<Environment>
 				<Variable name="WX_CFG" value="" />
-				<Variable name="WX_SUFFIX" value="u" />
+				<Variable name="WX_SUFFIX" value="ud" />
 				<Variable name="WX_VERSION" value="30" />
 			</Environment>
 		</Build>
@@ -725,6 +725,7 @@
 			<Add option="-DCB_PRECOMP" />
 			<Add option="-DWX_PRECOMP" />
 			<Add option="-DwxUSE_UNICODE" />
+			<Add option="-D__WXDEBUG__" />
 			<Add directory="$(#WX30.include)" />
 			<Add directory="$(#WX30.lib)/gcc_dll$(WX_CFG)/msw$(WX_SUFFIX)" />
 			<Add directory="sdk/wxscintilla/include" />

After that, when testing the built C::B, I don't have any crash when disable or enable plugins. I even strip all the debug information(both the C::B related binaries and the wx3 library dll), it also works fine. So, I believe the crash bug comes from the mingw-build gcc 5.2.

Another issue I encountered is that after running the "update30.bat", I can't start codeblocks.exe from the output30 folder. I check the codeblocks.exe in output30 folder by dependency walker tool, it said the "dbghelp.dll" file is broken. How would that happen? (I think I use a wrong strip.exe?, because I put a strip.exe in a common folder, the strip.exe is quite old, the build time of the strip.exe was 2011-03-20, so maybe, I need to use the strip.exe come from the newer gcc suite), to solve the issue, I just copy the "dbghelp.dll" from the devel30 folder to output30 folder, and now, codeblocks.exe works fine. 


EDIT:
When using the BUILD=debug option to build wxWidgets 3.0.2, it actually use the "-O0" option for the G++ compiler, while BUILD=release uses the "-O2" option instead, thus I believe the "-O2" cause the crash issue.

[stahta01]

I think I may meet a GCC issue which cause the crash I reported in this thread.
Now, I have just finishing building the wx3 library in debug mode with the command line:

After that, when testing the built C::B, I don't have any crash when disable or enable plugins. I even strip all the debug information(both the C::B related binaries and the wx3 library dll), it also works fine. So, I believe the crash bug comes from the mingw-build gcc 5.2.

Another issue I encountered is that after running the "update30.bat", I can't start codeblocks.exe from the output30 folder. I check the codeblocks.exe in output30 folder by dependency walker tool, it said the "dbghelp.dll" file is broken. How would that happen? (I think I use a wrong strip.exe?, because I put a strip.exe in a common folder, the strip.exe is quite old, the build time of the strip.exe was 2011-03-20, so maybe, I need to use the strip.exe come from the newer gcc suite), to solve the issue, I just copy the "dbghelp.dll" from the devel30 folder to output30 folder, and now, codeblocks.exe works fine. 

I do NOT strip the DLLs put into output30 because no Compilers are in my path.

Do you still want the Zipped Binary of my CB build?

I am uploading it right now. I am guessing 30 minutes to finish uploading.

Tim S.

[ollydbg]

I think I may meet a GCC issue which cause the crash I reported in this thread.
Now, I have just finishing building the wx3 library in debug mode with the command line:

After that, when testing the built C::B, I don't have any crash when disable or enable plugins. I even strip all the debug information(both the C::B related binaries and the wx3 library dll), it also works fine. So, I believe the crash bug comes from the mingw-build gcc 5.2.

Another issue I encountered is that after running the "update30.bat", I can't start codeblocks.exe from the output30 folder. I check the codeblocks.exe in output30 folder by dependency walker tool, it said the "dbghelp.dll" file is broken. How would that happen? (I think I use a wrong strip.exe?, because I put a strip.exe in a common folder, the strip.exe is quite old, the build time of the strip.exe was 2011-03-20, so maybe, I need to use the strip.exe come from the newer gcc suite), to solve the issue, I just copy the "dbghelp.dll" from the devel30 folder to output30 folder, and now, codeblocks.exe works fine. 

I do NOT strip the DLLs put into output30 because no Compilers are in my path.

I also have no Compilers in my PATH, but I have put an old "strip.exe" in my PATH.

Do you still want the Zipped Binary of my CB build?
I am uploading it right now. I am guessing 30 minutes to finish uploading.
Tim S.

Yes, I need that, I want to see whether your built binary crashes in my system. Thanks.

[stahta01]

Yes, I need that, I want to see whether your built binary crashes in my system. Thanks.

PMed link to you.

Please confirm you received it; and it unzips good; I hope to delete that old location today.

Tim S.

[scarphin]

EDIT:
When using the BUILD=debug option to build wxWidgets 3.0.2, it actually use the "-O0" option for the G++ compiler, while BUILD=release uses the "-O2" option instead, thus I believe the "-O2" cause the crash issue.

I use '-o3' for my x32 and x64 builds all the time and I don't have such a crash issue. My version for mingw-builds is 4.9.2 though. I used your method to overcome the pch issue to be able to compile 64-bit cb. Maybe you should try '-o3'.

[ollydbg]

Yes, I need that, I want to see whether your built binary crashes in my system. Thanks.

PMed link to you.

Please confirm you received it; and it unzips good; I hope to delete that old location today.

Tim S.

Hi, Tim, thanks.
I just tested your built version, and by enable and disable several plugins, I still see the crash. 
Here is the codeblocks.RPT:

Code

codeblocks.exe caused an Access Violation at location 69E8C5E5 in module wxmsw30u_gcc_mingw_builds.dll Reading from location 00000010.

Registers:
eax=6abc9220 ebx=00000000 ecx=00000000 edx=00000000 esi=00000000 edi=00040be8
eip=69e8c5e5 esp=0022d684 ebp=0a365f18 iopl=0         nv up ei pl zr na po nc
cs=001b  ss=0023  ds=0023  es=0023  fs=003b  gs=0000             efl=00010246

AddrPC   Params
69E8C5E5 00040BE8 00000001 00000016  wxmsw30u_gcc_mingw_builds.dll!wxWindow::FindItemByHWND(HWND__*, bool) const
69E8DC28 0022D830 00000133 4E01187C  wxmsw30u_gcc_mingw_builds.dll!wxWindow::HandleCtlColor(HBRUSH__**, HDC__*, HWND__*)
69E897A0 77F1E10B 0301112F 00000133  wxmsw30u_gcc_mingw_builds.dll!wxWindow::MSWWindowProc(unsigned int, unsigned int, long)

codeblocks.exe	13.12.0.0
ntdll.dll   	5.1.2600.6055
kernel32.dll	5.1.2600.6532
COMCTL32.DLL	5.82.2900.6028
ADVAPI32.dll	5.1.2600.5755
RPCRT4.dll  	5.1.2600.6477
Secur32.dll 	5.1.2600.5834
GDI32.dll   	5.1.2600.6460
USER32.dll  	5.1.2600.5512
libgcc_s_dw2-1.dll
msvcrt.dll  	7.0.2600.5512
libwinpthread-1.dll	1.0.0.0
SHELL32.dll 	6.0.2900.6242
SHLWAPI.dll 	6.0.2900.5912
SHFOLDER.DLL	6.0.2900.5512
libstdc++-6.dll
wxmsw30u_gcc_mingw_builds.dll	3.0.2.0
...
...

Which is much similar like the crash report I see in my self built C::B.
Thanks.

[stahta01]

New warning that looks like a real problem to me.

MSys2 32 bit MinGW GCC 5.2 compiler.

Tim S.

Code

src\plugins\contrib\wxSmith\wxwidgets\defitems\wxsfontpickerctrl.cpp|70|warning: logical not is only applied to the left hand side of comparison [-Wlogical-not-parentheses]|

Line 70 to 72 below

Code

            if(!sFnt.Len() > 0){
                sFntName = wxT("wxNullFont");
            }