como rastrear uma falha ao mudar de X: 1 para X: 0?

4

Eu preciso rastrear no 14.04 um acidente que acontece aqui:

Eu abro um novo X em: 1 (que às vezes vai para ctrl + alt + f8 outros para f9).
Mas quando eu tento voltar para o X: 0 com ctrl + alt + f7, ele cai cerca de 30% do tempo ...

O travamento acontece de forma que a tela de login é exibida novamente.

Eu olhei para /var/log/apport.log e achei isso:

ERROR: apport (pid 769726) Fri Aug  1 00:47:56 2014: called for pid 1457, signal 6, core limit 18446744073709551615
ERROR: apport (pid 769726) Fri Aug  1 00:47:56 2014: ignoring implausibly big core limit, treating as unlimited
ERROR: apport (pid 769726) Fri Aug  1 00:47:56 2014: executable: /usr/bin/Xorg (command line "/usr/bin/X -core :0 -seat seat0 -auth /var/run/lightdm/root/:0 -nolisten tcp vt7 -novtswitch")
ERROR: apport (pid 769726) Fri Aug  1 00:47:56 2014: is_closing_session(): no DBUS_SESSION_BUS_ADDRESS in environment
ERROR: apport (pid 769726) Fri Aug  1 00:47:56 2014: apport: report /var/crash/_usr_bin_Xorg.0.crash already exists and unseen, doing nothing to avoid disk usage DoS

Eu acho que a resposta pode ser uma informação genérica de rastreamento de travamento sobre: Xorg, xscreensaver, cpufreq e outros aplicativos que poderiam causar uma falha em tal situação de troca de terminal virtual. Podem ser também aplicativos relacionados ao OpenGL, como o Unity.

Eu apenas garanti que nenhum hacker de opengl de xscreensaver estivesse rodando, apenas labirinto; e um acidente aconteceu novamente.

Eu bloqueio a tela com xscreensaver, mas depois de algum tempo o screenlocker padrão da unidade entra em ação também, então eu tenho que fazer o login duas vezes.

Notícias úteis:
O acidente parece claramente relacionado ao Unity 3D, ignorando a presença de outro VT?
Eu vi claramente que o Unity HUD fica bagunçado como "suas texturas 3D" corrompem a memória?
Existe este script que verifica e pede para substituir compiz com metacity --replace .
Desde que comecei a usá-lo, não tive um único acidente; infelizmente, ao voltar para o X: 0 eu tenho que compiz --replace (o script está pronto para fazer isso também). Esse outro script (que abre uma nova sessão X) também faz essas verificações / fornece essas opções.

    
por Aquarius Power 01.08.2014 / 08:06

1 resposta

0

Isso vem acontecendo desde a atualização para o XUbuntu 16.04 (sem unidade, 3D ou de outra forma), 64 bits. Aqui está um novo apport.log:

ERROR: apport (pid 5067) Sun Sep  4 12:10:39 2016: called for pid 2649, signal 6, core limit 18446744073709551615

ERROR: apport (pid 5067) Sun Sep  4 12:10:39 2016: ignoring implausibly big core limit, treating as unlimited

ERROR: apport (pid 5067) Sun Sep  4 12:10:39 2016: executable: /usr/lib/xorg/Xorg (command line "/usr/lib/xorg/Xorg -core :0 -seat seat0 -auth /var/run/lightdm/root/:0 -nolisten tcp vt7 -novtswitch")

ERROR: apport (pid 5067) Sun Sep  4 12:10:39 2016: is_closing_session(): no DBUS_SESSION_BUS_ADDRESS in environment

ERROR: apport (pid 5067) Sun Sep  4 12:10:39 2016: apport: report /var/crash/_usr_lib_xorg_Xorg.0.crash already exists and unseen, doing nothing to avoid disk usage DoS

(Eu permito que o sistema envie relatórios sobre o problema.)

    
por Kent 05.09.2016 / 16:32

Tags