Comment l'exécution de strace pourrait-elle résoudre mon problème OpenGL?

Depuis une récente mise à niveau majeure de ma distribution (PLD Linux), j'ai eu des problèmes avec toute une série de programmes. Autant que je sache, tout ce qui touche les défauts de segmentation OpenGL ou PulseAudio. J'utilise les pilotes nvidia propriétaires et un noyau 3.2.x. Xorg lui-même fonctionne bien et je suis capable d'exécuter la plupart des programmes, cependant des choses comme mplayer segfault et aucun son n'est produit par aucun programme.

Une fois que j'ai compris qu'il pourrait être lié à OpenGL, j'ai commencé à jouer avec glxgearscomme test. L'exécuter par lui-même segfaults instantanément. Ensuite, j'ai découvert que le faire fonctionner sous stracefonctionnait bien. La même chose est vraie pour mplayer. Le lancer sur un fichier mp3 de test se sépare instantanément, le fonctionnement fonctionne strace mplayertrès bien (bien que le son à impulsions meurt toujours et qu'il redevienne un périphérique de sortie factice).

Comment le fait d'exécuter quelque chose sous l' straceempêcherait-il de se briser et comment pourrais-je continuer à déboguer la situation?

J'ai observé que Nvidia libGL.sotente de détecter si le processus en cours est tracé, en ouvrant /proc/self/statuset en recherchant " TracerPid:". Différents chemins de code sont choisis selon que la valeur de TracerPidest non nulle (c'est-à-dire si le traitement en cours est tracé ou non).

Installez sysdig et capturez deux fois la trace du processus incriminé, une fois pendant le stracing, une fois sans strace. Par exemple:

$ sysdig -w glxgears.scap proc.name=glxgears &
$ glxgears &
$ kill -TERM `pidof glxgears`
$ kill -TERM `pidof sysdig`
$ sysdig -w glxgears-strace.scap proc.name=glxgears &
$ strace glxgears &
$ kill -TERM `pidof glxgears`
$ kill -TERM `pidof sysdig`

Comparez la sortie textuelle des deux traces différentes pour observer le changement dans le flux d'exécution entre les séquences étirées et non étirées de glxgears.

strace"corrige" votre problème OpenGL, car il libGLse comporte différemment selon que le processus est tracé / débogué.

J'imagine qu'un autre paquet a remplacé libGL.so par sa propre version, remplaçant la version nVidia - très probablement un paquet Mesa. Pour résoudre le problème, réinstallez le pilote nVidia propriétaire, cela restaurera le libGL.so fourni par nVidia.

Vous avez dit avoir essayé nv, nouveau et vesa. Que s'est-il passé dans chaque cas?

Essayez également de démarrer votre ordinateur à partir d'une clé USB avec une autre distribution et voyez si le problème persiste. Si ce n'est pas le cas, alors, peut-être, les versions de pilote des autres distributions peuvent être utilisées sur votre machine. Cela pourrait également éclairer les spécificités du problème que vous rencontrez (il semble que ce soit un bug de synchronisation).

Les machines modernes sont-elles toujours capables de ralentir le bus PCI? Est-ce un ordinateur de bureau ou un ordinateur portable?

Juste comme une note latérale, vous pouvez vous épargner beaucoup de douleur future en évitant complètement ATI et NVidia, si possible en termes de performances. Leurs marges sont si faibles que même une baisse de 1% de la base d'utilisateurs peut les inciter à nettoyer leur acte.

Débarrassez-vous des pilotes nvidia propriétaires et utilisez ceux open source. Vous vous êtes identifié comme étant les pilotes propriétaires nvidia.