SFML tests and examples crash with "Process returned -1073741819 (0xC0000005)"

[Ixrec]

I'm still trying to set up MinGW and Code::Blocks to use the latest SFML code from Github.  Unfortunately I haven't been able to build and run a single program linked against SFML that doesn't crash (except for two of the examples), though I've had a few that will do something simple like printing Hello World! before crashing.  I can build and run a "pure" Hello World! program from the command line without any problems.  I don't get anything resembling a stack trace so I have no idea which .dll or build setting is wrong.  I also tried downloading the SFML 2.1 libs for MinGW and linking my test program against those, but the crash didn't change.

This is essentially a follow-up to http://en.sfml-dev.org/forums/index.php?topic=16519.0 since my initial problem of CMake/MinGW not working has been resolved.  I am now able to build debug/release/static/dynamic SFML libs from the latest Github source.  The problem now is that any attempt to use them produces crashes.

To try and remove Code::Blocks from the equation (though I did set it to use exactly the same mingw32 binaries I'm building SFML with), I also tried the example programs that get built by CMake/MinGW when I set SFML_BUILD_EXAMPLES to true.  After building I copy all the .dlls from <build dir>/lib and <source dir>/extlibs/bin/x64 into examples/pong (and the other examples that are easy to test).  Then double-clicking pong.exe gets me this:
---------------------------
pong.exe - Application Error
---------------------------
The application was unable to start correctly (0xc000007b). Click OK to close the application.
---------------------------
OK   
---------------------------

Trying the x86 extlib .dlls produces an entirely different problem: The pong window frame will momentarily appear then disappear.  Nothing ever gets drawn inside the frame and there's no indication that an error or crash took place.

The "window" example works perfectly fine for some reason.  The "sound" example did work perfectly fine but for some reason after I rebuilt everything from scratch it started getting the 0xc000007b dialog box.

The "shader", "win32", "opengl" and "shader" examples fail in various ways, from making a window appear and immediately disappear to immediately crashing with the "_ has stopped working" dialog box.

Since all I've got right now is a set of random crashes and not-quite-crashes with no clues to follow up on (and yes, I googled everything, as usual none of the hits were remotely relevant), I need to ask for help again.  What do I need to do to figure out what's wrong with my setup?

[Ixrec]

So I took a step back and tried compiling a few tiny programs with g++ using only the command line, proving it really does support some C++11 stuff, and I found something odd.  sf::Shader::isAvailable() always returns false.

I get this with the SFML 2.1 dlls and the dlls I built from my local SFML git repo.  The simplest command line I've reproduced this with is:

g++ test.cpp -I"C:\Dev\SFML-2.1\include" -L"C:\Dev\SFML-2.1\lib" -lsfml-graphics -lsfml-window -lsfml-system

where test.cpp is:

#include <iostream>
#include <SFML/Graphics.hpp>

int main()
{
        std::cout << "Shaders? " << sf::Shader::isAvailable() << std::endl;
}

The output is always "Shaders? 0".

I tried commenting out the isAvailable() call in the "shader" example program, and the result was a crash plus some stderr output saying "Failed to create a shader: your system doesn't support shaders (you should test Shader::isAvailable() before trying to use the Shader class)" several times.

Is it really possible for a laptop purchased in the last 1-2 years to not support shaders? The last computer I owned never had any problems using sf::Shader.

[eXpl0it3r]

Well notebooks are often not designed for shader based applications, but in the end it really depends on your hardware.

What's your GPU? Is your graphics driver installed/uptodate?

[binary1248]

You are absolutely sure that your driver exposes the necessary OpenGL entry points that SFML looks for right?

Contrary to what people think, Microsoft doesn't like to play fair when it comes to providing out-of-the-box support for graphics APIs. Their built-in drivers always provide the latest DirectX, but still only provide the OpenGL 1.1 API. You always need to install vendor drivers if you want to use OpenGL, even if DirectX games/applications work from the start.

[Ixrec]

The only information I can find so far is that it's "Intel HD Graphics Family" and Windows claims my drivers are up to date when I click its Update button.  I'll look some more.

[Ixrec]

The Intel website says I have an Intel® HD Graphics 4400 with driver 10.18.10.3345, and that there was a newer driver 15.36.3.64.3907, but when I tried to install it I get the error "This operating system is not supported".  So I have no idea what's going on.

[wintertime]

You can try http://www.realtech-vr.com/glview/ to see which OpenGL version and extensions are supported on your computer.
I would look at the Intel page again to see if you downloaded the wrong package and there is another for your OS (or if not look through older packages if they support it).

[Ixrec]

That is cool, thanks.

After much more aimless searching and downloading I was able to install drivers that gave me OpenGL 4.2 (according to wintertime's program) and made isAvailable() return true.  The moral appears to be: When downloading drivers, start with the OEM (Dell), not the chipset manufacturer (Intel).  A few Intel pages implied it's common for OEMs to deliberately block installations of "generic" Intel drivers in favor of the OEM's supposedly more specialized drivers (though you would think they could just output an error saying "Please go to dell.com first"...), so that's probably what I was running into.

Unfortunately, now the "shader" example is crashing every time I build and run it.  Before it would run fine and simply say "shaders not available".  My command line:

C:\Dev\test>g++ Effect.hpp Shader.cpp -I"C:\Dev\SFML-2.1\include" -L"C:\Dev\SFML
-2.1\lib" -lsfml-graphics -lsfml-window -lsfml-system

The test folder contains the three required dlls, all (freshly) copied from SFML-2.1\bin.

P.S. The "pong" example builds and runs fine from the command line.  And I just accidentally discovered that it *is* possible to beat that stupid red paddle.

Edit: running the shader example with gdb shows this:

(gdb) run a
Starting program: C:\Dev\test\a.exe a
[New Thread 6104.0x19ac]
[New Thread 6104.0x1f14]
[New Thread 6104.0xf84]
[New Thread 6104.0x142c]
[New Thread 6104.0xcc4]
[New Thread 6104.0x1af0]

Program received signal SIGSEGV, Segmentation fault.
0x6fcaa9c3 in libstdc++-6!_ZNSt6localeaSERKS_ ()
   from C:\Dev\mingw32\bin\libstdc++-6.dll
(gdb) backtrace
#0  0x6fcaa9c3 in libstdc++-6!_ZNSt6localeaSERKS_ ()
   from C:\Dev\mingw32\bin\libstdc++-6.dll
#1  0x6fcac172 in libstdc++-6!_ZNSt8ios_base7_M_initEv ()
   from C:\Dev\mingw32\bin\libstdc++-6.dll
#2  0x6fcad400 in libstdc++-6!_ZNSt9basic_iosIcSt11char_traitsIcEE4initEPSt15bas
ic_streambufIcS1_E () from C:\Dev\mingw32\bin\libstdc++-6.dll
#3  0x669963ad in (anonymous namespace)::getFileContents(std::string const&, std
::vector<char, std::allocator<char> >&) ()
   from C:\Dev\test\sfml-graphics-2.dll
#4  0x669968b8 in sf::Shader::loadFromFile(std::string const&, sf::Shader::Type)
 () from C:\Dev\test\sfml-graphics-2.dll
#5  0x00000258 in ?? ()
#6  0x0040a0b5 in ?? ()
#7  0x00405236 in Effect::load (this=0x5c11dd8) at Effect.hpp:35
#8  0x00401951 in main () at Shader.cpp:289
(gdb)

Edit: I tried building in "debug mode" (ie using the -g flag and linking against the sfml-*-d libraries) and...the seg faults stopped.  The "shader" program is working perfectly for some reason.

[Ixrec]

Okay, there's definitely something unique to "release" builds about these crashes.

I am currently testing with these two command lines:

g++ -Wl,-subsystem,windows -std=c++11 -g Effect.hpp Shader.cpp -I"C:\Dev\SFML-2.1\include" -L"C:\Dev\SFML-2.1\lib" -L"C:\Dev\SFML-2.1\bin" -lsfml-audio-d -lsfml-graphics-d -lsfml-window-d -lsfml-system-d -lsndfile-1 -lopenal32 -o shader-d.exe

g++ -Wl,-subsystem,windows -std=c++11 Effect.hpp Shader.cpp -I"C:\Dev\SFML-2.1\include" -L"C:\Dev\SFML-2.1\lib" -L"C:\Dev\SFML-2.1\bin" -lsfml-audio -lsfml-graphics -lsfml-window -lsfml-system -lsndfile-1 -lopenal32 -o shader.exe

shader-d.exe runs perfectly fine. shader.exe gets the crash described above. I copied everything in SFML-2.1\bin into this test folder.  No one's been complaining about missing dlls.  The .hpp/.cpp files are also the ones from SFML-2.1\examples\shader.

I don't think I can get any more information on the crash since adding debug symbols seems to magically prevent the crash from happening.  I tried -g without the -d libs but that merely allowed me to step over but not into the SFML functions that are crashing (though it did not prevent the crash).

Edit: Probably not useful, but it looks like only the -d on sfml-graphics is needed to prevent the crash. -g and all other -d's seem to be irrelevant.

[binary1248]

Well... since gdb seems to be showing the crash happening when reading in the shader source, it might have something to do with that. It could be that something screwed up with std::locale, which is unlikely, unless there is a version mismatch somewhere. Or... , it could have something to do with the newline conversion that was merged not too long ago. I know it is a bit far-fetched, but at this point, I've seen too much weird stuff that nobody would have ever dreamed of. You can try out an older commit to rule this out, of course...

[Ixrec]

I've been testing exclusively with the SFML-2.1 MinGW download version for a while, so recent GitHub changes shouldn't be an issue.

[Juhani]

Could this be the problem?
http://en.sfml-dev.org/forums/index.php?topic=16494.msg118295#msg118295

The MinGw that comes with Code::Blocks is actually TDM-GCC, and TDM-GCC links libgcc and libstdc++ statically by default, but SFML links them dynamically, and this causes problems when memory is allocated in one module and freed in another.

So if you're using TDM-GCC you have to either compile SFML with SFML_USE_STATIC_STD_LIBS or order TDM-GCC to do dynamic linking with "-shared-libgcc" and "-shared-libstdc++"

[Ixrec]

I've been using the MinGW linked by exploiter in the previous thread ever since we got it working on my system.

C:\Dev\test>where g++
C:\Dev\mingw32\bin\g++.exe

To save you time checking the previous thread, the link was: https://sourceforge.net/projects/mingw-w64/files/Toolchains%20targetting%20Win32/Personal%20Builds/mingw-builds/4.9.1/threads-posix/dwarf/i686-4.9.1-release-posix-dwarf-rt_v3-rev1.7z/download

Since about halfway through the previous thread I stopped using CodeBlocks entirely solely to reduce the number of variables involved, so in this thread it's been all command line stuff using this one version of g++.

[Juhani]

Binaries compiled with an older GCC may be incompatible with the newer one.

I've been testing exclusively with the SFML-2.1 MinGW download version for a while, so recent GitHub changes shouldn't be an issue.

SFML binaries are compiled with GCC 4.7, and the one you're using is GCC 4.9.1.