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

일부 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안타깝게도 그것이 무엇을 의미하는지에 대한 어떤 표시도 찾을 수 없습니다 .

답변1

이것은 명확한 답은 아니지만 시작이 되어야 합니다.

Qt의 XCB 플러그인(v 5.9.8)에서 무슨 일이 일어나고 있는지 살펴보았습니다. 생각했던 대로 공유 메모리를 얻을 수 없으면 일반 메모리를 윈도우 백업 저장소로 사용하지만 이 경우에는 여전히 MIT-SHM 확장을 얻으려고 시도합니다. 코드를 약간 수정해서 시도조차 하지 않았지만 분명히 효과가 없었습니다.

마침내 공유 메모리 제한을 늘릴 수 있는지 알아보았습니다. 보라, 증가 shmseg(8에서 16으로 및 shmall)하면 shm 할당이 작동합니다. 이미 실행 중인 애플리케이션을 "적극적으로 소급하여"(분명히)...그리고저것"문제가 있는" 창의 높이가 최대화되더라도 BadAccess 오류는 사라집니다.

shmget어떻게 다른 응용 프로그램의 결함으로 인해 전혀 관련이 없는 응용 프로그램에서 X11 오류가 발생할 수 있는지 이해할 수 없습니다 . 그러나 X11 서버는 shmget또는 이에 상응하는 기능을 호출할 수도 있으며 이러한 호출은 내 Qt 응용 프로그램에서 실패한 것과 같은 이유로 실패할 수 있습니다. 이것이 BadAccess로 보고된다는 것은 다소 이상하지만 할당에 실패한 다운스트림 코드가 널 포인터 수신을 보고할 수도 있다는 것을 누가 알겠습니까?

관련 정보