일부 GTk3 응용 프로그램은 DISPLAY=:0일 때 BadAccess로 인해 중단되지만 DISPLAY=hnam.local:0 또는 심지어 DISPLAY=unix:0이 아닐 때 중단됩니다.

내 XQuartz 환경에 몇 가지 문제가 있고 파악하기 어려운 이상한 이유로 시작되지 않습니다. (대부분) 다시 작동했지만 다양한 문제 해결 시도에서 또 다른 회귀가 발생했을 것입니다.

Epiphany, gtk3-demo-application과 같은 애플리케이션도 zenity --calendar예상대로 실행됩니다. 이제 XCreatePixmap다음 호출을 통해 분명히 발생하는 BadAccess로 인해 중단됩니다 gdk_x11_window_set_icon_list. 이상합니다. 왜냐하면 이것이 XCreatePixmap에 버그가 있을 수 있다고 생각하지 않았기 때문입니다.

더욱 이상한 점은 그것이 사실이라는 것입니다아니요DISPLAY=hnam.local:0unix:0이러한 응용 프로그램을 실행하는 대신 (!)을 사용하면 이런 일이 발생합니다 DISPLAY=:0. 내가 아는 한, 이는 TCP/IP 스택을 통해 연결됩니다. 성능/기능 저하가 XQuartz에서는 실용적이지 않을 수 있으므로 이는 해결 방법으로 허용되지만 여기서 무슨 일이 일어나고 있는지 여전히 이해하고 싶습니다.

privileged_startx나는 이것이 실제로 XQuartz 사용자를 위해 일반적으로 활성화되고 /tmp 아래의 디렉토리 설정을 담당하는 래퍼를 사용하고 있다는 사실과 관련이 있다고 생각합니다 . 기억나지 않는 이유로 몇 년 전에 이 기능을 비활성화했지만 문제 해결 중에 다시 활성화했습니다. 다시 비활성화됐고, 그렇게 한 이후로 또 이상한 일이 일어났습니다. X11 환경을 시작한 후 이전처럼 문제가 되는 응용 프로그램을 시작할 수 있습니다. 몇 분 후에 다시 시작할 때 BadAccess가 발생합니다. 아니면 한 번만 시작하면 후속 시작 시 BadAccess를 유발하는 모든 것이 발생할 수 있습니다. 편집: 하지만 아래를 참조하세요 *)

LAN의 원격 서버로부터의 연결을 허용하도록 X11을 구성했습니다. 나 역시 항상 이렇게 합니다. xhost +x더 엄격한 형태의 연결 제어를 가질 이유가 없기 때문입니다.

문제를 해결하는 동안 내 .Xauthority 파일(루트 소유)에도 간단한 문제가 발생했는데, 이 파일을 다시 소유하고 .Xauthority 파일을 실행하여 문제를 해결했습니다 xauth -b.

위의 증상이 경고의 원인입니까? /tmp 아래 디렉터리에 있는 항목과 관련이 있나요? 아니면 내 .Xauthority 파일에 의심스러운 항목이 있나요? 원격 연결이 아닌 대부분의 로컬 연결에서 작업을 수행하면 규칙을 위반한다는 것이 이상하지 않습니까?

감사해요!

편집: 직접적인 원인을 짐작할 수 있지만 왜 이런 일이 발생하는지에 대한 설명은 아직 없습니다.

내 X11 세션은 xfce4 패널에 의해 "고정"되었습니다. 문제의 XCreatePixmap 호출은 패널의 "창 버튼"에 마운트된 애플리케이션 아이콘과 같이 패널 프로세스가 소유한 드로어블을 대상으로 하는 것 같습니다. 2개의 XDisplay 문자열이 동일한 경우에만 의미가 있습니다. 이는 DISPLAY=unix:0(내가 아는 한 DISPLAY=:0과 동일)을 사용하여 오류를 피할 수 있는 이유를 설명합니다.

내가 말했듯이, 나는 그것이 이전에 왜 작동했는지 여전히 이해할 수 없으며, 지금은 제한된 시간 동안 작동하는 이유는 말할 것도 없습니다. 편집: 나는 또한 xwininfo가 나에게 보여준 것을 오해한 것 같습니다.

XIOErrorExitHandler환경을 확인하는 프로그램을 함께 엮었습니다 . 변수는 계속 시도해야 한다는 것을 알고 있습니다. 이것은 작동하는 것 같습니다.

편집: 예를 들어 실행해도 sudo zenity --calendarBadAccess가 발생하지 않으며 더 이상 올바른 권한이 없는 파일의 방향을 다시 가리킵니다.

*) 편집: 그리고 가장 이상한 관찰: 실제로 실제 지연은 없습니다. 정규 작업 중 하나를 지연하여 시간 측면이 도입되었습니다. 초기 터미널 창을 원하는 화면(연결된 경우)으로 이동하고 WM을 통해 높이를 최대화합니다( xfwm4). 2개 창 중 1개 창(별도의 Konsole5 인스턴스에 속함)의 높이를 변경하면 문제가 발생합니다.창의 초기 높이를 복원하면 사라집니다.. 창을 닫으면 트리거 작업이 다른 창으로 이동합니다.

request_code 133안타깝게도 그것이 무엇을 의미하는지에 대한 어떤 표시도 찾을 수 없습니다 .