OpenGL bug? Nvidia driver bug? SFML bug? My fault?

[Tank]

Hi guys,

I've recently discovered a very disturbing "bug" -- if it's any. I'll try to describe the problem:

I'm using two threads in my application: the first polls SFML events, handles them and calls then another class (called "State") to render the scene. The second thread is inside that State class. It's launched when the State is created, waits a second and just creates an sf::Image and loads an image.

While the image gets loaded, it's possible that the first thread is just rendering the scene/clearing the window/displaying the contents.

So, my first question is: Is SFML threadsafe enough so that I don't have to manage that myself?

What happens is: when you start the program often enough (depends on luck, I guess...), it freezes. Backtrace:

Code: [Select]

#0  0x00007f8d9c74e1f4 in __lll_lock_wait () from /lib/libpthread.so.0
#1  0x00007f8d9c749acb in _L_lock_312 () from /lib/libpthread.so.0
#2  0x00007f8d9c7494d1 in pthread_mutex_lock () from /lib/libpthread.so.0
#3  0x00007f8d9dbff3c9 in ?? () from /usr/lib/libGL.so.1
#4  0x00007f8d9ac71d98 in ?? () from /usr/lib/libGLcore.so.1
#5  0x00007f8d9ac2caaa in ?? () from /usr/lib/libGLcore.so.1
#6  0x00007f8d9a8f133b in ?? () from /usr/lib/libGLcore.so.1
#7  0x00007f8d9d4a215e in sf::RenderTarget::Clear () from /usr/lib/libsfml-graphics.so.1.6
#8  0x000000000040354f in Tilechat::Run ()
#9  0x0000000000402f3b in main ()
So the last call before going to system libraries is sf::RenderTarget::Clear(). Then it's diving into OpenGL, where an infinite lock happens. This *normally* tells us it's a bug in OpenGL. But since I haven't learned the SFML source code good enough, that'd be also a possibility.

In the worst case, that "bug" even kills my X-Server! The log tells me this:

Code: [Select]

Backtrace:
560 0: /usr/bin/X(xf86SigHandler+0x6a) [0x47898a]
561 1: /lib/libc.so.6 [0x7f4c034470f0]
562 2: /usr/lib/xorg/modules/drivers//nvidia_drv.so(_nv001853X+0x6) [0x7f4bffbdf756]
563 3: /usr/lib/xorg/modules/drivers//nvidia_drv.so [0x7f4bffd5561c]
564 4: /usr/lib/xorg/modules/drivers//nvidia_drv.so [0x7f4bffd6c499]
565 5: /usr/bin/X(Dispatch+0x342) [0x44f7e2]
566 6: /usr/bin/X(main+0x4a5) [0x436bd5]
567 7: /lib/libc.so.6(__libc_start_main+0xe6) [0x7f4c034335a6]
568 8: /usr/bin/X [0x435e99]
nvidia_drv.so, that really sounds bad. But again, I don't know in which context and whatever. It's of course possible the bug starts very sooner and just kicks in at driver level.

So far, so good. Here's a ZIP containing source code for a minimal reproduction setup: *click* . Please keep in mind that the sources come from a rather full-blown game. I've stripped them down as much as possible to isolate the bug.


Okay, then something else, which maybe has something todo with the described bug above:
In my full game, I've also got one critical bug: *Sometimes* (not always!) the program crashes with an GLXBadContext error code. That ALWAYS happens when 1. using sf::Image::LoadFromFile() OR 2. doing something with the loaded image after that.

If that helps, I can post more source code, but since it's a big project, it would take some more time to understand it. So I thought I'd just point you in the right direction at first to see if you know anything that can help.

My system setup is:
Debian GNU/Linux on a 64 Bit AMD CPU
SFML version: SVN r1177 (latest)
Graphics driver: nvidia, 185.18.14 (latest)
Kernel: 2.6.26

If you need any information, please let me know. It's important for me to get that thing fixed, since it stops my programming entirely.

[Laurent]

You should try the sfml2 branch, the OpenGL context handling has been totally rewritten so this kind of problem has typically disappeared.

If you're using the graphics module in a secondary thread in SFML 2, you'll have to explicitely instanciate a context and keep it alive as long as you're making graphics calls. See the documentation (header) of the sf::Context class for an example.

[Tank]

Good to know that there's a solution to this, thank you very much.

I'll switch over to SFML2 and see if that problem will disappear. Is there any way to automate that context behaviour in the future?

[Laurent]

Is there any way to automate that context behaviour in the future?

I've been thinking about this issue for a very (very very very) long time, and this is the simplest solution I found. Handling properly OpenGL contexts across threads is a pain in the ass

But it's not a big deal:

Code: [Select]

void ThreadedFunc(void*)
{
    sf::Context context;

    // your code
}

[Tank]

Okay, I switched to SFML2 and get some other errors now regarding to the sf::Context. In total 3 possible errors:

BadIDChoice

Code: [Select]

X Error of failed request:  BadIDChoice (invalid resource ID chosen for this connection)
  Major opcode of failed request:  1 (X_CreateWindow)
  Resource id in failed request:  0x2600010
  Serial number of failed request:  104
  Current serial number in output stream:  104

Backtrace from gdb:

Code: [Select]


#0  0x00007f6f0398f469 in glDeleteTextures () from /usr/lib/libGL.so.1
#1  0x00007f6f030bb232 in sf::Image::DestroyTexture () from /usr/lib/libsfml-graphics.so.2.0
#2  0x00007f6f030bb4d6 in sf::Image::~Image () from /usr/lib/libsfml-graphics.so.2.0
#3  0x00000000004179ec in ~Font (this=0x7f6f0339d940) at /usr/include/SFML/Graphics/Font.hpp:55
#4  0x00007f6f019957dd in exit () from /lib/libc.so.6
#5  0x00007f6f0145033d in _XDefaultError () from /usr/lib/libX11.so.6
#6  0x00007f6f0145040c in _XError () from /usr/lib/libX11.so.6
#7  0x00007f6f01457e93 in _XReply () from /usr/lib/libX11.so.6
#8  0x00007f6f012039df in ?? () from /usr/lib/libXrandr.so.2
#9  0x00007f6f01203d88 in XRRGetScreenInfo () from /usr/lib/libXrandr.so.2
#10 0x00007f6f033b348a in sf::priv::VideoModeSupport::GetDesktopVideoMode () from /usr/lib/libsfml-window.so.2.0
#11 0x00007f6f033ae8a9 in sf::VideoMode::GetDesktopMode () from /usr/lib/libsfml-window.so.2.0
#12 0x00007f6f033b27af in sf::priv::ContextGLX::ContextGLX () from /usr/lib/libsfml-window.so.2.0
#13 0x00007f6f033ae0da in sf::priv::ContextGL::New () from /usr/lib/libsfml-window.so.2.0
#14 0x00007f6f033add19 in sf::Context::Context () from /usr/lib/libsfml-window.so.2.0
#15 0x0000000000416e2e in DebugState::ThreadFunc (arg=0x184a6d0) at client/src/debugstate.cpp:17
#16 0x00007f6f035c0cb9 in sf::priv::ThreadImpl::EntryPoint () from /usr/lib/libsfml-system.so.2.0
#17 0x00007f6f0174afaa in start_thread () from /lib/libpthread.so.0
#18 0x00007f6f01a2d29d in clone () from /lib/libc.so.6
#19 0x0000000000000000 in ?? ()

BadLength

Code: [Select]

X Error of failed request:  BadLength (poly request too large or internal Xlib length error)
  Major opcode of failed request:  62 (X_CopyArea)
  Serial number of failed request:  105
  Current serial number in output stream:  106

Backtrace from gdb:

Code: [Select]

#0  0x00007f4b0a922469 in glDeleteTextures () from /usr/lib/libGL.so.1
#1  0x00007f4b0a04e232 in sf::Image::DestroyTexture () from /usr/lib/libsfml-graphics.so.2.0
#2  0x00007f4b0a04e4d6 in sf::Image::~Image () from /usr/lib/libsfml-graphics.so.2.0
#3  0x00000000004179ec in ~Font (this=0x7f4b0a330940) at /usr/include/SFML/Graphics/Font.hpp:55
#4  0x00007f4b089287dd in exit () from /lib/libc.so.6
#5  0x00007f4b083e333d in _XDefaultError () from /usr/lib/libX11.so.6
#6  0x00007f4b083e340c in _XError () from /usr/lib/libX11.so.6
#7  0x00007f4b083ea719 in ?? () from /usr/lib/libX11.so.6
#8  0x00007f4b083eae00 in _XReply () from /usr/lib/libX11.so.6
#9  0x00007f4b083c8d29 in _XGetWindowAttributes () from /usr/lib/libX11.so.6
#10 0x00007f4b083c8ed8 in XGetWindowAttributes () from /usr/lib/libX11.so.6
#11 0x00007f4b0a344cd2 in sf::priv::ContextGLX::CreateContext () from /usr/lib/libsfml-window.so.2.0
#12 0x00007f4b0a3457d1 in sf::priv::ContextGLX::ContextGLX () from /usr/lib/libsfml-window.so.2.0
#13 0x00007f4b0a3410da in sf::priv::ContextGL::New () from /usr/lib/libsfml-window.so.2.0
#14 0x00007f4b0a340d19 in sf::Context::Context () from /usr/lib/libsfml-window.so.2.0
#15 0x0000000000416e2e in DebugState::ThreadFunc (arg=0x1c447d0) at client/src/debugstate.cpp:17
#16 0x00007f4b0a553cb9 in sf::priv::ThreadImpl::EntryPoint () from /usr/lib/libsfml-system.so.2.0
#17 0x00007f4b086ddfaa in start_thread () from /lib/libpthread.so.0
#18 0x00007f4b089c029d in clone () from /lib/libc.so.6
#19 0x0000000000000000 in ?? ()

Freeze
Explained in the 1st posting.

Works!
Aaaand sometimes, it just works.


Edit: BTW, I just added the line "sf::Context  context;" to the thread function, like explained in the Context.hpp.

[Laurent]

Could you post the complete code that reproduces these errors?

[Tank]

Sure: Testsuite

And btw, another error came along: BadWindow.

[Laurent]

It seems to run fine on Windows (no error, got black screen with white text showing FPS).

I'll now try on Linux.

[Tank]

That's good. That shows at least it probably a problem with OpenGL or the driver under Linux.

[Laurent]

Ok, same errors on Linux.

By the way, this is a minimal example

Code: [Select]

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

sf::Image image;

void ThreadFunc(void*)
{
sf::Context context;
sf::Sleep(1.f);
image.LoadFromFile("rock.png");
std::cout << "OK!" << std::endl;
}

int main()
{
    sf::RenderWindow window(sf::VideoMode(1024, 768, 32), "Testsuite");

    sf::Thread thread(&ThreadFunc);
    thread.Launch();

    while (window.IsOpened())
    {
        sf::Event event;
        while (window.GetEvent(event))
        {
            if (event.Type == sf::Event::KeyPressed && event.Key.Code == sf::Key::Escape)
                window.Close();
        }

        window.Clear();
        window.Draw(sf::String("blah..."));
        window.Display();
    }

    return 0;
}

[Tank]

Yep, you're right. I just took as less lines of code from my actual project to a testsuite environment as possible -- too lazy to write something from scratch, sorry.

Do you already have an idea why that happens? Could it be the driver or the underlying OpenGL libraries?

[Laurent]

Actually, nothing is working, even the samples. And it has nothing to do with threading.

The only thing I made is installing the proprietary nVidia driver; I checked with the free driver and it works fine. It's surprising that nobody reported me this error before (is everyone using the free driver??).

It's not a bug in the driver because SFML 1.5 works fine.

:evil:

[Tank]

So something that got in trunk (or SFML2) lately?

[Laurent]

Actually SFML 1.5 is not working. So it may be a modification I made recently.

[Tank]

Hopefully an obviously change that can get fixed quick. Let me know when there's something to test or whatever.