こんにちは、NXPサポートの皆さん、
私たちはi.MX8MPプラットフォーム上の再現可能なグラフィックス問題を調査しています。
結果:
結果:
malloc(): unaligned tcache chunk detectedグラフィック障害発生後には、無関係なプロセスが時折クラッシュする。
当初、この問題はQt Quickの問題のように見えた。
しかし、テストケースは最小限に絞りました:
QOpenGLWindowQML、シーングラフ、QRhi、テクスチャ、カスタムレンダリングは使用しません。
故障は依然として発生する。
シンプルなネイティブのWayland/EGL/GLES3アプリケーションは安定しています:
wl_egl_window
eglCreateContext
glClear
eglSwapBuffers1920x1080何時間も。
私たちは以下の方法でネイティブのWayland/EGL/GLES3テストを作成しました。
以下のサイズは正常に通過します。
500x500
640x480
800x480
900x540
1024x6001280x720
1280x800OpenGLアプリケーションを起動した後、Westonはクラッシュします:
weston.service: Main process exited
status=11/SEGVThe Wayland connection broke.
Did the Wayland compositor die?これは、ウェストンが最初に衝突したことを示唆している。
正常に動作するシステムと故障しているシステムで異なるライブラリは以下のとおりです。
libGAL.so
libEGL.so
libGLESv2.so6.4.11.p4.4
6.4.11.p4.6一方、年配の方は:
6.4.11.p2.x6.6カーネルで動作します。
Vivante 6.4.11.p4.x には、以下の点に関する既知の問題はありますか?
p2.xとp4.xの間には既知の回帰関係はありますか?
以下の項目について、推奨されるデバッグオプションはありますか?
何かご助言いただければ大変ありがたいです。
Vivanteスタックを使ったカーネル6.18.20でクラッシュを再現できる簡単なテストアプリ(6.4.11.p4.4と6.4.11.p4.6)を添付しました
私はさらに調査を進めた。
カーネル6.6.52とVivante p6.4.11.p4.4の組み合わせは動作します。
カーネル6.18.20とVivante p6.4.11.p4.4の組み合わせでクラッシュする
調査結果は明らかに悪化している。
500x500から1024x600への直接的なサイズ変更だけでも、クラッシュを引き起こすのに十分だ。
クラッシュはOpenGLの処理パス内で、スワップチェーンのサイズ変更直後に発生します。
同時に、systemd-journalのSEGVが再び発生します。
これは単なるアプリのエラーではなく、GL/Wayland/Vivanteスタックにおけるメモリ破損の強い兆候です。
仮説の現状
重要なのは1280x720という解像度だけではない。
むしろ、決定的な要因は「再構成」に直接ジャンプし、その後に「提示」を実行することである。
連続的に小さなサイズ変更を行う方が、直接的なサイズ変更よりもはるかに堅牢です。
ソフトウェアバックエンドは安定しており、問題はハードウェア-GL経路にあることが確認されています。
こんにちは、
Qtの問題よりもVivante/galcoreやバッファ管理の問題です。特にネイティブEGLテストもトリガーし、Westonが最初にクラッシュするプロセスなので。レンダリングターゲットが大きい場合に発生し、p4.xスタックでのみ発生するという事実は、特に興味深い。p2とp4のGAL/GBMの変更点を比較し、バッファの割り当てとインポートに関するgalcore/Westonのデバッグを有効にします。