Developer forums (C::B DEVELOPMENT STRICTLY!) > Development
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
--- End code ---
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:
--- End code ---
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:
--- Quote from: stahta01 on September 28, 2015, 04:44:43 am ---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.
--- End quote ---
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;
}
--- End code ---
Why do we need the two line:
--- Code: --- if (appShutDown)
return;
--- End code ---
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. :(
Navigation
[0] Message Index
[#] Next page
[*] Previous page
Go to full version