Segmentation fault with mingw-w64 32-bit release binaries

[podsvirov]

I get a segmentation error when I use 32-bit binaries in the Release configuration, but everything is fine in the Debug configuration.

For renderarea example from SoQt I get:

Reading symbols from renderarea.exe...
(gdb) run
Starting program: renderarea.exe
[New Thread 7596.0x2484]
[New Thread 7596.0x350]
[New Thread 7596.0x176c]
[New Thread 7596.0x2674]
[New Thread 7596.0x197c]
[New Thread 7596.0x228c]
[New Thread 7596.0x1ec0]
[New Thread 7596.0x2754]
warning: mincore\com\oleaut32\dispatch\ups.cpp(2122)\OLEAUT32.dll!773B245F: (caller: 773B3D7F) ReturnHr(1) tid(2798) 8002801D
[New Thread 7596.0x1b38]
[New Thread 7596.0x1434]
[New Thread 7596.0x1ad8]
[New Thread 7596.0x126c]
[New Thread 7596.0x1f94]

Thread 1 received signal SIGSEGV, Segmentation fault.
0x0061fe63 in ?? ()
(gdb)

I also don't have any problems with 64-bit binaries.

I am asking for help in debugging the incident.

[VolkerEnderlein]

Thanks for notifying us about this issue. I built coin and soqt under msys2 32bit and could reproduce the issue. As I am not very knowledged with gdb I was first checking the link time dependencies of renderarea.exe, libSoQtd.dll and libCoin-80d.dll by using ntldd as I was supposing a runtime libraries mismatch from your report. renderarea.exe correctly links to the debug versions of Coin and SoQt. But when checking libSoQtd.dll I noticed, that it links to the release version of Qt5 although a debug version has been installed. Can you attach the output of ntldd libSoQtd.dll, to make sure, SoQt is properly built in debug mode?

[podsvirov]

@VolkerEnderlein I have no problems when Coin built in debug mode. Segmentation fault actual only for 32-bit built in release mode. The python-pivy scripts also work when build coin package in debug mode without debug postfix. You may be surprised when you see the filenames of the qt5-debug package.

[VolkerEnderlein]

@podsvirov Thanks. I was getting it wrong that the debug version failed and you're right I was also very much intimidated from the filenames of the qt5-debug package. :) How do I link properly with the debug version of Qt5? Does CMake handle that or do I need to install some additional stuff? Until now I installed Qt5 and Qt5-debug by calling pacman -S mingw-w64-i686-qt5-debug mingw-w64-i686-qt5 The debug build succeeded, but I could not run any program built so far. Edit: Got it running in debug and and see the segfault in renderarea.exe in release mode.

[VolkerEnderlein]

@podsvirov First update on the issue: I had crashes in all test programs when building current Coin version using MinGW. CMake supports the build type RelWithDebugInfo out of the box and I built Coin/SoQt and the test programs for 32bit using this. I was able to debug the renderarea.exe and embeddedexaminer.exe with gdb but the results do not make much sense to me as they vary from build to build. Sometimes I get an Illegal instruction error, other times a Segmentation fault error. Most times the programs crash when leaving a function scope or when doing sychronisation in SoDB::readunlock() function while traversing the scene graph. One time I was crashing in strcmp! I also built Coin with Autotools (configure) and SoQt with CMake (as SoQt Autotools scripts do not support Qt5) and the program crashed. Even enabling COIN_THREADSAFE on the Coin library did not succeed. Next I will try to build Coin/SoQt with an older gcc (mingw-8.1 or mingw-7.3) to check whether it depends on the compiler.

[podsvirov]

@VolkerEnderlein thanks for your efforts in researching this issue.

[mati865]

Gdb sometimes isn't able to get useful results on Windows, in that cases you can resort to lldb, windbg or winedbg (on Linux).

[VolkerEnderlein]

I checked mingw73 and mingw81: all were crashing in release mode for the CMake and Autotools build. Finally, after trying many other things I got the programs to run in Release mode, too. It seems to be an issue with optimization. When lowering the optimization level from -O2 to -O1 or -O0 I got the program running. Will further need to find out what causes this, as the 32bit versions in Ubuntu 16.04 (using GCC 5), 18.04 (using GCC 7), and Visual Studio run flawlessly and did not crash.

[VolkerEnderlein]

@podsvirov So I examined the optimization issue somewhat further. It could be reduced to the -fipa-icf option of GCC that is added in addition to the options from -O1 when -O2 option is set (it occurred only with MinGW compilers and 32bit). However, the application does not segfault, if I add -fipa-icf to the lib compiled with -O0. Adding all other options for -O2 (one by one and and all together) to -O1 does not lead to the faulty behaviour. See here for a explanation of the differences between -O0, -O1, and -O2 and here about what the optimization it is doing. As a workaround for the crash I would suggest adding -DCMAKE_CXX_FLAGS=-fno-ipa-icf to the cmake build command line for MinGW 32bit until this issue is fixed. I tested this and the renderarea.exe application behaves as expected.

So how would one proceed to find the code that causes this segfault?

[mati865]

So how would one proceed to find the code that causes this segfault?

On Linux one would typically use C-Reduce to get minimal reproducer.

[VolkerEnderlein]

@mati865 Thanks for the pointer. I will check if it can be used with MinGW too.

[VolkerEnderlein]

Ok, further update on the issue. It all boils down to the combination of the -fomit-frame-pointer and -fipa-icf optimization options. Adding both of them in addition to -O0 makes the program crash with segfault, adding either one of them makes the program run. Weird.

[podsvirov]

@VolkerEnderlein, your suggestion to add a compile flag via -DCMAKE_CXX_FLAGS=-fno-ipa-icf is applied in the msys2/MINGW-packages#7908. Rebuilt packages are available in the pacman repository with version 4.0.0-3.