Como o stracing de execução pode corrigir meu problema de OpenGL?

8

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

Uma vez que descobri que poderia estar relacionado ao OpenGL, comecei a jogar com glxgears como teste. Correndo por si mesmo segfaults instantaneamente. Então eu descobri que executá-lo em strace é executado corretamente. O mesmo acontece com mplayer . Executá-lo em um arquivo de teste segfaults instantaneamente, executando strace mplayer reproduz muito bem (embora o pulso de áudio ainda morra e ele retorna a um dispositivo de saída fictício).

Como a execução de algo sob strace impede que ele seja segmentado e como eu continuaria a depurar a situação?

    
por Caleb 08.03.2012 / 23:26

4 respostas

2

Eu observei que libGL.so da Nvidia tenta detectar se o processo atual está sendo rastreado, abrindo /proc/self/status e procurando por " TracerPid: ". Caminhos de código diferentes são tomados dependendo se o valor de TracerPid é diferente de zero (isto é, o processamento atual está sendo rastreado ou não).

Instale sysdig e capture o rastreio para o processo ofensivo duas vezes, uma vez enquanto estiver em stracing, uma vez sem o strace. 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 alteração no fluxo de execução entre as execuções com strings e sem strings de glxgears .

strace "corrige" seu problema de OpenGL, porque libGL está se comportando de maneira diferente dependendo se o processo está sendo rastreado / depurado.

    
por 17.12.2014 / 17:14
1

Eu imagino 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 proprietário nVidia, isso irá restaurar o libGL.so fornecido pela nVidia.

    
por 09.04.2012 / 01:52
0

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

Além disso, tente inicializar sua máquina com um pen drive USB com outra distro e veja se o problema persiste. Se isso não acontecer, talvez as versões de driver das outras distros possam ser usadas em sua máquina. Também poderia lançar alguma luz sobre as especificidades do problema que você está tendo (parece ser um erro de cronometragem).

As máquinas modernas ainda são capazes de desacelerar o barramento PCI? É um PC desktop ou um notebook?

Apenas como uma observação, você pode poupar-se de muitas dores futuras evitando a ATI e a NVidia, se possível em termos de performance. Suas margens são tão baixas que até mesmo uma queda de 1% na base de usuários pode desencadear a limpeza do ato.

    
por 21.03.2012 / 23:50
-1

Livre-se dos drivers proprietários da nvidia e use os de código aberto. Você se identificou como proprietários dos drivers nvidia para ter um problema.

    
por 09.03.2012 / 21:12