Como a execução do strace pode corrigir o problema do OpenGL?

Desde uma grande atualização recente para minha distribuição (PLD Linux), tenho tido problemas com vários programas. Pelo melhor que posso dizer, qualquer coisa que toque nos segmentos OpenGL ou PulseAudio. Estou usando os drivers proprietários da nvidia e um kernel 3.2.x. O próprio Xorg roda bem e eu consigo executar a maioria dos programas, no entanto, coisas como mplayer segfault e nenhum som é produzido por nenhum programa.

Depois que descobri que isso poderia estar relacionado ao OpenGL, comecei a brincar glxgearscomo um teste. Executá-lo sozinho segfaults instantaneamente. Então eu descobri que executá-lo em stracebom estado. O mesmo vale para mplayer. Executando-o em um arquivo mp3 de teste segfaults instantaneamente, a execução strace mplayeré executada muito bem (embora o áudio de pulso ainda morra e seja revertido para um dispositivo de saída falso).

Como a execução de algo sob straceimpedi-lo de segfaulting e como eu continuaria a depurar a situação?

Eu observei que as libGL.sotentativas da Nvidia de detectar se o processo atual está sendo rastreado, abrindo /proc/self/statuse procurando " TracerPid:". Caminhos de código diferentes são usados ​​dependendo se o valor de TracerPidfor diferente de zero (ou seja, o processamento atual está sendo rastreado ou não).

Instale o sysdig e capture o rastreamento a para o processo incorreto duas vezes, uma vez durante o rastreamento, uma vez sem rastreamento. Por exemplo:

$ 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`

Compare a saída textual dos dois rastreamentos diferentes para observar a mudança no fluxo de execução entre as execuções com e sem rastreamento glxgears.

strace"corrige" o problema do OpenGL, porque seu libGLcomportamento é diferente dependendo de o processo estar sendo rastreado / depurado.

Eu imaginaria que outro pacote substituiu libGL.so por sua própria versão, substituindo a versão nVidia - provavelmente um pacote Mesa. Para corrigir o problema, reinstale o driver nVidia proprietário, isso restaurará o libGL.so fornecido pela nVidia.

Você disse que tentou nv, nouveau e vesa. O que aconteceu em cada caso?

Além disso, tente inicializar sua máquina com um dispositivo USB com outra distribuição e verifique se o problema persiste. Caso contrário, talvez as versões de driver de outras distros possam ser usadas na sua máquina. Também poderia lançar alguma luz sobre as especificidades do problema que você está tendo (parece ser um bug de tempo).

As máquinas modernas ainda são capazes de diminuir a velocidade do barramento PCI? É um PC de mesa ou um notebook?

Apenas como uma observação lateral, você pode poupar muita dor no futuro, evitando a ATI e a NVidia completamente, se possível em termos de desempenho. Suas margens são tão baixas que mesmo uma queda de 1% na base de usuários pode levá-los a limpar suas ações.

Livre-se dos drivers proprietários da nvidia e use os de código aberto. Você se identificou com os drivers proprietários da nvidia como culpados.