-
Hi, I'm currently working on a small game engine using sfml.
I've recently had users with intel graphics cards building reporting that they were getting corrupt images when loading image files. Sadly, I couldn't reproduce the problems with my graphics card.
In the end, I had to place a
pRenderWindow->setActive( true );
before each and every texture and view manipulation function
and a glFlush() right afterwards.
Users have been telling me since that they aren't getting the problems,
but I feel like this is a terrible ad-hoc hack just waiting to hit me in the face again any time.
Are there any plans to improve context management in sfml,
or is this the only way to prevent these weird bugs?
The attached image is a screenshot sent to me by one of my users -
there's this weird mixing of textures going on despite having loaded single image files.
I am not running the executable in a multithreaded fashion and all images loaded are done through
the normal .loadFromFile() function.
-
It would help to know what kind of hardware your users are running and most importantly whether they are using current drivers. Many similar problems that have popped up in the past were solved by updating drivers, especially for Intel chips since not everything is 100% hardware accelerated. Most users who use the integrated graphics more often than not don't bother updating their graphics driver because 1. drivers are released less frequently than those for discrete GPUs and 2. they are more of a hassle to get hold of because there are multiple obscure sources to get them from.
Also, SFML is trying to cut down on the number of workarounds needed for things that are broken that aren't really SFML's fault and work for the majority of others. Often these workarounds have a negative impact on those who don't experience the problem, so the reliable solution is to fix the problem upstream (i.e. driver maintainer). If you can reproduce this in a minimal example using the latest Intel drivers then it is easy to reconstruct a minimal OpenGL example to submit to Intel so they can reproduce the problem and hopefully fix it in their next release. If nobody cares to file bug reports you really can't expect anything to get fixed.
-
Hi, I've asked for some additional info from my users previously reporting bugs. It seems they're using:
Intel HD Graphics 4400
Intel HD Graphics 4000
They've replied back to me saying that they'd all updated to the latest drivers they could get.
I can understand wanting to reduce the number of workarounds to serve the minority with issues, but is there no underlying method to address or improve them all?
I've had roughly 20 people during the last month email me with the problem (back before the fix)
- while they may be a minority in terms of a larger group, I definitely don't feel that they should be considered lightly;
especially if something as simple as adding a 'pRenderWindow->setActive(true)' before all texture/view/window manipulation functions cleaned out most issues.
I'm not sure how effective this would be, but would it be possible to add something along the lines of a 'normal' mode and 'safe' mode trigger for context management? 'normal' mode would run without the workarounds pertaining to minority drivers, while 'safe' mode would be as cautious as possible to suit as many drivers as possible.
-
What about... come up with a simple (100-200 lines) self contained example using SFML exclusively (without any built-in workarounds or modifications) that breaks on said chips? It can't be too hard from what you describe. I can build a simple executable using win32 and GL and if that breaks as well on your users' systems, you can file a report at Intel. If they can reproduce it using the latest drivers, then I'm sure they will acknowledge the bug and fix it for the next driver release.
If you can't reproduce it in a minimal example, then you must understand that we have to assume that the error is specific to your code and making any changes to SFML to alleviate problems caused exclusively by your code isn't such a good idea.
Also, judging by your description of the fix, it sounds like either the problem is really an easily reproducible bug (context related) or that something else is messing with the context that makes it look like it is context related but actually not. Intel is notorious for not being as nice to work with as Nvidia or AMD, but I've never heard of a case that was this bad...
Don't get me wrong, I want to help you, but it is better if we find clean thought-out solutions rather than just "hackish workarounds" that are the result of trial and error. The first step is to reproduce the problem in an isolated environment so we can rule out anything that really isn't related to the problem, and that step is up to you. Just throw a few SFML objects together to make it look like what your application does and see what happens. Even if the example doesn't turn out to be that short, we'll help you shorten it.
-
Thanks for the reply,
I managed to get a hold of a laptop pc with an intel hd graphics 4000 graphic card.
#include <SFML\Graphics.hpp>
#include <memory>
#include <array>
std::unique_ptr<sf::RenderWindow> pRenderWindow;
using ImageVec = std::array<std::shared_ptr<sf::Texture>, 3>;
int main()
{
using namespace std;
pRenderWindow.reset( new sf::RenderWindow( sf::VideoMode( 800, 600 ), "sfml test", sf::Style::Titlebar | sf::Style::Close ) );
ImageVec imageVec;
while ( pRenderWindow->isOpen() )
{
// check all the window's events that were triggered since the last iteration of the loop
sf::Event event;
while ( pRenderWindow->pollEvent( event ) )
{
switch ( event.type )
{
case sf::Event::Closed:
imageVec.empty();
pRenderWindow->close();
pRenderWindow.reset();
return 0;
case sf::Event::KeyPressed:
switch ( event.key.code )
{
case sf::Keyboard::Num4:
{
ImageVec imageVec_ = { make_shared<sf::Texture>(), make_shared<sf::Texture>(), make_shared<sf::Texture>() };
imageVec = imageVec_;
for ( auto& pBtnImage : imageVec )
{
pBtnImage = make_shared<sf::Texture>();
pBtnImage->create( 100, 100 );
}
}
}
}
pRenderWindow->clear( sf::Color( 255, 255, 255, 255 ) );
pRenderWindow->display();
}
}
return 0;
}
Running the code and hitting on the keyboard 4 key a couple of times and then closing the window will produce the following error: (with just different memory addresses)
First-chance exception at 0x7797E3BE (ntdll.dll) in sfml_test.exe: 0xC0000005: Access violation reading location 0x95159966.
First-chance exception at 0x7797E3BE (ntdll.dll) in sfml_test.exe: 0xC0000005: Access violation reading location 0x95159966.
First-chance exception at 0x7797E3BE (ntdll.dll) in sfml_test.exe: 0xC0000005: Access violation reading location 0x95159966.
Tell me if there is anything wrong with the code itself - it works completely fine on my pc with the ATI graphics card; the problem only occurs on the one with the Intel card.
-
That example still seems unnecessarily complex. Are the unique_ptr and shared_ptrs really necessary to reproduce the problem? The way you use the unique_ptr, you might as well just create an instance of the RenderWindow directly. Also, why create a temporary ImageVec only to assign it to another in the following line? Is that required to reproduce the problem?
Try to get rid of the <memory> related objects and see if the problem is still reproducible. Also, does this have to do with the original problem you mentioned? Or is it just a crash you ran into while trying to reproduce the original problem?
Also, just in case you forgot, make sure the driver is up to date ;). The latest one (15.33.22.3621) was released on 5/21/2014.
P.S. You might want to use code=cpp tags instead of a quote the next time you post code.
-
Thanks for the feedback :)
#include <SFML\Graphics.hpp>
#include <array>
using ImageVec2 = std::array<sf::Texture, 3>;
int main()
{
using namespace std;
sf::RenderWindow renderWindow( sf::VideoMode( 800, 600 ), "sfml test", sf::Style::Titlebar | sf::Style::Close );
ImageVec2 imageVec;
while ( renderWindow.isOpen() )
{
// check all the window's events that were triggered since the last iteration of the loop
sf::Event event;
while ( renderWindow.pollEvent( event ) )
{
switch ( event.type )
{
case sf::Event::Closed:
imageVec.empty();
renderWindow.close();
return 0;
case sf::Event::KeyPressed:
switch ( event.key.code )
{
case sf::Keyboard::Num4:
{
for ( auto& pBtnImage : imageVec )
{
pBtnImage.create( 100, 100 );
}
}
}
}
renderWindow.clear( sf::Color( 255, 255, 255, 255 ) );
renderWindow.display();
}
}
return 0;
}
The same memory address errors occur after pressing on the 4 key a few times and closing the window.
The crash is something I noticed while trying to reproduce the original issue.
The code that loads the textures in the original issue and the above code are closely related in my engine code - fixing this might fix the texture corruption issue that users have reported to me about.
I notice visual studio breaking me at times on
`pBtnImage.create( 100, 100 );` in the original engine code (the same ntdll.dll issue), this might be the source of trouble in the minimized code here as well.
-
So does the following code also (immediately) crash?
#include <SFML\Graphics.hpp>
int main()
{
sf::RenderWindow renderWindow( sf::VideoMode( 800, 600 ), "sfml test", sf::Style::Titlebar | sf::Style::Close );
renderWindow.clear( sf::Color( 255, 255, 255, 255 ) );
renderWindow.display();
sf::Texture imageVec[3];
for ( int i = 0; i < 3; ++i )
{
imageVec[i].create( 100, 100 );
}
renderWindow.clear( sf::Color( 255, 255, 255, 255 ) );
renderWindow.display();
renderWindow.close();
}
-
So does the following code also (immediately) crash?
#include <SFML\Graphics.hpp>
int main()
{
sf::RenderWindow renderWindow( sf::VideoMode( 800, 600 ), "sfml test", sf::Style::Titlebar | sf::Style::Close );
renderWindow.clear( sf::Color( 255, 255, 255, 255 ) );
renderWindow.display();
sf::Texture imageVec[3];
for ( int i = 0; i < 3; ++i )
{
imageVec[i].create( 100, 100 );
}
renderWindow.clear( sf::Color( 255, 255, 255, 255 ) );
renderWindow.display();
renderWindow.close();
}
I've just checked the code - it crashes right away.
-
I've found something interesting.
The following code crashes: (the same ntdll.dll access violation errors)
#include <SFML\Graphics.hpp>
int main()
{
sf::RenderWindow renderWindow( sf::VideoMode( 800, 600 ), "sfml test", sf::Style::Titlebar | sf::Style::Close );
renderWindow.clear( sf::Color( 255, 255, 255, 255 ) );
renderWindow.display();
sf::Texture texture;
texture.loadFromFile( "btn_sel.png" );
sf::Sprite sprite;
sprite.setTexture( texture );
renderWindow.clear( sf::Color( 255, 255, 255, 255 ) );
renderWindow.display();
renderWindow.close();
return 0;
}
while the following code doesn't:
#include <SFML\Graphics.hpp>
int main()
{
sf::RenderWindow renderWindow( sf::VideoMode( 800, 600 ), "sfml test", sf::Style::Titlebar | sf::Style::Close );
renderWindow.clear( sf::Color( 255, 255, 255, 255 ) );
renderWindow.display();
sf::Texture texture;
texture.loadFromFile( "btn_sel.png" );
sf::Sprite sprite;
sprite.setTexture( texture );
renderWindow.clear( sf::Color( 255, 255, 255, 255 ) );
renderWindow.draw( sprite );
renderWindow.display();
renderWindow.close();
return 0;
}
The only difference is one `renderWindow.draw( sprite );` call.
(the same occurs if I replace the texture.loadFromFile function with texture.create( 100, 100 ); )
I don't know if this helps track down something.
-
Does this code crash?
#include <SFML\Graphics.hpp>
int main()
{
sf::RenderWindow renderWindow( sf::VideoMode( 800, 600 ), "sfml test", sf::Style::Titlebar | sf::Style::Close );
sf::Texture texture;
texture.create( 100, 100 );
renderWindow.display();
return 0;
}
Also, what driver version is installed on the machine? Maybe this is a known bug.
-
Does this code crash?
#include <SFML\Graphics.hpp>
int main()
{
sf::RenderWindow renderWindow( sf::VideoMode( 800, 600 ), "sfml test", sf::Style::Titlebar | sf::Style::Close );
sf::Texture texture;
texture.create( 100, 100 );
renderWindow.display();
return 0;
}
Also, what driver version is installed on the machine? Maybe this is a known bug.
The code doesn't crash - it doesn't crash if I change 'texture.create( 100, 100 );' to a 'texture.loadFromFile()' either.
The driver version on this laptop is 8.771.1.0
This code also works:
#include <SFML\Graphics.hpp>
int main()
{
sf::RenderWindow renderWindow( sf::VideoMode( 800, 600 ), "sfml test", sf::Style::Titlebar | sf::Style::Close );
renderWindow.clear( sf::Color( 255, 255, 255, 255 ) );
renderWindow.display();
sf::Texture texture;
texture.create( 100, 100 );
renderWindow.clear( sf::Color( 255, 255, 255, 255 ) );
renderWindow.display();
//renderWindow.close();
return 0;
}
It seems the moment I uncomment the 'renderWindow.close()', the code crashes again.
The same happens if I add a 'renderWindow.close()' to the last part of the code you gave.
-
From what I've seen, 8.771.1.0 means you have a HP notebook with dual AMD/Intel graphics? That driver package is 4 years old and I'm sure Intel has fixed a ton of bugs since then. Is there no way to update the drivers? HP is known to not release driver updates for their products as soon as a couple of years after release. You could try heading to the Intel download site (https://downloadcenter.intel.com/SearchResult.aspx?lang=eng&ProductFamily=Graphics&ProductLine=Laptop+graphics+drivers&ProductProduct=3rd+Generation+Intel%C2%AE+Core%E2%84%A2+Processors+with+Intel%C2%AE+HD+Graphics+4000&ProdId=3712&LineId=1101&FamilyId=39) and installing the "appropriate" driver and hope it doesn't break your AMD graphics.
From the code that has been posted so far, this looks more and more like a driver bug. There is no systematic way to explain why renderWindow.close() prevents the crash since it is called when the RenderWindow goes out of scope at the end of main() as well. So whether renderWindow.close() is present or not, the code that is executed is almost identical and really shouldn't be able to have an effect on the crash and yet it does...
-
For me with an i5 4200u (Intel HD 4400) with the latest driver (10.18.10.3621) I have no problems with the code, also with the "GPU" Geforce gt740m I get no error.
Btw I have also an HP laptop and I does always use the "normal" drivers from the intel site and the Nividia site. So from my experience it's not a problem.
AlexAUT
-
From what I've seen, 8.771.1.0 means you have a HP notebook with dual AMD/Intel graphics? That driver package is 4 years old and I'm sure Intel has fixed a ton of bugs since then. Is there no way to update the drivers? HP is known to not release driver updates for their products as soon as a couple of years after release. You could try heading to the Intel download site (https://downloadcenter.intel.com/SearchResult.aspx?lang=eng&ProductFamily=Graphics&ProductLine=Laptop+graphics+drivers&ProductProduct=3rd+Generation+Intel%C2%AE+Core%E2%84%A2+Processors+with+Intel%C2%AE+HD+Graphics+4000&ProdId=3712&LineId=1101&FamilyId=39) and installing the "appropriate" driver and hope it doesn't break your AMD graphics.
From the code that has been posted so far, this looks more and more like a driver bug. There is no systematic way to explain why renderWindow.close() prevents the crash since it is called when the RenderWindow goes out of scope at the end of main() as well. So whether renderWindow.close() is present or not, the code that is executed is almost identical and really shouldn't be able to have an effect on the crash and yet it does...
You're right- the test machine I'm using is a HP notebook with dual AMD/Intel graphics. This is the only machine I have that seems to model the problems that my users are getting though - hence updating the drivers currently isn't an option. Telling my users with laptops to update their drivers hoping that it doesn't break something on theirs, isn't really an option either..;
For me with an i5 4200u (Intel HD 4400) with the latest driver (10.18.10.3621) I have no problems with the code, also with the "GPU" Geforce gt740m I get no error.
Great to know you're here to help AlexAUT - it's good to know there are other people to help check the issue.
I've noticed that the following code works without any access violation issues - any thoughts?
'renderWindow.close();' doesn't seem to cause an issue here.
The only real thing I've changed here is in using a pointer to a texture instead.
#include <SFML\Graphics.hpp>
sf::Texture* texture;
int main()
{
sf::RenderWindow renderWindow( sf::VideoMode( 800, 600 ), "sfml test", sf::Style::Titlebar | sf::Style::Close );
texture = new sf::Texture();
texture->create( 100, 100 );
renderWindow.display();
renderWindow.close();
return 0;
}
-
Telling my users with laptops to update their drivers hoping that it doesn't break something on theirs, isn't really an option either..;
Huh, why not?
-
Telling my users with laptops to update their drivers hoping that it doesn't break something on theirs, isn't really an option either..;
Huh, why not?
I was somewhat referring to my experience with hp laptops and their lack of support for continuous intel graphic card driver updates - grabbing in an intel graphic driver update from the intel site and just manually installing it to laptops with ex. dual graphic cards, seems many a time to cause a variety of crashes to a finely working machine.
I don't think asking my users to take this risk, especially if my current target audience is one that lacks computer knowledge, is really something I'd like to be doing.
-
I've noticed that the following code works without any access violation issues - any thoughts?
Since you no longer destroy the texture, it's most likely a problem with the destructor of sf::Texture. Which is confirmed by the previous test: calling window.close() would close the window before the texture, whereas letting the objects go out of scope would destroy the texture before the window.
-
On second glance, I think it has something to do with context sharing. Perhaps the Intel driver (from back then) doesn't like it when a resource is deleted in a different context than the one it was created in. This is something that works on all current desktop systems and as AlexAUT said, it also works for him with an up-to-date notebook driver. Coding a workaround to make sure that resources are destroyed within the context they were created would become very very complex and is probably not even currently feasible. If it was, it would certainly hamper people that don't have a problem with the current implementation.
You can check if this is the case with this code:
#include <SFML/Graphics.hpp>
int main()
{
sf::Context context;
{
sf::Texture texture;
texture.create(2, 2);
// Comment this line to see if it prevents the crash
context.setActive(false);
}
}
-
On second glance, I think it has something to do with context sharing. Perhaps the Intel driver (from back then) doesn't like it when a resource is deleted in a different context than the one it was created in. This is something that works on all current desktop systems and as AlexAUT said, it also works for him with an up-to-date notebook driver. Coding a workaround to make sure that resources are destroyed within the context they were created would become very very complex and is probably not even currently feasible. If it was, it would certainly hamper people that don't have a problem with the current implementation.
You can check if this is the case with this code:
#include <SFML/Graphics.hpp>
int main()
{
sf::Context context;
{
sf::Texture texture;
texture.create(2, 2);
// Comment this line to see if it prevents the crash
context.setActive(false);
}
}
Thanks for the reply,
I've just checked the code: as it is, it produces a 'Invalid address specified to RtlFreeHeap( 003F0000, 044EFF30 )' error.
With the 'context.setActive(false)' commented out, the program produces no error.
The code works both without and with the comment with the ATI driver.
What should I be doing then - is there something that can be done on my side?
-
What should I be doing then - is there something that can be done on my side?
Update graphics drivers as already said, or buy newer hardware which come with better drivers. It isn't feasible for us to work around stupid driver bugs like this.
-
What should I be doing then - is there something that can be done on my side?
Update graphics drivers as already said, or buy newer hardware which come with better drivers. It isn't feasible for us to work around stupid driver bugs like this.
Thanks for the opinion,
But as I've already mentioned, that isn't something I'd really like to be telling my users. If the problem only affected me, sure, that's what I would be doing, but this isn't the case.
I'd like to know if there are any workarounds that can be implemented on my side. I don't mind any excess boilerplate code if that will work.
-
I hate to break it to you, but if someone is not that computer-savvy, they really shouldn't be getting a system with dual graphics. They are known to be more maintenance intensive (not in the short term, but long term as you already noticed). This can be made easier if the notebook vendor would show some cooperation, but that obviously isn't the case with HP. Ironically, even in this case having a notebook with just an Intel IGP would be easier to maintain, and you could probably still run the latest GL code (albeit probably slower than a single discrete GPU solution) because the driver would be up-to-date.
Sorry to say this, but you're out of luck. We know what the problem is, but the assumption that context sharing works properly is so deeply rooted into the SFML code that it isn't feasible to code a workaround just for people who have this problem, even if they are not that small of a user base.
What you can do however, in your own code, is prevent this case from happening. Now that you understand what triggers the crash, you can take steps to avoid getting into this situation. As should be obvious from the example, make sure you always only have one context active, from the start to the end of the application. The first thing you should do is create the window and set its context active. Do not create new contexts or deactivate it after that. This means, no access to anything graphics related in secondary threads as well. The last thing your application should do is let the window go out of scope after all other resources have already been destroyed. Do not manually close it, it will close itself on destruction.
If you follow those instructions, chances are good that you will end up only working in a single context. I already do this myself, because I constantly work with unsharable resources like VAOs, and this strategy works for me. You have to be very strict on yourself, but if that is the only option you have, I don't think there is anything else you can do.
-
Sorry to say this, but you're out of luck. We know what the problem is, but the assumption that context sharing works properly is so deeply rooted into the SFML code that it isn't feasible to code a workaround just for people who have this problem, even if they are not that small of a user base.
What you can do however, in your own code, is prevent this case from happening. Now that you understand what triggers the crash, you can take steps to avoid getting into this situation. As should be obvious from the example, make sure you always only have one context active, from the start to the end of the application. The first thing you should do is create the window and set its context active. Do not create new contexts or deactivate it after that. This means, no access to anything graphics related in secondary threads as well. The last thing your application should do is let the window go out of scope after all other resources have already been destroyed. Do not manually close it, it will close itself on destruction.
If you follow those instructions, chances are good that you will end up only working in a single context. I already do this myself, because I constantly work with unsharable resources like VAOs, and this strategy works for me. You have to be very strict on yourself, but if that is the only option you have, I don't think there is anything else you can do.
Thanks for the reply - how should I then handle things like needing to change the window resolution during play? (ex. switching in and out of full screen)
From what I understand of the problem, using RenderWindow.create() to recreate the window may cause a context switch. (or does it not?)
-
You remember those good old days where games used to say something like: "To apply these settings, a game restart is required."
Yeah... those days :)
-
You remember those good old days where games used to say something like: "To apply these settings, a game restart is required."
Yeah... those days :)
Haha.... those good old days;
I don't know if this would be feasible, but would something along the lines of getting the opengl context from the current window, and managing its lifetime myself be possible? (and would that help solve this)
-
No. The window exclusively owns its context and you are not able to access it.
If you want, you can go down the masochistic route and create a second sf::Context which you will always activate after every window operation. Remember: the window will almost always activate its own context when you make it do something. So after every single window.someMethod() call, there would have to be a myContext.setActive(true) call. This second context would need to be declared right after the window to guarantee the destruction order and it would the one that you create all other objects in.
-
If you want, you can go down the masochistic route and create a second sf::Context which you will always activate after every window operation. Remember: the window will almost always activate its own context when you make it do something. So after every single window.someMethod() call, there would have to be a myContext.setActive(true) call. This second context would need to be declared right after the window to guarantee the destruction order and it would the one that you create all other objects in.
Thanks again for the reply,
I'll go with your advice and see how the masochistic route goes. I can confirm that the following code works without problem:
#include <SFML\Graphics.hpp>
int main()
{
sf::RenderWindow renderWindow( sf::VideoMode( 800, 600 ), "sfml test", sf::Style::Titlebar | sf::Style::Close );
sf::Context context;
sf::Texture texture;
texture.create( 2, 2 );
renderWindow.clear( sf::Color( 255, 255, 255, 255 ) );
renderWindow.display();
context.setActive( true );
renderWindow.close();
}
But if something like creating a second sf::Context and activating it after every window operation will get the job done, then wouldn't something along the lines of
1. create a function to pass the pointer to a manually managed sf::Context to sf::RenderWindow
2. create a private inline void function within sf::RenderWindow that
'if (m_pUniqueContext != nullptr) m_pUniqueContext->setActive(true)'
3. place the function at the end of every window function (except .close() which will need this at the start)
allow sfml to support both the current shared opengl context implementation and also all use cases requiring a unique opengl context? This seems like a method to get both done with minimum overhead and with barely any change to the current sfml code.
-
1. create a function to pass the pointer to a manually managed sf::Context to sf::RenderWindow
2. create a private inline void function within sf::RenderWindow that
'if (m_pUniqueContext != nullptr) m_pUniqueContext->setActive(true)'
3. place the function at the end of every window function (except .close() which will need this at the start)
allow sfml to support both the current shared opengl context implementation and also all use cases requiring a unique opengl context? This seems like a method to get both done with minimum overhead and with barely any change to the current sfml code.
Maybe it works, just try it. ;)
If this was a suggestion to include it within SFML, then no this is not going to happen.