一部の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は発生せず、正しい権限を持たないファイルの方向をもう一度指します。

*)編集:そして最も奇妙な観察:実際には実際の遅れはありません。通常の作業の1つを遅らせることによって時間の側面が導入されました。初期端末ウィンドウを目的の画面(接続されている場合)に移動し、WMを介して高さを最大化します(xfwm4)。 2つのウィンドウのうち1つのウィンドウ(別々のKonsole5インスタンスに属する)の高さを変更すると問題が発生します。ウィンドウの初期高さを復元すると消えます。。ウィンドウを閉じると、トリガー操作は別のウィンドウに移動します。

request_code 133残念ながら、それが何を意味するのかについては何も表示されません。

ベストアンサー1

これは明確な答えではありませんが、始めるべきです。

QtのXCBプラグイン(v 5.9.8)で何が起こっているのか見ました。思ったように共有メモリを取得できない場合は、通常のメモリをWindowsバックアップストアとして使用しますが、この場合はまだMIT-SHM拡張を取得しようとします。コードを少し変更して試してみませんでしたが、明らかにうまくいきませんでした。

最後に、共有メモリの制限を増やすことができるかどうかを調べました。見て、増やすshmseg(8から16へshmall)、shm割り当てが機能します。すでに実行しているアプリケーションを「積極的に遡って」(明らかに)...そしてそれ「問題のある」ウィンドウの高さが最大になっても、BadAccessエラーは消えます。

shmget他のアプリケーションの欠陥によってまったく関連のないアプリケーションでX11エラーが発生する可能性を理解することはできません。ただし、X11サーバーはまたはshmgetそれに対応する機能を呼び出すことができ、これらの呼び出しは私のQtアプリケーションで失敗したのと同じ理由で失敗する可能性があります。これがBadAccessとして報告されることは多少奇妙ですが、割り当てに失敗したダウンストリームコードがNULLポインタの受信を報告する可能性があることを誰が知っていますか?

おすすめ記事