ddd falha ao conectar ao X Window: É um bug ou um erro de configuração local?

Question

No momento, estou analisando um problema em que ddd trava porque não pode se conectar ao X Window. Aqui está a saída do strace:

connect(4, {sa_family=AF_LOCAL, sun_path=@"/tmp/.X11-unix/X0"}, 20) = 0
getpeername(4, {sa_family=AF_LOCAL, sun_path=@"/tmp/.X11-unix/X0"}, [20]) = 0
uname({sysname="Linux", nodename="terra-arch", ...}) = 0
access("/home/phil/.Xauthority", R_OK)  = 0
open("/home/phil/.Xauthority", O_RDONLY) = 5
fstat(5, {st_mode=S_IFREG|0600, st_size=55, ...}) = 0
read(5, "
ls -alhgtr /var/cache/pacman/pkg/xorg-*
...
-rw-r--r-- 1 root  27K Mar 25 10:01 /var/cache/pacman/pkg/xorg-server-common-1.18.2-4-x86_64.pkg.tar.xz
-rw-r--r-- 1 root 1.3M Mar 25 10:01 /var/cache/pacman/pkg/xorg-server-1.18.2-4-x86_64.pkg.tar.xz
-rw-r--r-- 1 root 708K Mar 25 10:01 /var/cache/pacman/pkg/xorg-server-xvfb-1.18.2-4-x86_64.pkg.tar.xz
-rw-r--r-- 1 root  17K Apr  1 18:25 /var/cache/pacman/pkg/xorg-xinit-1.3.4-4-x86_64.pkg.tar.xz
-rw-r--r-- 1 root 732K Apr  5 19:36 /var/cache/pacman/pkg/xorg-server-xvfb-1.18.3-1-x86_64.pkg.tar.xz
-rw-r--r-- 1 root  27K Apr  5 19:36 /var/cache/pacman/pkg/xorg-server-common-1.18.3-1-x86_64.pkg.tar.xz
-rw-r--r-- 1 root 1.3M Apr  5 19:36 /var/cache/pacman/pkg/xorg-server-1.18.3-1-x86_64.pkg.tar.xz
$ ls -l /tmp/.X11-unix
total 0
srwxrwxrwx 1 root root 0 Apr  5 21:22 X0
\nterra-arch
connect(4, {sa_family=AF_LOCAL, sun_path=@"/tmp/.X11-unix/X0"}, 20) = 0
getpeername(4, {sa_family=AF_LOCAL, sun_path=@"/tmp/.X11-unix/X0"}, [20]) = 0
uname({sysname="Linux", nodename="terra-arch", ...}) = 0
access("/home/phil/.Xauthority", R_OK)  = 0
open("/home/phil/.Xauthority", O_RDONLY) = 5
fstat(5, {st_mode=S_IFREG|0600, st_size=55, ...}) = 0
read(5, "
ls -alhgtr /var/cache/pacman/pkg/xorg-*
...
-rw-r--r-- 1 root  27K Mar 25 10:01 /var/cache/pacman/pkg/xorg-server-common-1.18.2-4-x86_64.pkg.tar.xz
-rw-r--r-- 1 root 1.3M Mar 25 10:01 /var/cache/pacman/pkg/xorg-server-1.18.2-4-x86_64.pkg.tar.xz
-rw-r--r-- 1 root 708K Mar 25 10:01 /var/cache/pacman/pkg/xorg-server-xvfb-1.18.2-4-x86_64.pkg.tar.xz
-rw-r--r-- 1 root  17K Apr  1 18:25 /var/cache/pacman/pkg/xorg-xinit-1.3.4-4-x86_64.pkg.tar.xz
-rw-r--r-- 1 root 732K Apr  5 19:36 /var/cache/pacman/pkg/xorg-server-xvfb-1.18.3-1-x86_64.pkg.tar.xz
-rw-r--r-- 1 root  27K Apr  5 19:36 /var/cache/pacman/pkg/xorg-server-common-1.18.3-1-x86_64.pkg.tar.xz
-rw-r--r-- 1 root 1.3M Apr  5 19:36 /var/cache/pacman/pkg/xorg-server-1.18.3-1-x86_64.pkg.tar.xz
$ ls -l /tmp/.X11-unix
total 0
srwxrwxrwx 1 root root 0 Apr  5 21:22 X0
\nterra-arch%pre%%pre%10%pre%MIT-MAGIC-COO"..., 4096) = 55
read(5, "", 4096)                       = 0
close(5)                                = 0
getsockname(4, {sa_family=AF_LOCAL, NULL}, [2]) = 0
fcntl(4, F_GETFL)                       = 0x2 (flags O_RDWR)
fcntl(4, F_SETFL, O_RDWR|O_NONBLOCK)    = 0
fcntl(4, F_SETFD, FD_CLOEXEC)           = 0
poll([{fd=4, events=POLLIN|POLLOUT}], 1, -1) = 1 ([{fd=4, revents=POLLOUT}])
writev(4, [{"...", 12}, {"", 0}, {"MIT-MAGIC-COOKIE-1", 18}, {"...", 2}, {"...", 16}, {"...", 0}], 6) = 48
recvmsg(4, 0x7ffc641c6e80, 0)           = -1 EAGAIN (Resource temporarily unavailable)
%pre%10%pre%MIT-MAGIC-COO"..., 4096) = 55
read(5, "", 4096)                       = 0
close(5)                                = 0
getsockname(4, {sa_family=AF_LOCAL, NULL}, [2]) = 0
fcntl(4, F_GETFL)                       = 0x2 (flags O_RDWR)
fcntl(4, F_SETFL, O_RDWR|O_NONBLOCK)    = 0
fcntl(4, F_SETFD, FD_CLOEXEC)           = 0
poll([{fd=4, events=POLLIN|POLLOUT}], 1, -1) = 1 ([{fd=4, revents=POLLOUT}])
writev(4, [{"...", 12}, {"", 0}, {"MIT-MAGIC-COOKIE-1", 18}, {"...", 2}, {"...", 16}, {"...", 0}], 6) = 48
recvmsg(4, 0x7ffc641c6e80, 0)           = -1 EAGAIN (Resource temporarily unavailable)

Antes da chamada recvmsg, comunica com o socket "/tmp/.X11-unix/X0" e envia um MIT-MAGIC-COOKIE-1 com uma chamada escrita. Em seguida, ele faz um loop para sempre (a chamada recvmsg continua falhando).

Funcionou há pouco tempo, ddd é o único aplicativo que parece ser afetado. Infelizmente, não estou familiarizado com o protocolo de autorização XWindow .

Estou usando o Arch Linux. Não tenho certeza se está relacionado, mas o xorg-server foi atualizado recentemente:

%pre%

/tmp/.X11-unix/X0 existe e pertence a root:

%pre%

Se eu executar sudo ddd , funcionará.

Não tenho certeza se devo escrever um relatório de bug ou se é um erro no meu sistema local. Você pode me ajudar a reduzi-lo?

    

Answer 1

Isso se tornou um problema de configuração. Movendo o diretório ~/.ddd para que ddd usasse uma nova configuração, resolveu o problema.

Isso explica porque funcionou com o sudo, já que ele foi executado como o usuário root que não tinha uma configuração confusa.

Algo que vale a pena mencionar é que minha interpretação da saída strace também não estava correta. É normal ver um loop de recvmsg retornando EAGAIN ("Recurso temporariamente indisponível"). Isso significa apenas que o aplicativo está pesquisando o soquete quanto a eventos. É assim que se comunica com o X11.