I still seem to have problems with this. I'm working on the project with opatut and the threading stuff that works for him crashes for me. I debugged it quite a bit and figured it must be an implementation problem but I do not know who is at fault.
Relevant parts of backtrace on my machine (Arch Linux x86_64, Mobility Radeon X2100 with r500g drivers, mesa from recent git):
#0 0x0000000000000020 in ?? ()
#1 0x00007fffef33d1af in ?? () from /usr/lib/xorg/modules/dri/r300_dri.so
#2 0x00007fffef34b882 in ?? () from /usr/lib/xorg/modules/dri/r300_dri.so
#3 0x00007fffef4020b9 in ?? () from /usr/lib/xorg/modules/dri/r300_dri.so
#4 0x00007fffef49af57 in ?? () from /usr/lib/xorg/modules/dri/r300_dri.so
#5 0x00007fffef3e6b21 in ?? () from /usr/lib/xorg/modules/dri/r300_dri.so
#6 0x00007ffff794eccb in sf::Image::EnsureTextureUpdate() const ()
from /usr/lib/libsfml-graphics.so.2.0
#7 0x00007ffff794ecf9 in sf::Image::Bind() const ()
from /usr/lib/libsfml-graphics.so.2.0
#8 0x00007ffff7964a3d in sf::Renderer::SetTexture(sf::Image const*) ()
from /usr/lib/libsfml-graphics.so.2.0
#9 0x00007ffff7969132 in sf::Sprite::Render(sf::RenderTarget&, sf::Renderer&) const ()
from /usr/lib/libsfml-graphics.so.2.0
#10 0x00007ffff796581a in sf::RenderTarget::Draw(sf::Drawable const&) ()
from /usr/lib/libsfml-graphics.so.2.0
#11 0x000000000055b93d in Submarine::Draw (this=0x7fffe4037390, target=0x8410a8)
at /home/svenstaro/NoisyHunter/game/src/common/Submarine.cpp:111
Surprisingly, it works when I start it in valgrind (albeit with corruption). I originally suspected a racing condition in our code. However, it works just fine for the nvidia users with proprietary nvidia drivers.
The thread is launched as follows:
void ResourceManager::LoadAllQueuedImages(void* data) {
sf::Context context;
auto resmgr = Root::get_mutable_instance().GetResourceManagerPtr();
while(!resmgr->GetLoadingStatus().IsFinished()) {
resmgr->LoadNextImage();
}
}The problematic line here is sf::Conext context. If I take it out, the thread breaks for nvidia users due to missing glContext but works for me (though I get white images as expected). If I put it in, nvidia users observe expected behavior but it crashes for me with the above backtrace unless I run it in valgrind, oddly enough.
The problem isn't even that the sf::Context can't somehow be created. For instance, if I run it with
void ResourceManager::LoadAllQueuedImages(void* data) {
sf::Context context;
auto resmgr = Root::get_mutable_instance().GetResourceManagerPtr();
while(!resmgr->GetLoadingStatus().IsFinished()) {
resmgr->LoadNextImage();
}
sf::Sleep(10.f);
}I can play for 10 seconds until the thread goes out of scope. The behavior is just as expected in that case. I'd idle the thread indefinitely but that looks like an ugly hack. I tried creating a memory leak like this:
void ResourceManager::LoadAllQueuedImages(void* data) {
sf::Context* context = new sf::Context();
auto resmgr = Root::get_mutable_instance().GetResourceManagerPtr();
while(!resmgr->GetLoadingStatus().IsFinished()) {
resmgr->LoadNextImage();
}
}and it works without crash. It gives me almost the expected behavior. I get a few image corruptions in the images loaded in the thread. Not all images come out corrupt, but those that do are so corrupt that my driver refuses rendering them (I get a kernel exception for an invalid texture steam).
I tested the exactly same stuff on a Arch Linux i686-based Radeon Mobility FireGl 9000-series card with r200 (non-gallium) drivers and the behavior is almost exactly the same as on my r500g (the corruption looks different).
Suspecting a problem in the mesa part of this, I ran it on my Arch Linux x86_64 Virtualbox guest. In this case, the sf::Context never was created and the images were never actually loaded. They all came out white. The Virtualbox guest uses their accelerated Chromium drivers.
Can you give us some insight here? At first glance it would seem as though the drivers are at fault but on a second look this might not be actually true and the sf::Context might in fact be the problem. Any help appreciated.
