1. ホーム
  2. debugging

再現できないバグはどのように修正するのですか?

2023-10-16 06:07:17

質問

質問がすべてを物語っています。複数のユーザーが報告したバグがあるにもかかわらず、ログにそのバグが発生した記録がなく、どんなに頑張ってもそのバグを繰り返すことができない場合、どのように修正するのでしょうか? あるいは、できるのでしょうか?

このようなことは、きっと皆さんの多くに起こっていることでしょう。この状況であなたは何をしましたか、そして最終的な結果はどうなりましたか。


編集してください。 私はむしろ、"em" と "em "の間にある についてどうされたかに興味があります。 について何が行われたかに興味があります。解決不可能なバグとは、少なくとも問題があることがわかり、ほとんどの場合、それを探すための出発点があるようなバグです。解決できないバグの場合、あなたは何をすればいいのでしょうか?何かできることはありますか?

どうすれば解決できるのか?

言語

異なるプログラミング言語には、それぞれのバグの特徴があります。

C

デバッグステートメントを追加することで、問題を を複製することが不可能になります。 として知られている SEGFAULT を回避するために、デバッグ ステートメント自体がポインタを十分に移動させるからです。 ハイゼンバグ . ポインターの問題を追跡し再現するのは困難ですが、デバッガを使用することで解決できます (たとえば GDB DDD ).

Java

複数のスレッドを持つアプリケーションは、非常に特定のタイミングまたはイベントのシーケンスでのみバグが表示されるかもしれません。不適切な並行処理の実装は、再現が困難な状況においてデッドロックを引き起こす可能性があります。

JavaScript

一部のウェブブラウザは、メモリリークで悪名高いです。あるブラウザで正常に動作する JavaScript コードが、別のブラウザで不正な動作を引き起こすかもしれません。何千人ものユーザーによって厳密にテストされたサードパーティのライブラリを使用すると、特定の不明瞭なバグを回避するのに有利になることがあります。

環境

バグがある)アプリケーションが動作している環境の複雑さによっては、環境を簡素化することが唯一の手段であるかもしれません。アプリケーションは実行されますか。

  • サーバー上で動作していますか。
  • デスクトップで?
  • Web ブラウザーで?

アプリケーションはどのような環境で問題を発生させますか?

  • 開発ですか?
  • テスト?
  • プロダクション?

余計なアプリケーションの終了、バックグラウンド タスクの終了、すべてのスケジュールされたイベント (cron ジョブ) の停止、プラグインの削除、およびブラウザーのアドオンのアンインストールを実行します。

ネットワーキング

ネットワークは非常に多くのアプリケーションに不可欠なものです。

  • ワイヤレス信号を含む、安定したネットワーク接続を確保する。
  • ネットワーク障害の後、ソフトウェアが堅牢に再接続するか。
  • すべての接続は、ファイル記述子を解放するように適切に閉じられますか?
  • 使用すべきでない人がマシンを使用していないか?
  • 不正なデバイスがマシンのネットワークと相互作用していないか?
  • 干渉を引き起こす可能性のある工場や電波塔が近くにありませんか?
  • パケットサイズと周波数は公称範囲内か?
  • パケットは を監視していますか? ?
  • すべてのネットワーク デバイスは、大量の帯域幅の使用に対して適切ですか?

一貫性

未知な部分をできるだけなくす。

  • アーキテクチャのコンポーネントを分離する。
  • 必要のない、またはおそらく問題のある (競合する) 要素を削除します。
  • 異なるアプリケーション モジュールを非アクティブにします。

本番、テスト、開発間のすべての差異を取り除く。同じハードウェアを使用します。まったく同じ手順で、完璧に、コンピュータをセットアップすること。一貫性が重要です。

ログ記録

イベントが発生した時刻を関連付けるために、大量のログを使用します。明らかなエラーやタイミングの問題などがないか、ログを調べます。

ハードウェア

ソフトウェアに問題がないようであれば、ハードウェアの不具合を検討します。

  • 物理的なネットワーク接続はしっかりとしていますか。

    • 物理的なネットワーク接続はしっかりしていますか
    • ケーブルが緩んでいませんか?
    • チップは正しく取り付けられているか。
    • すべてのケーブルはきれいに接続されていますか?
    • 作業環境は清潔で、ほこりのないものですか?
    • 隠しデバイスやケーブルは、ネズミや齧歯類によって損傷されていないか? 昆虫 ?
    • ドライブに不良ブロックはありませんか?
    • CPU ファンは動作していますか?
    • マザーボードはすべてのコンポーネントに電力を供給できますか? (CPU、ネットワーク カード、ビデオ カード、ドライブ、その他)
    • 可能性 電磁波障害 が原因なのでしょうか?

    そして、ほとんどが埋め込み用です。

    • 供給バイパスの不足?
    • 基板の汚れ?
    • はんだ接合不良/リフロー不良?
    • 電源電圧が許容範囲外の場合、CPU がリセットされない?
    • 電源レールが I/O ポートからバックパワーされ、完全に放電されないため、リセットの不良が発生する?
    • ラッチアップ?
    • 入力端子はフローティングですか?
    • ロジック レベルでの十分な (場合によっては負の) ノイズ マージンですか?
    • タイミングマージンが不十分(負になることがある)?
    • 錫のウィスカー ?
    • ESDダメージ?
    • ESDによるアプセット?
    • チップのエラッタ?
    • インターフェースの誤使用 (例: I2C のオフボードまたは高出力信号の存在下)?
    • レース コンディション?
    • 部品の偽造?

    ネットワーク vs. ローカル

    アプリケーションをローカルに (つまり、ネットワークを介さずに) 実行するとどうなりますか。他のサーバーでも同じ問題が発生していますか? データベースはリモートですか? ローカルのデータベースを使用することはできますか?

    ファームウェア

    ハードウェアとソフトウェアの間にあるのがファームウェアです。

    • コンピューターの BIOS は最新のものですか?
    • BIOS のバッテリは動作していますか?
    • BIOS のクロックとシステム クロックは同期していますか?

    時刻と統計情報

    タイミングの問題は追跡が困難です。

    • 問題はいつ発生するのか?
    • どのくらいの頻度で発生しますか?
    • その時、他にどのようなシステムが稼働していますか?
    • アプリケーションは時間に敏感か (たとえば、閏日や閏秒が問題を引き起こすか)。

    問題についての確かな数値データを収集します。最初はランダムに見える問題でも、実はパターンがある場合があります。

    変更管理

    システムのアップグレード後に問題が発生することがあります。

    • 問題が最初に発生したのはいつですか。
    • 環境 (ハードウェアとソフトウェア) で何が変わりましたか?
    • 以前のバージョンにロールバックした後、何が起こりますか。
    • 問題のあるバージョンと良好なバージョンの間にはどのような違いがありますか。

    ライブラリの管理

    オペレーティングシステムによって、競合するライブラリを配布する方法は異なります。

    • Windows は DLL地獄 .
    • Unix では、壊れたシンボリック リンクが多数存在する可能性があります。
    • Java ライブラリ ファイルも同様に、解決するのが難しい場合があります。

    オペレーティング システムの新規インストールを実行し、アプリケーションに必要なサポート ソフトウェアのみを含めます。

    Java

    すべてのライブラリが一度だけ使用されることを確認します。アプリケーションコンテナには、アプリケーション自身と異なるバージョンのライブラリがあることがあります。これは、開発環境では再現できないかもしれません。

    のようなライブラリ管理ツールを使用します。 メイブン または アイビー .

    デバッギング

    バグが発生したときに通知(ログ、電子メール、ポップアップ、ポケットベルのビープ音など)をトリガーする検出方法をコード化する。自動化されたテストを使用して、アプリケーションにデータを送信します。ランダムなデータを使用する。既知のケースと起こりうるエッジケースをカバーするデータを使用する。最終的には、バグが再び現れるはずです。

    スリープ

    他の人が言っていたことを繰り返す価値があります。問題から離れて時間を過ごし、他の仕事 (文書作成など) を終わらせましょう。コンピュータから物理的に距離を置き、運動をする。

    コードレビュー

    コードを一行ずつ見ていき、各行が自分自身、同僚、あるいは ラバーダック . これは、バグを再現する方法についての洞察につながるかもしれません。

    宇宙線

    宇宙線 はビットを反転させることができます。これは、メモリの近代的なエラー チェックにより、過去にはそれほど大きな問題ではありませんでした。地球の保護を離れたハードウェアのソフトウェアは、宇宙線のランダム性により、単純に再現できない問題に直面します。

    ツール

    まれではありますが、コンパイラがバグを引き起こすことがあります。特にニッチなツール (例: シンボルテーブルのオーバーフローに悩まされる C マイクロコントローラコンパイラ) ではそうです。別のコンパイラを使うことは可能でしょうか?ツールチェーン内の他のツールが問題を引き起こしている可能性はありますか?