Bug/crash on 3.2.2.1 (wxSplashScreen, all GUI-Elements)

[Tecnoworld]

Hello,
I´ve changed the toolchain from TDM-GCC 4.8 to 10.3, wxWidgets from 3.0.2 to 3.2.2.1, Codeblocks from 10.3 to 20.03.

Without changinf the code now I have severall problems.
One problem is the wxSplashScreen:
I use them with BitmapType_png, it works on different machines, but on some Win10 machines it craches in the constructor.
If I compile the debug version, it runs perfectly - so I can´t debug this.
If I comment out the wxSplash-Screen the program starts, but the Screen is almost empty. I use wxSmith to create the Dialogs.

Also its very rare, that on Windows wxBitmap can not display empty images (alpha channel). It comes as a block box.
This happens on all Windows versions (Win7, Win10).

Someone can help me with this case?

Best,
Ingolf

[ONEEYEMAN]

Hi,
There was a recent forum post in regards to the problem with the Splash Screen.

Search the forum and see if the solution will help.

Thank you.

[Tecnoworld]

Thanks for the hint, but this i have done bevor. This is only a problem with transparency, not a crash.

[doublemax]

Recently there was a compiler optimization bug fixed that affected wxImage, but it was for Visual C++.

Can you load the image with wxImage::Load()?

Also, it should be possible to add debug information to a release build, or enable cpu optimization for a debug build (in case that's a potential cause for the crash).

[Tecnoworld]

Ok, the optimization I will try
If I add debugg info and no-optimization then the program runs perfectly.

[Tecnoworld]

Ok, when I compile my program against the wxwidgets release dll's it always crashes. I can't use optimisation or O1, O2, O3 - and I can create debug symbols - no changes - it always crashes.

When I compile against the wxwidgets debug dll's it works fine.

I compile wxWidgest with:
mingw32-make -f makefile.gcc MONOLITHIC=1 SHARED=1 UNICODE=1 BUILD=release

and for debugging with:
mingw32-make -f makefile.gcc MONOLITHIC=1 SHARED=1 UNICODE=1 Debug_Flags=2 Debug_INFO=1 BUILD=debug

in earlier versions I had to add the flag USE_OPENGL=1 to generate the opengl support. In 3.2.2.1, an error message appears when I use this flag, but Opengl support seems to be compiled by default.

[ONEEYEMAN]

Hi,
This will probably not help you, but:

UNICODE options is the default one, so you can drop it.

Unless you are CodeBlocks developer I suggest to drop MONOLITHIC build.

Now, what if you give Debug_Flags and Debug_INFO options to release build? One by one...

Thank you.

[Tecnoworld]

Monolithic is necessary because I want to deploy all single dll´s. This can be complicated with updates. Our software was distributed since 2012, and over this time we had a lot of updates - always simpler with fewer files.

The debug-options are only for the debug version - not release.
The two options, as I read, are different options, not the same. Info enables is more detailed info, as I understud.

But all of them don´t change my problem.
This happens also, I f I build wxWidgets on a different System (Win7) - the result is the same - the program crashes.
The crash is not only the Splash screen. If I take out the Spalsh screen it crashes in the Main frame.

[[email protected]]

When a program crashes in release build only, the most common reasons are:
1) use of an uninitialized variable (which will be 0 in debug, but may contain random garbage in release build)
2) compiler optimization

You will need a call stack to debug this properly, so you should add debug info in release build (For your project, not the wx libs).
In VS this would be simple, but i don't know how to do it with MinGW.

[Tecnoworld]

My programm runs perfect in release build and in debug build.
Problem is wxWidgets.
I compiled now the release build of wxWidgets with -O0 instead of -O2 like default settings and then the libs are running.

So the problem is a bug in wxWidgets with the optimization flags.

This happens only on some Win10 machines, but not on all.
On Intel NUC system with Win10 pro happens on 2 machines, on all other I have runs fine.

[ONEEYEMAN]

Hi,
What flavor/version of MinGW do you use?

Can you build it with MSVC? A frfee one just for the test?

Also - I'm not sure I understand.
You program does not run fine in both debug and release modes. It either crashes or have a problem with the wxSplashScreen.

Thank you.

[Tecnoworld]

I use the recommendet TDM GCC 32, latest version from the github: https://github.com/jmeubank/tdm-gcc

Ok - I explain:
wxWidgets debug dll`s:
I can compile my program in Release-Mode (stripping symbols, Optimization etc.) and the programm runs perfect.
I can compile my program in Debug-Mode (with debug symbols, -O0 etc..) and the program runs also perfect.

wxWidgets release dll´s:
I can compile my program in Release-Mode (stripping symbols, Optimization etc.) and the programm crashs.
I can compile my program in Debug-Mode (with debug symbols, -O0 etc..) and the program crashs.

wxWidgets compiles as release, but with flag -O0:
I can compile my program in Release-Mode (stripping symbols, Optimization etc.) and the programm runs perfect.
I can compile my program in Debug-Mode (with debug symbols, -O0 etc..) and the program runs also perfect.

Never I worked with MSVC, because I come from Linux and don´t like MS
If we compile on Windows, we use Code-Blocks as IDE and the TDM-GCC.

If you explain me, how I can get such a version and how I can compile wxWidgets, I can have a try...

The crash is not only the splash screen, this is the first element what comes up.
If I take out the splash screen the program crashes later. All the frame ist empty, no elements, buttons, etc.. inside.

[doublemax]

Ok, so it has nothing to do with splashscreen.

To me this sounds just like build error of the libraries, or you're using incompatible DLLs.

Let's to back to square 1: Can you build and run the "minimal" sample that comes with wxWidgets with the same configuration that crashes your app?

[Tecnoworld]

The build of wxWidgets was done on two different PCs, one Win7, other on Win10.
Complete different installations. The result is the same as described.

Yes, the smallest samples crashes also - in this case is clear - it have nothing to do with our software.

I will make a further test - compiling wxWidgets with -O1 instead of -O0 or -O2.

I think its a problem in wxWidgets with compiler optimization (volatile or something else).

PS:
On Linux (Debian) the 64bit and the 32bit version runs fine, with the wxWidgets library as release version and the default options.
Also the build on ARMhf runs fine (Raspberry-Pi).

[PB]

I would try a different MinGW-based compiler than TDM-GCC.

It seems that current gold standard is MSYS2 package (either MSVCRT or UCRT one) such as https://packages.msys2.org/groups/mingw ... -toolchain.

There are also https://winlibs.com/ and https://github.com/niXman/mingw-builds- ... s/releases, https://nuwen.net/mingw.html has not been updated to the latest GCC.

It should be easy to use multiple MinGW-based toolchains side by side to test, just make sure there are no incompatible DLLs in PATH, where they could be picked-up by the Windows executable loader (e.g., from a different MinGW toolchain). Building wxWidgets with -jN is rather quick as long as one has decentish computer (multiple CPU cores, SSD, enough RAM).