ht
2022年2月18日 11時28分
お世話になっております。
現在，Armadillo-840mと液晶モジュール(タッチパネル)を使用し，
Qtを使用したアプリケーションプログラムを動作させています。
(Armadillo-840mとタッチパネルはUSB経由で接続しています)
画面表示更新を行う処理を数時間続けていると，
画面の描画が止まってしまう現象が発生しております。
プログラム自体がハングアップや異常終了しているわけではなく，
タッチパネル操作でのイベントは発生しているようです。
タッチパネルをタッチした時に，
タッチ音を鳴らす処理や，タッチに応じた画面表示更新処理を行っているのですが，
タッチ音は鳴るのですが，画面への描画が行われず，画面の表示に反映されない状態となっているようです。
調査を行っておりますが，
どのように調査を進めていけばよいか悩んでおります。
このような場合，どのような点を調査・確認すれば良いか
ご意見をいただけないでしょうか？
【環境】
製品: Armadillo-840m
液晶モジュール: GTWV050VHB00P
GUIフレームワーク: Qt5(Qt Quick 2.0)
【現状わかっていること】
・画面表示更新を行う処理を数時間続けていると，画面の描画が止まる。
(描画が止まる時間は一定ではなく，1時間程度で再現したり24時間程度止まらないこともある)
・タッチ操作等のイベントは発生する。
・一度アプリケーションプログラムを終了し，再度実行すると表示が更新される状態で動作する。
・QMLプロファイラで確認したところ，「描画」項目では処理が実行されているように見える。
添付画像は正常時と異常時(画面が止まっている状態)の比較なのですが，差異が見られませんでした。
・表示が止まった状態で，取扱説明書に記載の「フレームバッファデバイスにテスト画像を出力」の
コマンド実行すると，添付画像のテスト画像が表示される。
このことより，フレームバッファ以降の描画処理は正しく動作しているように思います。
以上，お手数をおかけしますが，よろしくお願いします。
コメント
at_shinya.koga
アットマークテクノの古賀です。
htさん：
>現在，Armadillo-840mと液晶モジュール(タッチパネル)を使用し，
>Qtを使用したアプリケーションプログラムを動作させています。
>(Armadillo-840mとタッチパネルはUSB経由で接続しています)
>
>画面表示更新を行う処理を数時間続けていると，
>画面の描画が止まってしまう現象が発生しております。
>
>プログラム自体がハングアップや異常終了しているわけではなく，
>タッチパネル操作でのイベントは発生しているようです。
>タッチパネルをタッチした時に，
>タッチ音を鳴らす処理や，タッチに応じた画面表示更新処理を行っているのですが，
>タッチ音は鳴るのですが，画面への描画が行われず，画面の表示に反映されない状態となっているようです。
>
>調査を行っておりますが，
>どのように調査を進めていけばよいか悩んでおります。
>
>このような場合，どのような点を調査・確認すれば良いか
>ご意見をいただけないでしょうか？
以下を拝見すると、アプリケーション自身に要因がある可能性が低くない感じですね。
1時間～24時間程度で発生する症状、ということで、Qt Center のフォーラムで5年ほど前に報告されていた、この症状が似ているなと思いました：
https://www.qtcentre.org/threads/68410-Qt-application-hangs-in-xcb_wait…
この報告の環境は、Red Hat Linux 6 (kernel 2.6.32?) + Qt 4.6 とありますから、お手元で発生してい症状とは違う要因の可能性が大ですが、もし同様な要因であれば、報告者が適用したワークアラウンドが参考になるかも知れません：
https://www.qtcentre.org/threads/68410-Qt-application-hangs-in-xcb_wait…
>【環境】
>製品: Armadillo-840m
>液晶モジュール: GTWV050VHB00P
>GUIフレームワーク: Qt5(Qt Quick 2.0)
>
>【現状わかっていること】
>・画面表示更新を行う処理を数時間続けていると，画面の描画が止まる。
> (描画が止まる時間は一定ではなく，1時間程度で再現したり24時間程度止まらないこともある)
>・タッチ操作等のイベントは発生する。
>・一度アプリケーションプログラムを終了し，再度実行すると表示が更新される状態で動作する。
>・QMLプロファイラで確認したところ，「描画」項目では処理が実行されているように見える。
>添付画像は正常時と異常時(画面が止まっている状態)の比較なのですが，差異が見られませんでした。
>・表示が止まった状態で，取扱説明書に記載の「フレームバッファデバイスにテスト画像を出力」の
> コマンド実行すると，添付画像のテスト画像が表示される。
>このことより，フレームバッファ以降の描画処理は正しく動作しているように思います。
以上、的を外しているかも知れませんが、もし参考になりましたら幸いです。
ご回答ありがとうございます。
> 異常の発生時、/var/log/messages にログが出力されてないでしょうか？
> まずはログの中に、error や warning が無いか確認してみることをおすすめします。
異常発生後，/var/log/messagesの内容を確認しました。
結果，ログの中に異常に関連するerrorやwarningは見つかりませんでした。
また，異常が発生した時刻にはログは出力されていませんでした。
> 1時間～24時間程度で発生する症状、ということで、Qt Center のフォーラムで5年ほど前に報告されていた、
> この症状が似ているなと思いました：
> https://www.qtcentre.org/threads/68410-Qt-application-hangs-in-xcb_wait…
> この報告の環境は、Red Hat Linux 6 (kernel 2.6.32?) + Qt 4.6 とありますから、
> お手元で発生してい症状とは違う要因の可能性が大ですが、
> もし同様な要因であれば、報告者が適用したワークアラウンドが参考になるかも知れません：
> https://www.qtcentre.org/threads/68410-Qt-application-hangs-in-xcb_wait…
情報ありがとうございます。現在確認しております。
派生クラスから基本クラスのPaintEventを呼び出すことで，
メモリリークが発生していたということだと思いますが，
本アプリケーションプログラムでは，PaintEventは明示的に呼び出していないため，
また別の問題かもしれません。
現在，メモリリークに関する調査を検討しております。
以上，よろしくお願いします。
お世話になっております。
タッチパネル画面の描画が止まる件の調査を進めているのですが，
まだ解決できていないため，以下の内容について教えていただけないでしょうか。
【調査した内容】
以下の記事を参考にメモリリークが発生していないか調査を行いました。
https://armadillo.atmark-techno.com/forum/armadillo/1367
まず，mtraceという方法で
メモリリークが発生していないか確認しました。
しかし，Qtライブラリ内でのメモリ確保場所が特定できず，
他のスレッドでのメモリ確保等の情報も含まれているようで，
どのメモリ確保ログが自分の処理で確保した異常かを
判断することが難しい状態です。
次に，valgrindという方法で
メモリリークが発生していないか確認しました。
しかし，valgrindを使用してQtアプリケーションを実行させると，
以下のエラーが発生し，
Qtアプリケーションが終了してしまう挙動になりました。
disInstr(thumb): unhandled instruction: 0xEB0D 0x0585
==8069== valgrind: Unrecognised instruction at address 0x70698cf.
==8069== at 0x70698CE: ??? (in /lib/libfontconfig.so.1.5.0)
==8069== Your program just tried to execute an instruction that Valgrind
==8069== did not recognise. There are two possible reasons for this.
==8069== 1. Your program has a bug and erroneously jumped to a non-code
==8069== location. If you are running Memcheck and you just saw a
==8069== warning about a bad jump, it's probably your program's fault.
==8069== 2. The instruction is legitimate but Valgrind doesn't handle it,
==8069== i.e. it's Valgrind's fault. If you think this is the case or
==8069== you are not sure, please let us know and we'll try to fix it.
==8069== Either way, Valgrind will now raise a SIGILL signal which will
==8069== probably kill your program.
==8069==
==8069== Process terminating with default action of signal 4 (SIGILL)
==8069== Illegal opcode at address 0x70698CF
==8069== at 0x70698CE: ??? (in /lib/libfontconfig.so.1.5.0)
また，メモリリークの調査とは別に，
Qtアプリケーションのどの部分で処理が止まっているかを調査したところ，
現象発生時は，Qtライブラリ内の描画スレッドで止まっているようでした。
(描画スレッドが呼び出すシグナルイベントが実行されなくなることを確認しました)
現在，Qtの描画スレッドのどこで止まっているかを調査するために，
Qtライブラリ内をデバッグできないか検討しております。
【お聞きしたいこと】
①valgrindについて
valgrind起動時のオプション等で，
エラーを回避してvalgrindを使用する方法はあるでしょうか？
valgrindについては，
debianのコンパイル済みのパッケージ(valgrind_3.7.0-6_armhf.deb)を使用しました。
もし，使用したバイナリが良くないということであれば，
Armadillo-840mに適したvalgrindのバイナリの入手方法，
またはソースファイルの入手場所を教えていただけないでしょうか？
エラーとなっている箇所は，Qt側で使用していると思われるライブラリのようなので，
リンクしない，呼び出さない等の対応は難しいです。
②Qtのライブラリ内のデバッグ方法について
Qtライブラリの処理が止まっている箇所を特定するために，
Qtライブラリのソースコードをデバッグしたいと検討しております。
(ブレークポイントを設定したり，ステップ実行等を行いたいです)
Armadilloで使用しているQt(5.0.2)ライブラリ内を
デバッグする方法について教えていただけないでしょうか？
③シグナルイベントが発生しなくなることについて
もし，描画に関連するQtのシグナルイベントが発生しなくなることについて，
同じような情報がありましたら，教えていただけないでしょうか。
以上，よろしくお願いします。
at_shinya.koga
アットマークテクノの古賀です。
htさん：
>タッチパネル画面の描画が止まる件の調査を進めているのですが，
>まだ解決できていないため，以下の内容について教えていただけないでしょうか。
…
>【お聞きしたいこと】
>①valgrindについて
>valgrind起動時のオプション等で，
>エラーを回避してvalgrindを使用する方法はあるでしょうか？
>valgrindについては，
>debianのコンパイル済みのパッケージ(valgrind_3.7.0-6_armhf.deb)を使用しました。
>もし，使用したバイナリが良くないということであれば，
>Armadillo-840mに適したvalgrindのバイナリの入手方法，
>またはソースファイルの入手場所を教えていただけないでしょうか？
ごめんなさい。分かりません。
>②Qtのライブラリ内のデバッグ方法について
>Qtライブラリの処理が止まっている箇所を特定するために，
>Qtライブラリのソースコードをデバッグしたいと検討しております。
>(ブレークポイントを設定したり，ステップ実行等を行いたいです)
>Armadilloで使用しているQt(5.0.2)ライブラリ内を
>デバッグする方法について教えていただけないでしょうか？
Armadillo-800 シリーズで使用している Qt 5.0.2 のソースを用意したうえで、Armadillo-800 上で動作する gdbserver が必要です。実際に試してはいませんが、以下のページが参考になりそうです：
https://doc.qt.io/qtcreator/creator-debugger-operating-modes.html#remot…
https://armadillo.atmark-techno.com/forum/armadillo/1169#comment-1447
https://armadillo.atmark-techno.com/forum/armadillo/1215#comment-1490
>③シグナルイベントが発生しなくなることについて
>もし，描画に関連するQtのシグナルイベントが発生しなくなることについて，
>同じような情報がありましたら，教えていただけないでしょうか。
こちらで把握しているものは、ありません。
ところで、Armadillo-800 シリーズでは、Qt の QPA (Qt Platform Abstraction) はデフォルトで eglfs を使用していますが、環境変数 QT_QPA_EGLFS_DEBUG を指定することで、デバッグ用のログを出力してくれるかも知れません：
https://doc.qt.io/qt-5/embedded-linux.html#eglfs
この環境変数が 5.0.2 で有効かどうか確認していませんが、もし有効であれば、手がかりになる情報をとれるかも知れません。
以上、十分な回答でなく恐縮ですが、もし参考になりましたら幸いです。
ご連絡ありがとうございます。
デバッグを進めたところ，
Qtの描画スレッドで描画を行うのではなく，
Qtのメインスレッドで描画を行うように変更すると，
おそらくですが描画が停止しないということが分かりました。
(過去に24時間以上停止しなかったこともあったため，断言はできない状況です)
さらに，以下のQtのバグレポートの中に，
本件の原因かもしれない情報を見つけました。
Qtのバージョン5.0.0から発生して，5.1.0で改善しているようです。
現在使用しているQtのバージョンは5.0.2なので，この情報に当てはまります。
https://bugreports.qt.io/browse/QTBUG-30663
描画スレッドがスリープ状態から二度と復帰しなくなることがあるといった内容です。
メインスレッドと描画スレッドがアクセスする変数に
ビットフィールドを使用していることが原因だったようです。
Armadillo-840mにおいて，
Qtのバージョンを5.1.0以降にバージョンアップすることは可能でしょうか。
もしバージョンアップが可能であれば，バージョンアップの方法を教えていただけないでしょうか。
なお，描画スレッドではなくメインスレッドで
描画するように変更することも検討しているのですが，
メインスレッドで描画すると描画速度が若干遅くなるようでして，
どのように対処しようか悩んでおります。
koga
アットマークテクノの古賀です。
htさん；
>デバッグを進めたところ，
>Qtの描画スレッドで描画を行うのではなく，
>Qtのメインスレッドで描画を行うように変更すると，
>おそらくですが描画が停止しないということが分かりました。
>(過去に24時間以上停止しなかったこともあったため，断言はできない状況です)
>
>さらに，以下のQtのバグレポートの中に，
>本件の原因かもしれない情報を見つけました。
>Qtのバージョン5.0.0から発生して，5.1.0で改善しているようです。
>現在使用しているQtのバージョンは5.0.2なので，この情報に当てはまります。
>
> https://bugreports.qt.io/browse/QTBUG-30663
>
>描画スレッドがスリープ状態から二度と復帰しなくなることがあるといった内容です。
>メインスレッドと描画スレッドがアクセスする変数に
>ビットフィールドを使用していることが原因だったようです。
うかがっている状況からすると、おっしゃるように、このバグが原因の可能性が高そうですね。
>Armadillo-840mにおいて，
>Qtのバージョンを5.1.0以降にバージョンアップすることは可能でしょうか。
>もしバージョンアップが可能であれば，バージョンアップの方法を教えていただけないでしょうか。
フォーラムの過去の投稿で、Qt5.3 以降のバージョンへの移行について質問を頂いたことがあり、それに対する回答が参考になるかと思います：
https://armadillo.atmark-techno.com/forum/armadillo/2137#comment-3443
なお、この回答で提示している Qt5.4.2 のソースアーカイブのリンクは、現在リンク切れになっており、こちらに移動しているようです：
https://download.qt.io/new_archive/qt/5.4/5.4.2/single/
Qt5.1.0 のソースアーカイブは、こちらです：
https://download.qt.io/new_archive/qt/5.1/5.1.0/single/
なお、上記バグレポートに添付されているパッチを、Qt5.0.2 に適用する、という方策もありかと思います。Qt5.0.2 のビルドについては、以下で提示した三つのページのうち、
https://armadillo.atmark-techno.com/forum/armadillo/1169#comment-1447
をご覧ください。
古賀（2022年3月4日 15時22分）：
>Armadillo-800 シリーズで使用している Qt 5.0.2 のソースを用意したうえで、Armadillo-800 上で動作する gdbserver が必要です。実際に試してはいませんが、以下のページが参考になりそうです：
> https://doc.qt.io/qtcreator/creator-debugger-operating-modes.html#remot…
> https://armadillo.atmark-techno.com/forum/armadillo/1169#comment-1447
> https://armadillo.atmark-techno.com/forum/armadillo/1215#comment-1490
以上、参考になりましたら幸いです。
ところで
>なお，描画スレッドではなくメインスレッドで
>描画するように変更することも検討しているのですが，
>メインスレッドで描画すると描画速度が若干遅くなるようでして，
>どのように対処しようか悩んでおります。
この方式で対処する場合、メインスレッドで描画すると描画速度が若干遅くなるとしたら、描画処理以外の処理で I/O 待ちがあるのが原因かも知れませんね。その場合は、当該処理をメインスレッドから別スレッドへ移す、という方策が可能であれば、それで改善できないだろうか、と思いました。
お忙しいところ，ありがとうございます。
いただいたご意見で現象が改善できないか検討しております。
Qtのバージョンアップについて，
AtmarkDist環境でQtを使用したいと思っているのですが，
度々申し訳ございませんが，
下記の点について教えていただけないでしょうか？
①
ATDE5上で，Qtをクロスコンパイルする方法を教えていただけないでしょうか？
②
もしATDE5でビルドできない場合なのですが，
「Debian Wheezy 環境」でQtのライブラリをビルドしたとして，
そのライブラリをAtmarkDist環境にコピーして使用することは可能でしょうか？
③
Qt 5.0.2をビルドした際のconfigre設定を教えていただけないでしょうか？
以上，よろしくお願いします。
at_kojiro.yamada
2022年2月18日 14時21分
> お世話になっております。
>
> 現在，Armadillo-840mと液晶モジュール(タッチパネル)を使用し，
> Qtを使用したアプリケーションプログラムを動作させています。
> (Armadillo-840mとタッチパネルはUSB経由で接続しています)
>
> 画面表示更新を行う処理を数時間続けていると，
> 画面の描画が止まってしまう現象が発生しております。
>
> プログラム自体がハングアップや異常終了しているわけではなく，
> タッチパネル操作でのイベントは発生しているようです。
> タッチパネルをタッチした時に，
> タッチ音を鳴らす処理や，タッチに応じた画面表示更新処理を行っているのですが，
> タッチ音は鳴るのですが，画面への描画が行われず，画面の表示に反映されない状態となっているようです。
>
> 調査を行っておりますが，
> どのように調査を進めていけばよいか悩んでおります。
>
> このような場合，どのような点を調査・確認すれば良いか
> ご意見をいただけないでしょうか？
異常の発生時、/var/log/messages にログが出力されてないでしょうか？
まずはログの中に、error や warning が無いか確認してみることをおすすめします。