glXMakeCurrent haengt fest

[tom dent]

Hallo,

ich habe ein Problem mit meinem GL Programm und den dort verwendetetn Pbuffern. Eigentlich wollte ich nur einen Fehler-Toleranten Ansatz fuer die Erzeugung von Pbuffern schreiben, d.h. dass mein Programm auch dann fehlerfrei weiterlaeuft, wenn ein Pbuffer nicht erfoglreich erzeugt werden konnte.

Ich habe also mit
XSetErrorHandler
einen Error Handler eingehaengt, der mir bei "BadAlloc Problemen" eine globale Variable setzt, die ich nach dem glXCreatePbuffer abfrage. So kann ich entsprechend auf BadAllocs reagieren. Ist dies bereits kein "sicheres" Vorgehen?

Jetzt bekomme ich aber ein Problem (einen Haenger) wenn ich einen neuen context erzeuge und diesen current mache:
glXCreateContext
glXMakeCurrent

das Erzeugen des Context funktioniert noch problemlos ohne Fehler (kein X und kein GL Fehler). Allerdings haengt sich der Prozess dann im glXMakeCurrent auf (kein Absturtz oder aehnliches. Wenn man mit einem Debugger oder strace schaut was der Prozess so treibt so sieht man eine ganze Reihe von getPid() aufrufen, die letzten Stellen die man vor dem getPid Aufruf sieht sind folgende:

#0 0x0000002aab8cdab9 in getpid () from /lib64/tls/libc.so.6
#1 0x0000002aa9027690 in glXChannelRectSyncSGIX () from /usr/lib64/libGL.so.1
#2 0x0000002aa9026539 in glXChannelRectSyncSGIX () from /usr/lib64/libGL.so.1
#3 0x0000002aa902e949 in glXChannelRectSyncSGIX () from /usr/lib64/libGL.so.1
#4 0x0000002aa901f518 in ?? () from /usr/lib64/libGL.so.1
#5 0x0000002aa904d88f in _nv000004gl () from /usr/lib64/libGL.so.1
#6 0x0000002aa904d35b in _nv000004gl () from /usr/lib64/libGL.so.1
#7 0x0000002aaca0214c in _nv000096gl () from /usr/lib64/libGLcore.so.1
#8 0x0000002aac9b9419 in _nv000111gl () from /usr/lib64/libGLcore.so.1
#9 0x0000002aac9f9fab in _nv000096gl () from /usr/lib64/libGLcore.so.1
#10 0x0000002aacae3d1b in _nv000049gl () from /usr/lib64/libGLcore.so.1
#11 0x0000002aacae432a in _nv000049gl () from /usr/lib64/libGLcore.so.1
#12 0x0000002aacae46df in _nv000049gl () from /usr/lib64/libGLcore.so.1
#13 0x0000002aac9bb6fb in _nv000106gl () from /usr/lib64/libGLcore.so.1
#14 0x0000002aa902820f in glXChannelRectSyncSGIX () from /usr/lib64/libGL.so.1
#15 0x0000002aa902bad6 in glXChannelRectSyncSGIX () from /usr/lib64/libGL.so.1
#16 0x0000002aa9025ea2 in glXMakeCurrent () from /usr/lib64/libGL.so.1

Wenn ich jetzt allerdings einen ganz anderen Prozess starte (ein ganz anderes Programm auch), welches fuer das gleiche Display ebenfalls einen PBuffer anlegt (bzw. versucht anzulegen, da alle Ressourcen bereits verbraucht sind), dann laeuft auch der erste Prozess weiter.

Bisherige versuche das Problem zu loesen:

Ich habe mir Mesa kompiliert und versucht die Code-Pfade nachzuvollziehen. Der Fehler trat mit Mesa nicht auf (da hier die Ressourcenbegrenzung fuer PBuffer nicht wie bei der Grafikkarte stark limitiert ist) aber man bekommt eine Idee wie das Ganze funktioniert.

Ich habe mich mit gDEBugger an den Prozess gehaengt und versucht auf OpenGL Fehler hin zu Debuggen. Ohne Ergebnis - mein Fehler schein mehr ein X Problem zu sein.

Vermutung:
Meine Vermutung ist, dass durch den Abbruch (BadAlloc) beim Versuch einen PBuffer zu erzeugen irgendetwas nicht korrekt wieder zurueckgesetzt wird. Im Mesa Code gibt es an diversen Stellen ein LockDisplay. Etwas in dieser Richtung vermute ich auch. Es wird etwas (eine Ressource) blockiert und durch den BadAlloc-Fehlerfall nicht wieder freigegeben. Ein erneuter Aufruf von CreatePBuffer sorgt dann wieder fuer die Freigabe und das Programm laeuft weiter.

Umgebung:
Das Ganze passiert unter Linux:
Red Hat Enterprise Linux WS release 3 (Taroon Update 4)
auf einem 64 Bit System.
OpenGL vendor string: NVIDIA Corporation
OpenGL renderer string: Quadro FX 1000/AGP/SSE2
OpenGL version string: 2.1.0 NVIDIA 96.31

Ich bin fuer jeden Hinweis oder Tipp dankbar. Leider gehen mir langsam die Ideen aus.

[tom dent]

Mit einem 100.14er Nvidia Treiber tritt das Problem nicht mehr auf.