The class wxTextCtrl is not working while building with "MinGW TDM 64 bit #22639
Comments
|
Thanks, but to make this bug report more useful, could you please:
TIA! |
|
Dear Vadz. Since I only use a monolithic build DLL of wxWidgets I could not confirm that it is not happening with separate DLLs or with static libraries. The change I have implemented was done in the wxWidgets header
I have not modified the text sample but the wxWidgets library code.
Actually I thought this issue is already known by you since 2018 since the one who has suggested the workaround "Vadim Zeitlin" seems to be the author of the source-file I have modified. Best regards, |
|
Yes, I suggested the workaround because it clearly bypasses the problem entirely. As you said, this is not a proper solution, but I didn't have time to debug the issue back then -- and, to be honest, don't have much more time to do it now neither. So if you could check whether the issue occurs with the multilib build, it would be helpful. |
|
Dear Vadz. The big disadvantage of using small part-libraries is the fact that you have to figure out which you really need. However, as far as I understand you use the same compiler for your official TDM binary release.
Best regards, |
The advantage is that you don't need to link with stuff that you don't need.
You need to link with base and core, and you don't need any MSVS projects. Just replace the mono DLL with the base and core ones in your existing project. |
|
Hello Vadz. As you have advised, I have replaced my monolithic DLL
Furthermore I have modified the header I have started the text-sample application and closed it again.
Please find attached the sample folder with the core and base DLLs taken from the 3.2.0_gcc1030TDM_x64_ReleaseDLL.7z Attention: Read my PS.: regarding a potential virus-detection in the base DLL. Best regards, PS.: I've got an notification from my virus-scanner (Norton 360) when I placed the |
|
OK, thanks, I'll try to debug this. |
|
Hello Vadz. Thank you in advance for all the effort you will take. Best regards, |
When inheriting from std::streambuf, as is the case by default, and creating wxTextCtrl in the application (as is common) and destroying it in the library (as is even more so, as it's typically done when the parent window is destroyed), having inline constructor but not inline destructor apparently results in std::locale, which is part of std::streambuf, to be allocated and destroyed using different heaps or something similar when using TDM-GCC libstdc++, as destroying std::locale inside the library corrupts the heap and results in crashes when the next std::locale object is destroyed -- i.e. creating, and then destroying, more than one wxTextCtrl results in a crash. Work around this by moving the constructors out of line, as this is sufficient to avoid the problem, even if it's exact causes are not exactly clear. This commit is best viewed with Git --color-moved option. See wxWidgets#22639.
|
After spending a couple of hours on this, I finally have a fix, see the PR #22641. I still don't fully understand what's going on here, but TDM-GCC libstdc++ does something weird and doesn't allow creating The annoying thing is that this is, of course, not ABI-compatible, so can't be applied to 3.2 as is. But it's clearly worth breaking ABI compatibility for TDM-GCC if this means avoiding crashes... However I don't know how to check for TDM-GCC in the preprocessor, does anybody? My debugging notes, not really needed any moreI can reproduce the crash. Annoyingly, it doesn't happen in the debug build, but in the release one it crashes on exit due to heap corruption, resulting in Moreover, I can even reproduce it using this minimal example #include "wx/app.h"
#include "wx/textctrl.h"
struct MyApp : wxApp {
bool OnInit() override {
wxTextCtrl t1;
wxTextCtrl t2;
return false;
}
};
wxIMPLEMENT_APP(MyApp);i.e. simply destroying the second text control results in this problem as, apparently, destroying the first one corrupts memory. And there is no almost wx code being involved here, as |
|
Just for the record: I think this is a rather old issue, discovered in 2020 with TDM 9.2 (only 64-bit version IIRC) and discussed on wx-dev and forum. And to answer the question from the related PR: WinLibs is a MinGW distribution (unlike nuwen not providing some popular prebuilt libraries but being more up-to-date), aiming to fill a hole left by mingw-64 project not providing their own installer anymore. I know it may be hard to believe, but it seems many people do not like / are not familiar with MSYS2 environment and strongly prefer to use non-MSYS2 up-to-date MinGW distro and building wxWidgets with a makefile. |
|
Yes, thanks, these links were actually given in #22636 in which I had asked to create a separate issue for this problem, but the context got lost, sorry about this. As for people preferring building with a makefile, I realize that they exist. This is a problem because I have no idea how to maintain the makefiles for them, but, I guess, we'll have to do it somehow... |
vadz
added
the
backport-3.2
|
I've realized that 70c5ec6 (Move wxTextCtrl constructors out of line in wxMSW, 2022-07-18) still wasn't backported to 3.2. I think it should be safe to do it, but it'd be great if somebody could actually confirm it, i.e. build a program with the current wx 3.2 DLLs, then apply this commit, rebuild the DLLs and confirm that the program still runs when using them (and sorry in advance if anybody has already done it and I just forgot about it, but I couldn't find anything like this in the various bugs/PRs associated with this problem). |
|
I've finally tested this myself and as it seems to work fine, I'm backporting this fix to 3.2. |
vadz
removed
the
backport-3.2
When inheriting from std::streambuf, as is the case by default, and creating wxTextCtrl in the application (as is common) and destroying it in the library (as is even more so, as it's typically done when the parent window is destroyed), having inline constructor but not inline destructor apparently results in std::locale, which is part of std::streambuf, to be allocated and destroyed using different heaps or something similar when using TDM-GCC libstdc++, as destroying std::locale inside the library corrupts the heap and results in crashes when the next std::locale object is destroyed -- i.e. creating, and then destroying, more than one wxTextCtrl results in a crash. Work around this by moving the constructors out of line, as this is sufficient to avoid the problem, even if it's exact causes are not exactly clear. This commit is best viewed with Git --color-moved option. See wxWidgets#22639, wxWidgets#22735. (cherry picked from commit 70c5ec6)
Dear Developers.
The class
wxTextCtrlis not working while building with "MinGW TDM 64 bit.If you build wxWidgets as a monolithic 64 bit DLL by using TDM-GCC 10.3.0 you could use in your application not more than on instance of the class
wxTextCtrl. Otherwise the application is crashing while destroying the instances. You will already face this issue with the official sample.Please take look to the "std::streambuf" issue.
In addition you could take a look into your forum: Abnormal program exit
It works only if you modify the header "wx/textctrl.h" as Vadim Zeitlin wrote:
Thus I implemented the following change:
#if wxUSE_STD_IOSTREAM
#include "wx/ioswrap.h"
// #define wxHAS_TEXT_WINDOW_STREAM 1
#define wxHAS_TEXT_WINDOW_STREAM 0 // changed by Eckard Klotz 2022.07.10
#else
#define wxHAS_TEXT_WINDOW_STREAM 0
#endif
And yes, if you do so before building the DLL and the application it helps. But this is only a workaround and hope you are able to provide a more professional solution.
Platform and version information
Best regards,
Eckard Klotz.
The text was updated successfully, but these errors were encountered: