Bluetooth 経由でデータを記録するアプリに取り組んでいますが、データを何時間も収集すると断続的にクラッシュします (バグを追跡するのが難しくなります)。
logcat の出力はあまり役に立ちません。
スローされる例外はなく、プロセスが終了した原因の手がかりもありません。
何がうまくいかなかったのか、どうすればわかりますか? logcat によって表示されない例外がスローされていますか? このバグを追跡するにはどうすればよいですか?
質問する
15115 次
3 に答える
13
シグナル 9 は SIGKILL で、プロセスをすぐに終了します (プロセス内のハンドラーは実行されません)。ログ行から、プロセスはそれ自体を強制終了しているため、SIGKILL を発行している外部エージェントではありません。
私の推測 (そして実際の推測) は、プロセス内で実行されているメモリ管理コード (あなたが書いたコードではなく、インフラストラクチャの一部として) が、リソースを使い果たしたと判断しており、唯一の手段は死ぬことです。ログがこの時点に達する前に、さらに多くのメッセージがあると予想されるため、ログ履歴を参照して、この時点より前のプロセスからの有用な警告があるかどうかを確認することをお勧めします。
この直前の行は GC ログで、何らかのメモリ リソースが不足していることを示しています。しかし、ヒープがいっぱいではないように見えるため、割り当てが失敗する可能性は低いようです。割り当てられるオブジェクトが大きすぎてヒープに収まらない場合や、断片化によってオブジェクトが割り当てられなかった場合でも、割り当てエラーが発生する可能性があります。ただし、この場合、より関連性の高いログ メッセージが表示されることを期待しています。
より多くのログを取得すると (必要に応じてアプリの PID でフィルタリングすることもできます)、作業を進めるのに役立つと思います。
于 2012-07-10T20:21:38.603 に答える
0
この問題は、RXjava を使用し、onErrorコールバック メソッドを実装しない場合に発生します。
于 2020-06-18T01:05:50.300 に答える