[SOLVED] SIGILL running EmptyExample compiled under win10 on a Win7 machine

Hello,

I’m having a problem with a custom application developed with open-frameworks that I’m not able to really understand/solve by myself.
I’m able to reproduce the same problem I’m facing with my application with the openframeworks (0.9.3) EmptyExample.

I compile the EmptyExample application with msys2-mingw on a Win-10 PC.
The application (debug/release) runs fine on this machine.

When I move the application (.exe) on another machine (Win7) with all the dll prooperly installed (I have installed msys2 and set the correct path):

  • the application compiled with the debug profile works fine;
  • the application compiled with the release profile crashes with a SIGILL.

I tried to further investigate running the release application using gdb and it seems that the application is crashing for some exception in the ofFpsCounter creator (it seems to me that there is some problem in the generated .exe file that, by the way, works correcly in the Win10 machine).

GNU gdb (GDB) 7.12.1

Reading symbols from emptyExample_w10_2.exe…done.
(gdb) start
Temporary breakpoint 1 at 0x625363
Starting program: C:\of_v0.9.3_msys2\apps\myApps\emptyExample\bin\emptyExample_w
10_2.exe
[New Thread 1304.0x13c4]

Temporary breakpoint 1, 0x00625363 in main ()
(gdb) continue
Continuing.

Program received signal SIGILL, Illegal instruction.
0x005fadde in std::_Deque_base<double, std::allocator >::_M_initialize_m
ap(unsigned int) ()
(gdb) bt
#0 0x005fadde in std::_Deque_base<double, std::allocator >::_M_initiali
ze_map(unsigned int) ()
#1 0x005faf1f in std::_Deque_base<double, std::allocator >::_Deque_base
() ()
#2 0x00419437 in ofFpsCounter::ofFpsCounter(double) ()
#3 0x00404d76 in ofCoreEvents::ofCoreEvents() ()
#4 0x0042ab5b in ofAppGLFWWindow::ofAppGLFWWindow() ()
#5 0x00403b58 in ofMainLoop::createWindow(ofWindowSettings const&) ()
#6 0x00401cab in ofCreateWindow(ofWindowSettings const&) ()
#7 0x0040274c in ofSetupOpenGL(int, int, ofWindowMode) ()
#8 0x0062538a in main ()

Am i missing something? Is there any option I can specify to mingw to generate a .exe that is backward compatible with previous version of windows?

Any idea? Thank you
Andrea

PS: I tried to compile the same EmptyExample application on the Win7 machine and the generated .exe works fine in windows 10 (both release/debug)

I’ve investigated a little more this issue.

It happens only when the target machine is running W7E (embedded); when the target machine is running W7 both the release and the debug application compiled in W10 works fine.
I can replicate the same issue when I compile the application in W7 and try to run it under W7E.

The weird thing about this issue is that, with a previous version of the application (compiled in WIn10, with of8.4 and code-block mingw) the application works without any issue on W7, W7E and W10 OS.

I had to move the application to the new OF (so I need to change the develop environment from CB to Qtcreator) to take advantage from the OF_PIXELS_NATIVE feature.

I am now trying to compile the application with VS to see if I can bypass this issue.

sigill usually means that you are trying to use an instruction that can’t be run on that cpu, if you are compiling on one machine and running then in some embedded architecture the optimizations of the compiler are probably creating an incompatible binary for the seconds machine.

if the debug binary works it’s surely because of that.

compiling in vs probably solves the problem but otherwise in the project qbs in of.cxxFlags and of.cflags you can try to add:

of.cFlags: [ "-mtune=..." ]

where the … would be the correct target architecture for optimizations which you can check here:

https://gcc.gnu.org/onlinedocs/gcc-4.5.3/gcc/i386-and-x86_002d64-Options.html

1 Like

Thank you Arturo for the support.

By forcing the -mtune -march=corei7 the problem has been solved.

With the older version of the develop environment (of8.4 and CB) the problem did not appear because in code::block you had to explicitly force the -mtune -march options, while with the new OF these two cflags are enabled by default in the config.msys2.default.mk.