violation d'accès à wglMakeCurrent

Question

Parfois, dans mon application OpenGL je reçois une violation d'accès dans l'appel API suivante:

wglMakeCurrent(NULL, NULL); 

L'application ne dispose que d'un seul fil, et je l'ai vérifié que avant cet appel, les deux DC et HGLRC qui sont actuellement utilisés sont corrects et valides.

Il existe trois fenêtres différentes avec le contenu OpenGL, et elles sont toutes redessinées sur les messages WM_PAINT et si une actualisation est requise en raison de l'interaction de l'utilisateur (par exemple, la sélection d'un objet).

Cette violation d'accès se produit également sur différentes machines avec différentes cartes graphiques, donc je ne pense pas que ce soit un problème de pilote.

Que pourrait faire planter cet appel d'API? Que dois-je rechercher dans le code de l'application pour savoir où/pourquoi cela se produit? Je suis vraiment perdu ici depuis que j'ai vérifié tout ce à quoi je pouvais penser. J'espère que quelqu'un peut me donner des conseils/idées sur ce qu'il y a d'autre à vérifier.

Answer 1

Il s'avère qu'un pilote graphique mis à jour fixe la question. Donc, c'était un problème dans le pilote.

Answer 2

Essayez d'ajouter un appel glFlush juste avant de procéder. Peut-être que le pipeline de rendu n'a pas encore été entièrement vidé vers le GPU.

Answer 3

Le but de cet appel est-il de libérer le contexte de périphérique du thread en cours? C'est la seule fois que passer NULL pour les deux paramètres est valide. De la documentation:

« Si hglrc est NULL, la fonction rend le contexte de rendu actuel thread appelant aucun courant plus, et libère le contexte de l'appareil qui est utilisé par le contexte de rendu Dans ce cas, hdc est ignoré.. "

Suite à la suggestion de Tarydon d'ajouter un glFlush, il semble que ce serait redondant:

« Avant de passer au nouveau contexte de rendu, OpenGL débusque un contexte de rendu précédent qui était en cours au thread appelant "

Compte tenu de l'API se bloque en fait, et ne résulte pas simplement un échec, la seule suggestion que je peux penser est que le fil sur lequel vous appelez wglMakeCurrent pour libérer le HGLRC n'est pas le même contexte de fil utilisé pour associer le HGLRC au contexte de ce périphérique. Il se peut donc que le pilote recherche le mauvais stockage local de l'appel, provoquant ainsi le plantage. Que se passe-t-il si vous ajoutez de la journalisation à votre code et imprimez l'ID de thread actuel juste avant chaque appel à wglMakeCurrent?

Voir:

• wglMakeCurrent reference sur MSDN