Developer forums (C::B DEVELOPMENT STRICTLY!) > Development

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

<< < (5/25) > >>

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){}

--- End code ---

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();
}

--- End code ---

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);
}
--- End code ---

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:

--- Quote from: stahta01 on September 28, 2015, 11:36:55 am ---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.

--- End quote ---
Thanks for the test.



--- Quote ---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
--- End quote ---
I did the same thing as you did.



--- Quote ---OS Windows 7 32 Bit Ultimate.
--- End quote ---
This is the only difference(I'm on winXP 32bit), maybe, my OS is broken?  :(


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

--- End quote ---
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

--- End code ---

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" />

--- End code ---

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:

--- Quote from: ollydbg on September 28, 2015, 03:47:15 pm ---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.  :)

--- End quote ---

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.

Navigation

[0] Message Index

[#] Next page

[*] Previous page

Go to full version