Segfault in multithread OpenGL app on i915

Hello,

I have a weird problem with multithread application on i915 chipset (i810 DRI driver). Application segfaults when trying to use OpenGL functions from second thread.

All necessary initialization is perfomed in application, ie XInitThreads, etc.

Tested on Suse 10.1 (xorg 6.8, 20050225 i810 driver) and Gentoo LiveDVD (xorg 7.0, 1.4.2 i810 driver).

This code works fine with NVidia drivers.

Is this a driver bug? a Mesa bug? a well-known bug that nobody is going to fix in near future? Or this is my programming error?

static void* cbOpenglTest1(void*)
{
  while(1)
  {
    XLockDisplay(display);
    if(!glXMakeCurrent(display, x_win, x_glxContext))
    {
      printf("glXMakeCurrent failed
");
      exit(0);
    }
    int err = glGetError();
    L_INFO("OpenGL Error: %i", err);
    if(!glXMakeCurrent(display, 0, 0))
    {
      printf("glXMakeCurrent failed
");
      exit(0);
    }
    XUnlockDisplay(display);
    usleep(100);
  }
  return 0;
}

static void Expose()
{
  XLockDisplay(display);
  if(!glXMakeCurrent(display, win, glxContext))
  {
    printf("glXMakeCurrent failed
");
    exit(0);
  }
  glClear(GL_COLOR_BUFFER_BIT | GL_DEPTH_BUFFER_BIT);
  glColor3f(1.0, 0.0, 0.0);
  glRectf(-0.5, -0.5, 0.5, 0.5);
  swapBuffers();
  if(!glXMakeCurrent(display, 0, 0))
  {
    printf("glXMakeCurrent failed
");
    exit(0);
  }
  XUnlockDisplay(display);
}


Nickolay

Hard to say like that. You code is syntactically and sementically right.

I personally don’t use X synchronization functions but what you’ve done should be correct.

Also I’m almost sure this is not a bug from X neither from Mesa (but if you have a very old Mesa version). Maybe an i810 driver bug but really hard to say even if I remember there have had some workarounds with such drivers (but for other reasons, like GL compatibilities).

So I can make only guesses. Do you define _REENTRANT when compiling (assuming you use pthreads) ? What’s your glx version ? Did you tried to debug your program ?

Finally, it’s best to unlock the display before making an exit when you encounter a problem, mainly if it’s not in the main thread just because the main thread will continue to work and will indefinately wait for the display release which will never happen.

Brian Paul, pointed to Mesa/progs/xdemos/glthreads.c program as a good “cross-check”.

It also segfaults on i810 driver, but works correctly with NVidia. Can somebody confirm this behaviour?

Try to use the VESA drivers instead of i810 (should be Driver “vesa” or so in /etc/X11/xorg.conf, make a search as I can’t confirm it). These are generic drivers, so should work okay with threads.

  1. Vesa drivers also don’t work correctly (different behaviour — full X segfault)

  2. I’m not interested in Vesa drivers. I need 3D acceleration on Intel Integrated Graphics Chipset under Linux. :frowning:

I’ve found related bug in freedesktop bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=6240

I wasn’t saying you should switch to VESA. I tried to mean that you could test under VESA.
So as you have the same errors on different drivers, the problem might come, as you said, from xorg.

So what you could try for the moment, is simply to create a new context inside your thread. However, I’m really unsure about the result (should work okay on non-buggy environments).

Upgrading to Xorg 7.1, Mesa 6.5.1 and Intel driver 1.7.0 — fixed problem. (many thanks to Gentoo team)

We need to upgrade Mesa?
I’ve never bothered with it. I just update the video driver.

I think that driver DRI interface uses Mesa internally. glxinfo displays information about Mesa version.

This topic was automatically closed 183 days after the last reply. New replies are no longer allowed.