Cannot Get 2.2 to Work - Crashes on Draw

[StephenGilbert]

Hello,

I'm a teacher at a community college in California and I've been having my students work with SFML in their C++ I class. They have been using SFML 2.0 with both MingW and with Visual Studio. Today I tried to upgrade to 2.2 and was unsuccessful. Here are the particulars:

1. Using sample "green dot" starter from the getting started tutorial
2. Code compile and links and crashes on draw()

Operating System is Window 7-64 bit.
Video card is ATI Radeon HD 3470 (computer configured by IT)

Downloaded and installed prebuilt binaries for VS2012 for both 2.1 and 2.2.
  - Works for SFML 2.1, crashes on SFML 2.2
Downloaded and installed prebuilt binaries for VS2013 for 2.2:
  - crashes at same place.
Used CMake to build libraries for 2.0, 2.1 and 2.2 for MinGW 4.8.1 (from MingW.org).
  - 2.0 works, 2.1 works, 2.2 crashes on draw
Used CMake to build libraries for MingW64-4.82
  - 2.2 crashes on draw.

In Visual Studio I can get a stack trace which is shown below. Since I don't seem to have debugging symbols (although I am using the debugging version of the library), I can't tell what code is actually executing in the dll.

    00000000()   Unknown
    [Frames below may be incorrect and/or missing]   
    sfml-graphics-d-2.dll!50be0762()   Unknown
    sfml-graphics-d-2.dll!50be02e2()   Unknown
    sfml-graphics-d-2.dll!50bdfa86()   Unknown
    sfml-graphics-d-2.dll!50c092bd()   Unknown
    sfml-graphics-d-2.dll!50bdfa03()   Unknown
    sfml-graphics-d-2.dll!50bfedf8()   Unknown
    sfml-graphics-d-2.dll!50bdfa03()   Unknown
>   SFML-2.2-VS2012.exe!main() Line 19   C++
    SFML-2.2-VS2012.exe!_WinMain@16()   Unknown
    SFML-2.2-VS2012.exe!__tmainCRTStartup() Line 528   C
    SFML-2.2-VS2012.exe!WinMainCRTStartup() Line 377   C
    kernel32.dll!76df33aa()   Unknown
    ntdll.dll!77d59ef2()   Unknown
    ntdll.dll!77d59ec5()   Unknown

This is the first help request that I've submitted, so I'm not sure if I'm doing something incorrectly.

Thanks for your consideration.

--Steve

[StephenGilbert]

Sorry. I forgot to add the list of DLLs that were loaded. All of them look like they come from the system folder.

Loaded 'C:\Users\sgilbert\Desktop\vs2012\SFML-2.1\Debug\SFML-2.2-VS2012.exe'. Symbols loaded.
Loaded 'C:\Windows\SysWOW64\ntdll.dll'.
Loaded 'C:\Windows\SysWOW64\kernel32.dll'.
Loaded 'C:\Windows\SysWOW64\KernelBase.dll'.
Loaded 'C:\Users\sgilbert\Desktop\vs2012\SFML-2.1\Debug\sfml-graphics-d-2.dll'.
Loaded 'C:\Users\sgilbert\Desktop\vs2012\SFML-2.1\Debug\sfml-window-d-2.dll'.
Loaded 'C:\Users\sgilbert\Desktop\vs2012\SFML-2.1\Debug\sfml-system-d-2.dll'.
Loaded 'C:\Windows\SysWOW64\winmm.dll'.
Loaded 'C:\Windows\SysWOW64\msvcrt.dll'.
Loaded 'C:\Windows\SysWOW64\user32.dll'.
Loaded 'C:\Windows\SysWOW64\gdi32.dll'.
Loaded 'C:\Windows\SysWOW64\lpk.dll'.
Loaded 'C:\Windows\SysWOW64\usp10.dll'.
Loaded 'C:\Windows\SysWOW64\advapi32.dll'.
Loaded 'C:\Windows\SysWOW64\sechost.dll'.
Loaded 'C:\Windows\SysWOW64\rpcrt4.dll'.
Loaded 'C:\Windows\SysWOW64\sspicli.dll'.
Loaded 'C:\Windows\SysWOW64\cryptbase.dll'.
Loaded 'C:\Windows\SysWOW64\msvcr110d.dll'. Symbols loaded.
Loaded 'C:\Windows\SysWOW64\msvcp110d.dll'. Symbols loaded.
Loaded 'C:\Windows\SysWOW64\opengl32.dll'.
Loaded 'C:\Windows\SysWOW64\glu32.dll'.
Loaded 'C:\Windows\SysWOW64\ddraw.dll'.
Loaded 'C:\Windows\SysWOW64\dciman32.dll'.
Loaded 'C:\Windows\SysWOW64\setupapi.dll'.
Loaded 'C:\Windows\SysWOW64\cfgmgr32.dll'.
Loaded 'C:\Windows\SysWOW64\oleaut32.dll'.
Loaded 'C:\Windows\SysWOW64\ole32.dll'.
Loaded 'C:\Windows\SysWOW64\devobj.dll'.
Loaded 'C:\Windows\SysWOW64\dwmapi.dll'.
Loaded 'C:\Windows\SysWOW64\imm32.dll'.
Loaded 'C:\Windows\SysWOW64\msctf.dll'.
Loaded 'C:\PROGRA~2\Sophos\SOPHOS~1\SOPHOS~1.DLL'.
Loaded 'C:\Windows\SysWOW64\psapi.dll'.
Loaded 'C:\Windows\SysWOW64\uxtheme.dll'.
Loaded 'C:\Windows\SysWOW64\dinput.dll'.
Loaded 'C:\Windows\SysWOW64\hid.dll'.
Loaded 'C:\Windows\SysWOW64\wintrust.dll'.
Loaded 'C:\Windows\SysWOW64\crypt32.dll'.
Loaded 'C:\Windows\SysWOW64\msasn1.dll'.
Loaded 'C:\Windows\SysWOW64\ole32.dll'.
Unloaded 'C:\Windows\SysWOW64\ole32.dll'
First-chance exception at 0x00000000 in SFML-2.2-VS2012.exe: 0xC0000005: Access violation executing location 0x00000000.
Unhandled exception at 0x7534C9F1 in SFML-2.2-VS2012.exe: 0xC0000005: Access violation executing location 0x00000000.
The program '[7816] SFML-2.2-VS2012.exe' has exited with code 0 (0x0).

--Steve

[eXpl0it3r]

Sounds like you're mixing compiler versions. For C++ libraries it's important that you use the same exact compiler as the library was built with.
If you use Visual Studio 2012, you can't use Visual Studio 2013 binaries. If you use MinGW the pre-built libraries need to have been compiled with the same compiler.
Equally important is, that you don't mix debug and release modes. If you are in debug mode, you need to link the debug libraries (with the -d suffix) and if you are in release mode, you need to link the release libraries (without a -d suffix).

The MinGW 4.9.2 DW2 package was built with this compiler.
The 32-bit TDM versions were built with the compilers that ship with Code::Blocks.

Personally I really recommend to build SFML on your own, just to make sure it works with your setup.
Then if you have issue with one setup, it's best to focus and find out what's the issue, instead of trying out every other possibility.

For the ones that fail, I recommend you provide verbose build command, so we can see if you've used all the right settings.

[StephenGilbert]

Thanks for your reply. I'm pretty sure I wasn't mixing compiler versions. Each was downloaded into its own folder. I only tested the debug versions, and each folder had only the three runtime DLLs needed, again, each from the correct download folder.

For the three MingW compilers, I didn't use the prebuilt binaries but built the libraries myself.

I'll grab a verbose build command when I go into work in the morning and post it then.

Thanks again for your help.

Steve

[Jesper Juhl]

Even if you are not mixing up compiler versions you might still be mixing up debug/release builds of the lib/your application. Worth checking.
Also, old graphics drivers are a common source of issues, so making sure they are up-to-date is worth checking.

[StephenGilbert]

Thanks very much. Yes I did check debug/release builds and had those both correct. (I'm actually only checking the debug build; all the libraries with the -d in the name; same with the DLLs.)

It looks like you are on to something with the driver problem, though. I just copied the offending executables to a different lab with newer computers and they do not crash. The ATI driver difference happened somewhere between 8.56->8.64.

Thanks again for your help tracking down this problem. For the next semester, I'll just make sure all of my students know to use SFML 2.1 which seems to work on all the computers across campus. In the meantime, I'll put in an IT workorder to try and get the video-cards updated. I'm not very optimistic about that happening.

--Steve

[binary1248]

Not necessary at all, but just for future reference, if you feel like it: Can you debug the library on that specific machine and see where exactly it crashes? A lot of stuff happens inside draw(), so it is kind of hard to guess what could be the cause without any hints. Since you mentioned that you were already able to build the libraries yourself successfully, building them in the debug configuration and running the examples in a debugger shouldn't be too much effort for you I hope.

[StephenGilbert]

Hello,

Sure; I just built a new version of the library with Visual Studio 2013 and stepped through the simplest ("green dot") program. The program crashes on line 445 of RenderTarget.cpp, specifically, this line:
 glCheck(GLEXT_glBlendEquation(equationToGlConstant(mode.colorEquation)));

In this case the mode.colorEquation is Add(0x0000000)

--Steve

[binary1248]

Unfortunately "new version" doesn't really tell us much, unless you simply meant that you rebuilt the same version with debugging symbols this time.

As I already somewhat expected from the list of loaded DLLs, since no ATI .dll is loaded, it probably means that either no ICD is installed or if it is, then it's not operating correctly on the system in question. It isn't a matter of replacing a card, just installing the proper driver and making sure it actually works, which is done in just a matter of minutes even by a layperson. And if your IT people assert that the driver was installed correctly, then ask them how they tested it, because not many people know that even in the absence of an ICD, Windows can still run DirectX games/applications because it ships a functional DirectX driver and a non-functional OpenGL driver by default, politics as usual.

If there is no ICD installed, Windows will just provide OpenGL 1.1 functionality through a Direct3D wrapper, which is probably what is happening to you. glBlendEquation is an OpenGL 1.2 function, so trying to call it when it is not provided will simply crash the application. SFML made no checks for this in the past, but recently a patch was pushed that at least emits a warning to the console if a pre-1.2 OpenGL context is created which leads to required function pointers not being loaded.

You can check the version of the context that gets created by inspecting the return value of window.getSettings(). It is more than likely to be 1.1. As long as you don't try to draw anything in this case, nothing should crash on you, but that is also pretty much all you will be able to do on those systems.

We live in the 21st century, installing the proper drivers should be a non-issue. Obviously Microsoft couldn't care less if you aren't able to run OpenGL powered applications, so your IT people would be doing them a favour by putting up with the current state of the system in question. If you explain this situation to them and they tell you to use DirectX instead, do me a favour and kick them for me... kick them really hard, multiple times if you feel it is necessary.

[StephenGilbert]

Thank you. I feel a little foolish because I have no idea what an ICD is. All Google will tell me is an International Classification of Disease, and I'm sure that's not right.

In any event, the machine(s) in question do indeed return 1.1 (majorVersion, minorVersion) with getSettings(). Thanks for letting me know.

As I mentioned, I teach at a Community College so getting something like drivers fixed is not that easy. Our computers are bought on a State contract, installed by Dell and pretty much locked down so that nothing can be changed without doing a change to the base image and a reimage across campus. It's usually better if I can work around that. Since 2.1 doesn't seem to require Open-GL 2.1 (at least in the apps I've built so far), I can keep my class going for the next semester.

--Steve

[binary1248]

Thank you. I feel a little foolish because I have no idea what an ICD is. All Google will tell me is an International Classification of Disease, and I'm sure that's not right.

Wikipedia might help sometimes: Installable Client device driver, in Microsoft Windows

As I mentioned, I teach at a Community College so getting something like drivers fixed is not that easy. Our computers are bought on a State contract, installed by Dell and pretty much locked down so that nothing can be changed without doing a change to the base image and a reimage across campus. It's usually better if I can work around that.

I know that government run institutions get pretty crappy treatment a lot, but if you really have a contract with Dell, then the least they can do is make sure their customers can actually use the hardware they are selling. These are desktop machines and not laptops, so it is even less tolerable that essential software such as drivers aren't available on them from the get go. Maybe they should think about giving these kinds of things more effort instead of making sure Sophos is installed.

Since 2.1 doesn't seem to require Open-GL 2.1 (at least in the apps I've built so far), I can keep my class going for the next semester.

Be aware that you will be limiting yourself substantially. Although Microsoft claims that the OpenGL 1.1 implementation basically wraps Direct3D, there is nothing preventing them from providing a pure software rendering implementation as well. They have proven many times in the past that they are willing to go to great lengths to make OpenGL as unattractive as possible on Windows. In addition to that, you won't have access to shaders, you will probably be limited to very small texture sizes, power of two textures, the "slow" RenderTexture implementation, among other things. I personally wouldn't put up with this, considering it takes the relevant people literally minutes of their time to rectify the problem. But, I guess it's not for me to decide whether it is worth the effort.

It might be worth considering making glBlendEquation support optional again, like it was pre-BlendModes just so that people in your situation don't have to live with old versions forever because of miserable IT support.

[Jesper Juhl]

It might be worth considering making glBlendEquation support optional again, like it was pre-BlendModes just so that people in your situation don't have to live with old versions forever because of miserable IT support.

I can see what you are saying, but seriously, it's 2015 and OpenGL < 1.2 (and even that) is dead as a doornail. Don't cater to it, move forward - would be my opinion.
Sure, there's value in supporting legacy systems, but it shouldn't hold you back - legacy users can use legacy SFML versions.
Just my $0.02.

[binary1248]

Actually, I've been reviewing the RenderTarget code again, and I am starting to consider it a "bug" that we don't check for the presence of glBlendEquation before calling it. Sure we can blame the user for not providing us with a 1.2 context to use, but simply crashing in that case is also not a friendly thing to do. In fact, disabling that specific call when it isn't available wouldn't even prevent people from using alpha blending since the default state it is in is enough for most people to work with (and corresponds to the default BlendMode that is set in sf::RenderStates).

I'll try and see if I can come up with a fix for this. It really doesn't need to be this way, and it isn't even a question of "holding us back". It's just a question of providing a sane fallback and making the behaviour of the library more robust against such scenarios. There is never an excuse for causing a crash, even if it is intentional.

[binary1248]

And... done. After just an hour's worth of work.

Feel free to test the branch out Steve. If it works out for you, it might be possible for this to get in for 2.3, so that community colleges all over the country won't have to shy away from using SFML any more.