TDM-Gcc is discontinued

[saidus]

Hello 
I saw that the TDM-GCC is not up to date (discontinued).
With wich version you plane deliver in the next release of CB.

Thank you.

[oBFusCATed]

mingw-w64 8.1.x or something similar. I don't remember which variant exactly.

[reckless]

I can still provide TDM versions of gcc upto gcc-9.2.0 but multilib is broken and has been for some time so no new versions of those untill the bugs get ironed out upstream.
This just means you have to select which bitness the compiler must support 32 or 64 bit.

[killerbot]

interesting, feel free to give it a try.

[TDragon]

Hi there,

Just popping in to say that I've spun up a new TDM-GCC release and shoved everything into Github. Apologies for the radio silence. I started working on GCC 9.1 last year sporadically and finally got everything in a working state again!

It's still a one-man show but feel free to file issues on Github (https://github.com/jmeubank/tdm-gcc) and I might take a peek more often.

In the years since the last TDM-GCC release, the MSYS2 project has gained continual traction and their recent toolchains function quite well. TDM-GCC does still offer 32-bit and 64-bit compilation as a one-stop shop, and tries *real* hard not to tie you to unwanted DLLs. Use whichever works for you!

Cheers,
John E. / TDM

[ollydbg]

Hi there,

Just popping in to say that I've spun up a new TDM-GCC release and shoved everything into Github. Apologies for the radio silence. I started working on GCC 9.1 last year sporadically and finally got everything in a working state again!

It's still a one-man show but feel free to file issues on Github (https://github.com/jmeubank/tdm-gcc) and I might take a peek more often.

In the years since the last TDM-GCC release, the MSYS2 project has gained continual traction and their recent toolchains function quite well. TDM-GCC does still offer 32-bit and 64-bit compilation as a one-stop shop, and tries *real* hard not to tie you to unwanted DLLs. Use whichever works for you!

Cheers,
John E. / TDM

Hi, John, long time no see. Great work for your new TDM-GCC release!

[gd_on]

Cool, ... but ...
I tried to compile wxWidgets 3.1.4 (git) : OK
I tried to compile C::B, svn 11979 with this wxWidgets 3.1.4 (git) : OK
I tried to compile one of my own programs, also using this wxWidgets 3.1.4 (git) : OK
In each case, executable is bigger tha previously, but it's normal because this gcc version has more statically linked parts.

But I had a crash in C::B itself when working on a project :
To obtain this crash :
In my workspace menu, "Properties...", and in the "Build Target" tab, I choosed one of the Build targets, clicked on the "Duplicate" button, accepted the name "copy of ..." and simply clicked on the OK button of the "Project/target options" window without changing anything. C::B crashes but no RPT file was created.
No such problem with gcc 9.2 found in msys2 nor with gcc 8.1.
Sorry 

[TDragon]

Go get us a stack trace and we'll see what we can do!

[gd_on]

I don't know how to do that !

[TDragon]

Well, this is where the real development work happens.

You have to build wxWidgets with debug flags (CFLAGS=-g CXXFLAGS=-g) and then build Code::Blocks with debug flags. And then you run CB under GDB (gdb codeblocks.exe) and, when it crashes, you see a lovely little call stack of all the functions that were on the stack when the crash was triggered!

[gd_on]

Oups ! Some work to do... Need some time.
More, simplu opening and closing the workspace "Properties" is sufficient to create the problem.

PS :
could it be my wxWidgets generation ? I use a .bat file containing, until now :

mingw32-make -f makefile.gcc USE_XRC=1 SHARED=1 MONOLITHIC=1 BUILD=release UNICODE=1 USE_OPENGL=1 DEBUG_LEVEL=0 VENDOR=cb_64 CXXFLAGS="-fpermissive -fno-keep-inline-dllexport -std=gnu++11 -Wno-deprecated-declarations" LDFLAGS="-Wl,--allow-multiple-definition"

[gd_on]

With this TDM 9.2 version :
I compiled a debug version of wxWidgets 3.1.4
I compiled a debug version of C::B without contrib plugins.
I copied the wxwidgets dll directly in devel folder and launched this new codeblocks.exe directly in this folder.
I have been able to load a workspace, to open and close a "Property..." window without problems.
So, ... the problem I met before comes probably from one of the contrib plugins.
Need some more work to try to identify which one ...

[gd_on]

I disabled all plugins the re-enabled them one by one. Apparently, the problem is within lib_finder.

[killerbot]

such cool news, I will give it a try ASAP, to try to build CB also with this toolchain, because maybe, just maybe, it might be interesting to bundle this one in our release ....

I probably will build this weekend, so let's hope that already the work of gd_on paves the road ;-)

[TDragon]

Personally I think you should go back to TDM-GCC 4.7.1, that's the last release that didn't bloat C++ code horrifically. But I'll keep rolling newer GCC releases when I can, and maybe the upstream maintainers will find some time to pay a little love to the libstdc++ import cruft that's been happening.

[gd_on]

OK.
I tried to run codeblocks under gdb. As it's the first time I do such a thing, I'm not totally sure of the result.
I compiled a wxWidget debug version (3.1.4 as told previously, not tested with 3.1.3 version).
I compiled codeblocks project, all wx* plugins and only lib_finder, using -g as cb_release_type and using <Variable name="WX_SUFFIX" value="ud" /> in each compiled project.

Here is a copy of the backtrace obtained in a cmd window after the crash.
If this can help...
gd_on

[TDragon]

Thanks for grabbing the stack trace! It definitely confirms that the problem happens in the lib_finder contrib plugin's ~ProjectConfigurationPanel() destructor.

Does it happen if you build with CXXFLAGS="-shared-libgcc -shared-libstdc++"?

The problem happens when one of the wxTextCtrl destructors triggers a std::locale::~locale() destructor, which I'm not familiar with and don't see the dependency yet in wxWidgets' code. I'm generally suspicious of double-deletion in cases like this but I don't see anything in lib_finder triggering a deletion when it shouldn't.

[gd_on]

I suppose you mean that I have to modify my wxWidgets build, which becomes :

Code: [Select]

mingw32-make -f makefile.gcc USE_XRC=1 SHARED=1 MONOLITHIC=1 BUILD=debug CFLAGS=-g UNICODE=1 USE_OPENGL=1 VENDOR=cb_64 CXXFLAGS="-g -shared-libgcc -shared-libstdc++ -fpermissive -fno-keep-inline-dllexport -std=gnu++11 -Wno-deprecated-declarations" LDFLAGS="-Wl,--allow-multiple-definition"
if it's still useful to build a debug version.

And, shall I have to generate C::B also with these flags ?

PS :
I tried with these flags in wxWidgets and C::B. The crash is always there.

[ollydbg]

Hi, gd_on.
I just did some test with tdm gcc 9.2 64bit. I don't see crash of the lib_finder plugin. Here is my steps:

1. download wx 3.1.3 release.
2, modify the setup.h to enable the direct2d support
3, use the command line below to build the wx library

Code: [Select]

mingw32-make -f makefile.gcc USE_XRC=1 SHARED=1 MONOLITHIC=1 BUILD=release UNICODE=1 USE_OPENGL=1 VENDOR=cb CXXFLAGS="-Wno-unused-local-typedefs -Wno-deprecated-declarations -fno-keep-inline-dllexport" >log-release.txt 2>&1
4, I build the CodeBlocks_wx31_64.cbp, all the targets in this cbp are built. (I set the cb_release_type string : -g -O0)
5, open the CodeBlocks_wx31_64.workspace, and set the lib finder plugin as the active plugin, and build this single plugin.
6, run the command: update31_64.bat
7, start the new built cb inside the cb
8, open some test project, and close the new built cb

There is no crash here.

[TDragon]

That's good news @ollydbg!

This means that @gd_on could be using a version of the lib_finder plugin DLL, or a dependency DLL, built by a different toolchain.

I try to make it possible to mix DLLs and EXEs between TDM-GCC and other toolchains, but there are some cases where it's not. I'll continue to try and spot the incompatibility if I have time, but it sounds like doing a clean build of Code::Blocks and all plugins with TDM-GCC could be enough?

README-gcc-tdm64.md

If you pass the -shared-libgcc and -shared-libstdc++ flags to TDM-GCC, it will built DLLs and EXEs that depend on the libgcc and libstdc++ DLLs. A DLL or EXE built with these options can safely link to a MinGW.org or MinGW-w64 DLL or EXE and pass exceptions into and out of DLLs, if the other GCC and TDM-GCC share the same GCC libstdc++ ABI. The ABI may change between GCC minor releases. 32-bit and 64-bit DLLs and EXEs mostly cannot interoperate.

[gd_on]

I tried to build wxwidgets 3.1.3 (and here not 3.1.4 as previously) and C::B (svn 11979) as ollydbg suggested. I have made, as far as I know, a clean build, in a totally new folder ....
But that was not enough. I have always a crash in lib_finder... strange.
As I told before, no problems with 9.2 version distributed with Msys2 !

[stahta01]

What compiler are you using with the crash?

Tim S.

[ollydbg]

Hi, gd_on.
I just did some test with tdm gcc 9.2 64bit. I don't see crash of the lib_finder plugin. Here is my steps:

1. download wx 3.1.3 release.
2, modify the setup.h to enable the direct2d support
3, use the command line below to build the wx library

Code: [Select]

mingw32-make -f makefile.gcc USE_XRC=1 SHARED=1 MONOLITHIC=1 BUILD=release UNICODE=1 USE_OPENGL=1 VENDOR=cb CXXFLAGS="-Wno-unused-local-typedefs -Wno-deprecated-declarations -fno-keep-inline-dllexport" >log-release.txt 2>&1
4, I build the CodeBlocks_wx31_64.cbp, all the targets in this cbp are built. (I set the cb_release_type string : -g -O0)
5, open the CodeBlocks_wx31_64.workspace, and set the lib finder plugin as the active plugin, and build this single plugin.
6, run the command: update31_64.bat
7, start the new built cb inside the cb
8, open some test project, and close the new built cb

There is no crash here.

Some more information.
I have build the whole targets in the CodeBlocks_wx31_64.workspace under TDM64bit compiler, except the FortranProject(because I use the git-svn) and the NassiShneiderman(because I don't have the boost headers)

I see no crash in the new built 64bit C::B.

[gd_on]

I use the new TDM 64 bit compiler, 9.2 version, to do these tests. I downloaded it via TDM web site.
As I told before, wxWidgets (3.1.3 or 3.1.4) is correctly compiled.
C::B itself is also correctly compiled and works for many usages, exept when I look at a workspace property, as explained before.
Normally, I use only one compiler each time, though I have several different ones on my PC. But only one is in the path and configured to be used by C::B.
May be there is sometimes a mix at compile time, but I don't see why...
I have to investigate more, sure ... If it works for others, it should work for me !

gd_on

[stahta01]

Has only one that tested lib_finder had it configured to work?
Because, I for one have no idea how to configure it to work.
And, I just wondered if it is a configuration issue that is causing it to crash.

Tim S.

[gd_on]

I don't use lib_finder until now. So it's certainly not configured. Could it be the problem in my case ?
For me disabling it, do the job.

[oBFusCATed]

If it is a configuration option problem you'll have the same problem using a night build. Is this the case? Can you try it?

[gd_on]

As told previously I use already svn 11979 build.

[TDragon]

Since the crash happens in std::locale, what's your system locale? Default character set / code page. Does the configuration contain any non-ascii characters? If so, this is a good place to dig further.

[gd_on]

My locale is fr_FR : I am french. My standard C::B is configured to use French also in the GUI.
Nevertheless, for these tries I use an other folder where the translation file of the GUI is not installed, and it appears in English.
By default, my C::B uses utf-8.
The strange thing if that it works correctly if I compile wxWidgets and C::B with gcc 8.1, 9.2 (Msys2), 9.2 (Equation), 9.2 (Winlibs) in 64 bits (not tested in 32 bits). Only TDM version gives me this problem and apparently only in a specific menu (I have not found such problems elsewhere, but surely I have not tested everithing !)

[gd_on]

May be a clue. During a test, my antivirus has decided that codeblocks.exe contained a virus. More, gcc.exe has been erased from my compiler folder without any warning.
I disabled my AV soft, and re-ran C::B. Nothing is erased there, but the bug is still alive 

[TDragon]

Not sure that it would cause the crash, but what AV software are you using? I already had to submit a retest of the tdm-gcc-webdl installer for Windows Defender in order for it not to be quarantined on day 1.

[gd_on]

McAfee LiveSafe

[ollydbg]

I think I see a similar crash when I run c::b built from TDM64 under GDB.

This happens when I create a new wxWidgets project by the project wizard, C::B just crashed. GDB shows such bt.

Code: [Select]

> bt
#0  0x0000000077cef2d0 in ntdll!RtlUnhandledExceptionFilter () from C:\Windows\SYSTEM32\ntdll.dll
#1  0x0000000077cef8d6 in ntdll!EtwEnumerateProcessRegGuids () from C:\Windows\SYSTEM32\ntdll.dll
#2  0x0000000077cf04f2 in ntdll!RtlQueryProcessLockInformation () from C:\Windows\SYSTEM32\ntdll.dll
#3  0x0000000077cf2604 in ntdll!RtlLogStackBackTrace () from C:\Windows\SYSTEM32\ntdll.dll
#4  0x0000000077c5a232 in ntdll!RtlFreeHeap () from C:\Windows\SYSTEM32\ntdll.dll
#5  0x000007feff8d10c8 in msvcrt!free () from C:\Windows\system32\msvcrt.dll
#6  0x000000006cf6c86d in std::locale::_Impl::~_Impl() () from F:\code\wx313-64\lib\gcc_dll\wxmsw313u_gcc_cb.dll
#7  0x000000006cf6ccd0 in std::locale::~locale() () from F:\code\wx313-64\lib\gcc_dll\wxmsw313u_gcc_cb.dll
#8  0x000000006c4cc59b in wxTextCtrl::~wxTextCtrl() () from F:\code\wx313-64\lib\gcc_dll\wxmsw313u_gcc_cb.dll
#9  0x000000006c4cc61e in wxTextCtrl::~wxTextCtrl() () from F:\code\wx313-64\lib\gcc_dll\wxmsw313u_gcc_cb.dll
#10 0x000000006c657e5d in wxWindowBase::Destroy() () from F:\code\wx313-64\lib\gcc_dll\wxmsw313u_gcc_cb.dll
#11 0x000000006c657f64 in wxWindowBase::DestroyChildren() () from F:\code\wx313-64\lib\gcc_dll\wxmsw313u_gcc_cb.dll
#12 0x000000006c3ca62b in wxWindow::~wxWindow() () from F:\code\wx313-64\lib\gcc_dll\wxmsw313u_gcc_cb.dll
#13 0x000000001150520c in wxNavigationEnabled<wxWindow>::~wxNavigationEnabled (this=0x1e68d600, __in_chrg=<optimized out>) at F:/code/wx313-64/include/wx/containr.h:189
#14 0x00000000115013aa in wxPanelBase::~wxPanelBase (this=0x1e68d600, __in_chrg=<optimized out>) at F:/code/wx313-64/include/wx/panel.h:30
#15 0x000000001150fb5a in wxPanel::~wxPanel (this=0x1e68d600, __in_chrg=<optimized out>) at F:/code/wx313-64/include/wx/msw/panel.h:19
#16 0x00000000114cb07e in ProjectPathPanel::~ProjectPathPanel (this=0x1e68d600, __in_chrg=<optimized out>) at D:\code\cb\cb_sf_git\cccrash2019\src\plugins\scriptedwizard\projectpathpanel.cpp:86
#17 0x00000000114cb09b in ProjectPathPanel::~ProjectPathPanel (this=0x1e68d600, __in_chrg=<optimized out>) at D:\code\cb\cb_sf_git\cccrash2019\src\plugins\scriptedwizard\projectpathpanel.cpp:88
#18 0x000000006c657e5d in wxWindowBase::Destroy() () from F:\code\wx313-64\lib\gcc_dll\wxmsw313u_gcc_cb.dll
#19 0x000000006c657f64 in wxWindowBase::DestroyChildren() () from F:\code\wx313-64\lib\gcc_dll\wxmsw313u_gcc_cb.dll
#20 0x000000006c3ca62b in wxWindow::~wxWindow() () from F:\code\wx313-64\lib\gcc_dll\wxmsw313u_gcc_cb.dll
#21 0x000000001150520c in wxNavigationEnabled<wxWindow>::~wxNavigationEnabled (this=0x1ed30200, __in_chrg=<optimized out>) at F:/code/wx313-64/include/wx/containr.h:189
#22 0x00000000115013aa in wxPanelBase::~wxPanelBase (this=0x1ed30200, __in_chrg=<optimized out>) at F:/code/wx313-64/include/wx/panel.h:30
#23 0x000000001150fb5a in wxPanel::~wxPanel (this=0x1ed30200, __in_chrg=<optimized out>) at F:/code/wx313-64/include/wx/msw/panel.h:19
#24 0x0000000011502810 in wxWizardPage::~wxWizardPage (this=0x1ed30200, __in_chrg=<optimized out>) at F:/code/wx313-64/include/wx/wizard.h:55
#25 0x0000000011504aaa in wxWizardPageSimple::~wxWizardPageSimple (this=0x1ed30200, __in_chrg=<optimized out>) at F:/code/wx313-64/include/wx/wizard.h:121
#26 0x00000000114d971a in WizPageBase::~WizPageBase (this=0x1ed30200, __in_chrg=<optimized out>) at D:\code\cb\cb_sf_git\cccrash2019\src\plugins\scriptedwizard\wizpage.cpp:108
#27 0x00000000114dad9e in WizProjectPathPanel::~WizProjectPathPanel (this=0x1ed30200, __in_chrg=<optimized out>) at D:\code\cb\cb_sf_git\cccrash2019\src\plugins\scriptedwizard\wizpage.cpp:338
#28 0x00000000114dadbb in WizProjectPathPanel::~WizProjectPathPanel (this=0x1ed30200, __in_chrg=<optimized out>) at D:\code\cb\cb_sf_git\cccrash2019\src\plugins\scriptedwizard\wizpage.cpp:340
#29 0x000000006c657e5d in wxWindowBase::Destroy() () from F:\code\wx313-64\lib\gcc_dll\wxmsw313u_gcc_cb.dll
#30 0x000000006c657f64 in wxWindowBase::DestroyChildren() () from F:\code\wx313-64\lib\gcc_dll\wxmsw313u_gcc_cb.dll
#31 0x000000006c3ca62b in wxWindow::~wxWindow() () from F:\code\wx313-64\lib\gcc_dll\wxmsw313u_gcc_cb.dll
#32 0x000000006c378fa7 in wxNonOwnedWindow::~wxNonOwnedWindow() () from F:\code\wx313-64\lib\gcc_dll\wxmsw313u_gcc_cb.dll
#33 0x000000006c75c1ce in wxWizard::~wxWizard() () from F:\code\wx313-64\lib\gcc_dll\wxmsw313u_gcc_cb.dll
#34 0x000000006c10308e in wxAppConsoleBase::DeletePendingObjects() () from F:\code\wx313-64\lib\gcc_dll\wxmsw313u_gcc_cb.dll
#35 0x000000006c103138 in wxAppConsoleBase::ProcessIdle() () from F:\code\wx313-64\lib\gcc_dll\wxmsw313u_gcc_cb.dll
#36 0x000000006c5026e1 in wxAppBase::ProcessIdle() () from F:\code\wx313-64\lib\gcc_dll\wxmsw313u_gcc_cb.dll
#37 0x000000006c13ce44 in wxEventLoopManual::DoRun() () from F:\code\wx313-64\lib\gcc_dll\wxmsw313u_gcc_cb.dll
#38 0x000000006c13cb1b in wxEventLoopBase::Run() () from F:\code\wx313-64\lib\gcc_dll\wxmsw313u_gcc_cb.dll
#39 0x000000006c106fec in wxAppConsoleBase::MainLoop() () from F:\code\wx313-64\lib\gcc_dll\wxmsw313u_gcc_cb.dll
#40 0x000000000040540a in CodeBlocksApp::OnRun (this=0x3ae18c0) at D:\code\cb\cb_sf_git\cccrash2019\src\src\app.cpp:901
#41 0x000000006c192aaa in wxEntryReal(int&, wchar_t**) () from F:\code\wx313-64\lib\gcc_dll\wxmsw313u_gcc_cb.dll
#42 0x00000000004022a1 in WinMain (hInstance=0x400000, hPrevInstance=0x0, nCmdShow=10) at D:\code\cb\cb_sf_git\cccrash2019\src\src\app.cpp:338
#43 0x00000000005e9422 in main (flags=<optimized out>, cmdline=<optimized out>, inst=<optimized out>) at C:/crossdev/src/mingw-w64-v7-git20191109/mingw-w64-crt/crt/crt0_c.c:18
#44 0x00000000004013b4 in __tmainCRTStartup () at C:/crossdev/src/mingw-w64-v7-git20191109/mingw-w64-crt/crt/crtexe.c:339
#45 0x00000000004014db in WinMainCRTStartup () at C:/crossdev/src/mingw-w64-v7-git20191109/mingw-w64-crt/crt/crtexe.c:195



[salvat]

Hi @TDragon

I found out that the function GetTickCount64() is not active in the header-file, if I set "#define _WIN32_WINNT 0x0600" to activate it in TDM-GCC-32 (4.x and 9.2.0)
--> undefined reference to `GetTickCount64'

TDM-GCC-64 (4.x and 9.2.0) does compile fine, but strangely it is also not active in the header-file and it can't be find, if I click on "Find decleration of GetTickCount64 " in the context menu ??
Is that a bug in the header-files of MinGW?

[TobiasA]

So I'll revive that thread in the hope it pops to the start.

I'm having the same and can reproduce it by compiling wxWidgets 3.1.4 in 64bit, compiling any app with a wxTextCtrl in it and destroying that textctrl. I have some applications with a textctrl in it, and each of them crashes with the stack pointing to the destructor of locale.

Code: [Select]

The stack is:
#0 0x76f8f230    ntdll!RtlUnhandledExceptionFilter() (C:\Windows\SYSTEM32\ntdll.dll:??)
#1 0x76f8f836    ntdll!EtwEnumerateProcessRegGuids() (C:\Windows\SYSTEM32\ntdll.dll:??)
#2 0x76f90452    ntdll!RtlQueryProcessLockInformation() (C:\Windows\SYSTEM32\ntdll.dll:??)
#3 0x76f92564    ntdll!RtlLogStackBackTrace() (C:\Windows\SYSTEM32\ntdll.dll:??)
#4 0x76efa232    ntdll!RtlFreeHeap() (C:\Windows\SYSTEM32\ntdll.dll:??)
#5 0x7fefee710c8    msvcrt!free() (C:\Windows\system32\msvcrt.dll:??)
#6 0x12a44bd    std::locale::_Impl::~_Impl() () (C:\wxGccTDM314\lib\gcc_dll64\wxmsw314ud_core_gcc_cb.dll:??)
#7 0x12a4920    std::locale::~locale() () (C:\wxGccTDM314\lib\gcc_dll64\wxmsw314ud_core_gcc_cb.dll:??)
#8 0x1153e0f    wxTextCtrlBase::~wxTextCtrlBase(this=0xc01dc70, __in_chrg=<optimized out>) (C:\wxGccTDM314_64\build\msw/../../include/wx/textctrl.h:693)
#9 0xe49951    wxTextCtrl::~wxTextCtrl(this=0xc01dc70, __in_chrg=<optimized out>) (C:\wxGccTDM314_64\build\msw/../../src/msw/textctrl.cpp:354)
#10 0xe49991    wxTextCtrl::~wxTextCtrl(this=0xc01dc70, __in_chrg=<optimized out>) (C:\wxGccTDM314_64\build\msw/../../src/msw/textctrl.cpp:365)
#11 0xf45f26    wxWindowBase::Destroy(this=0xc01dc70) (C:\wxGccTDM314_64\build\msw/../../src/common/wincmn.cpp:578)
#12 0xf46085    wxWindowBase::DestroyChildren(this=0xc0178d0) (C:\wxGccTDM314_64\build\msw/../../src/common/wincmn.cpp:610)
#13 0xdb68ec    wxWindow::~wxWindow(this=0xc0178d0, __in_chrg=<optimized out>) (C:\wxGccTDM314_64\build\msw/../../src/msw/window.cpp:483)
#14 0x117bdd8    wxNavigationEnabled<wxWindow>::~wxNavigationEnabled(this=0xc0178d0, __in_chrg=<optimized out>) (C:\wxGccTDM314_64\build\msw/../../include/wx/containr.h:189)
#15 0x1135e4a    wxPanelBase::~wxPanelBase(this=0xc0178d0, __in_chrg=<optimized out>) (C:\wxGccTDM314_64\build\msw/../../include/wx/panel.h:30)
#16 0x11c0d26    wxPanel::~wxPanel(this=0xc0178d0, __in_chrg=<optimized out>) (C:\wxGccTDM314_64\build\msw/../../include/wx/msw/panel.h:19)
#17 0x11c0ce5    wxPanel::~wxPanel(this=0xc0178d0, __in_chrg=<optimized out>) (C:\wxGccTDM314_64\build\msw/../../include/wx/msw/panel.h:19)
#18 0xf45f26    wxWindowBase::Destroy(this=0xc0178d0) (C:\wxGccTDM314_64\build\msw/../../src/common/wincmn.cpp:578)
#19 0xf46085    wxWindowBase::DestroyChildren(this=0xbfddae0) (C:\wxGccTDM314_64\build\msw/../../src/common/wincmn.cpp:610)
#20 0xdb68ec    wxWindow::~wxWindow(this=0xbfddae0, __in_chrg=<optimized out>) (C:\wxGccTDM314_64\build\msw/../../src/msw/window.cpp:483)
#21 0xe85fb8    wxControlBase::~wxControlBase(this=0xbfddae0, __in_chrg=<optimized out>) (C:\wxGccTDM314_64\build\msw/../../src/common/ctrlcmn.cpp:48)
#22 0x11e7c8c    wxControl::~wxControl(this=0xbfddae0, __in_chrg=<optimized out>) (C:\wxGccTDM314_64\build\msw/../../include/wx/msw/control.h:17)
#23 0x114d347    wxBookCtrlBase::~wxBookCtrlBase(this=0xbfddae0, __in_chrg=<optimized out>) (C:\wxGccTDM314_64\build\msw/../../include/wx/bookctrl.h:55)
#24 0x1152aa3    wxNotebookBase::~wxNotebookBase(this=0xbfddae0, __in_chrg=<optimized out>) (C:\wxGccTDM314_64\build\msw/../../include/wx/notebook.h:103)
#25 0xe2552d    wxNotebook::~wxNotebook(this=0xbfddae0, __in_chrg=<optimized out>) (C:\wxGccTDM314_64\build\msw/../../src/msw/notebook.cpp:296)
#26 0xe25553    wxNotebook::~wxNotebook(this=0xbfddae0, __in_chrg=<optimized out>) (C:\wxGccTDM314_64\build\msw/../../src/msw/notebook.cpp:302)
#27 0xf45f26    wxWindowBase::Destroy(this=0xbfddae0) (C:\wxGccTDM314_64\build\msw/../../src/common/wincmn.cpp:578)
#28 0xf46085    wxWindowBase::DestroyChildren(this=0xbfdd1e0) (C:\wxGccTDM314_64\build\msw/../../src/common/wincmn.cpp:610)
#29 0xdb68ec    wxWindow::~wxWindow(this=0xbfdd1e0, __in_chrg=<optimized out>) (C:\wxGccTDM314_64\build\msw/../../src/msw/window.cpp:483)
My locale is german.
32bit is fine, been using it for quite some time, apps are running fine and stable in both win7 and win10.

[ollydbg]

@TobiasA

For those days, I mainly use the GCC compiler inside the MSYS2 suite.

But someone mention other compilers in this thread.

I can't reply to you in the wx-user Google Group Application crashes on exit in 64bit (My message always get deleted automatically), so I reply it here.

[reckless]

Msys2 mingw-w64 has had some interresting development lately as it added hardening (ASLR / DEP) to pretty much the entire compiler. This has had the benefit that most AV solutions no longer complain about malicious code in the compiled executables.
But it is still early days and the hardening may not work for every project (some projects will crash outright if ASLR is on) and wxwidgets is one of them. This might be because we push the image base high by default on 64 bit builds (does not work with everything) DEP usually works without any problem though. TDM's gcc unfortunatly is wholly incompatible with this and cannot be built with ASLR or DEP at all, probably due to how it handles throwing exceptions from statically linked executables.
Still we are very much still in experimental territory and a more stable implementation might come with the next binutils release.
Atm we rely on a rather substantial patchset for binutils-2.35 but there are plans to make it a feature of upcomming binutils on windows.

[reckless]

Well i managed to get a TDM version of gcc-10.2.0 built with ASLR and DEP.
I had to rearrange a few things in the eh_shmem.patch also getting rid of a few of the trap calls which seems to be the problem with it on x86_64.
still it is not completly safe to use ASLR with it as some packages who do not exhibit any failures on standard msys2 mingw-w64 will segfault,
but it is far less than what it has been so it is up to the developer if he wants to try his hand at it.

Atm im building the various make tools (cmake meson ninja) which has turned out to be a massive pain in the butt
since many of the tools over the years have picked up a lot of circular dependencies (freetype fontconfig etc.).

when done i will provide a link for those who want to experiment with it.