タグ付けされた質問 「debugging」

デバッグとは、プログラムの実行中に、通常はデバッグツールを使用して、プログラムの状態を調べ、異常な動作を引き起こすバグを見つけようとするプロセスです。

4
Javaでデバッグ出力を処理する正しい方法は何ですか?
私の現在のJavaプロジェクトがますます大きくなるにつれて、コードのいくつかのポイントにデバッグ出力を挿入する必要性が同様に高まっていると感じています。 テストセッションの開始または終了に応じて、この機能を適切に有効または無効にするには、通常private static final boolean DEBUG = false、テストで検査するクラスの先頭にa を付け、この方法で(たとえば)簡単に使用します。 public MyClass { private static final boolean DEBUG = false; ... some code ... public void myMethod(String s) { if (DEBUG) { System.out.println(s); } } } など。 もちろん、それはうまくいきますが、数個を見つめていなければ、DEBUGをtrueに設定するクラスが多すぎる可能性があります。 逆に、出力されるテキストの量が圧倒的になる可能性があるため、私は(他の多くの人と同じように)アプリケーション全体をデバッグモードにすることを好みません。 だから、そのような状況をアーキテクチャ的に処理する正しい方法がありますか、最も正しい方法はDEBUGクラスメンバーを使用することですか?



3
「デコイ」機能または意図的なバグの用語は何ですか?[閉まっている]
俗語のプログラミング用語を忘れてしまいました。これは意図的なバグまたは気晴らしとして使用されるおとり機能です。使用例は、「ボブ、QAが今日レビューを行っています。$THING実際に見つけるべき問題があるようにモジュールに入れてください」。 これは、実際の問題から注意をそらすものとして発見するための非常に明白な意図的な欠陥を持つために、否定的に使用することができます。 これも積極的に使用できます。被災地を捜索するときに、常に救助犬に被害者を「見つけさせる」方法と同じです。また、QAプロセスが実際に欠陥をキャッチしていることを確認するためにも使用できます。 私が探している用語は何ですか?

10
新しいプログラマーがコンパイラーのエラーメッセージ/ランタイム例外メッセージを無視するように見えるのはなぜですか?[閉まっている]
私たちは皆これを見たと思います。初心者は、基本的な概要に従うStack Overflowで質問をします... 私はやろうとしています(目標の非常に漠然とした説明)がうまくいきません/エラー/例外が発生します。助けてください! 彼らの多くがエラーメッセージを貼り付ける必要がないと考えるのは奇妙ではないでしょうか? これの心理学は何だろうか。人々が最初は役に立たず、注意を払う価値がないと思わせるエラーメッセージについてはどうですか? 私が探している答えは、「彼らはエラーメッセージを理解していません」ではありません。それは、彼らがそれを理解するかもしれない他の誰かに話すことを考慮しない理由を説明しません。

7
戻り値の計算とreturnステートメントを1行のメソッドに分割しますか?
私は同僚returnと、ステートメントと、戻り値を2行で計算するステートメントを壊すことについて議論しました。 例えば private string GetFormattedValue() { var formattedString = format != null ? string.Format(format, value) : value.ToString(); return formattedString; } の代わりに private string GetFormattedValue() { return format != null ? string.Format(format, value) : value.ToString(); } コードに関しては、最初のバリアントには値が実際には表示されません。私にとって、後者は、特に短い方法の場合、より明確です。彼の主張は、前者のバリアントの方がデバッグが簡単だということでした-VisualStudioではブレークポイントにより実行が停止したときにステートメントを非常に詳細に検査できるため、これは非常に小さなメリットです。 私の質問は、それでもデバッグを一見するのを簡単にするためだけに、あまり明確でないコードを書くのが有効なポイントであるなら?それ以上の引数があるため、分割計算とを有する変異体returnのステートメントは?

2
JSPをデバッグするにはどうすればよいですか?
プロジェクトのJSPを編集しようとしていますが、サーバーから要求されたときに、JSPのどこかでNullPointerExceptionが発生します。 私のWebサーバー(JBoss)は例外を報告していますが、偽の行番号を教えてくれます。702行目で例外が発生したことが報告されていますが、JSPの長さは146行しかないため、どの行が窒息しているかを特定できません。 JSPのエラーをデバッグするための良いテクニックは何ですか?IDEとしてIntelliJ 9 Ultimateを使用しています。 ありがとう
26 java  ide  debugging  jsp  intellij 

7
デッドロックをデバッグするときに何を探しますか?
最近、スレッドを多用するプロジェクトに取り組んでいます。私はそれらを設計してもいいと思います。ステートレス設計を可能な限り使用する、複数のスレッドが必要とするすべてのリソースへのアクセスをロックする、など。関数型プログラミングの私の経験は非常に役立ちました。 しかし、他の人のスレッドコードを読むと、混乱します。私は今、デッドロックをデバッグしています。コーディングスタイルとデザインは私の個人的なスタイルとは異なるため、潜在的なデッドロック状態を見つけるのは困難です。 デッドロックをデバッグするときに何を探しますか?

3
非同期/待機デッドロックを診断するにはどうすればよいですか?
私はasync / awaitを多用する新しいコードベースで作業しています。私のチームのほとんどの人は、async / awaitにかなり慣れていません。私たちは一般的にMicrosoftによって指定されたベストプラクティスを保持する傾向がありますが、一般的には非同期呼び出しを通過するためにコンテキストが必要で、そうでないライブラリを使用していConfigureAwait(false)ます。 それらすべてを組み合わせて、毎週記事で説明されている非同期デッドロックに遭遇します。模擬テストされたデータソース(通常はを介してTask.FromResult)はデッドロックをトリガーするのに十分ではないため、ユニットテスト中には表示されません。そのため、実行時または統合テスト中に、一部のサービスコールは昼食に出て戻りません。それはサーバーを殺し、一般的に混乱をもたらします。 問題は、間違いがどこで発生したかを追跡すること(通常は完全に非同期ではないこと)には、通常、手作業のコード検査が含まれ、時間がかかり、自動化できないことです。 デッドロックの原因を診断するより良い方法は何ですか?
24 c#  debugging  async 

13
より良いバグ修正ツールになる
プログラマーであることが大好きです。そこで、私はそれを言った。しかし、そうは言っても、私は本当にバグ修正に耐えられないことに最近気付きました。まったく。 実際、私は何かを開発している間、私の生産性は非常に高いです。単体テストを作成し、開発の自己テストを行う場合でも、私は一般的に本当に生産的です。私はうまく集中することができ、タスクを完了することができます。 ただし、QAの時間が来て、バグの修正に取り組んでいるとき、私のインスピレーションは非常に急降下します。何かを成し遂げるには、かなり極端な手段(BPMの高い音楽、カフェインの過剰な量など)を強制する必要があります。私の仕事は通常、既存の大規模なプロジェクトに足を踏み入れ、新しい機能を追加したり、バグを修正したりすることです。そのため、すべてのコードのユニットテストを書くのに数週間かかることを雇用主に正確に伝えることはできません:)私たちがよく使用するサーバー技術は、ユニットテストと統合テストの両方で非常に禁止されています。Javaクラスローダーの問題がかなりあるからです。私は完全にバグ修正に反対しているわけではありません。時には楽しいこともありますが、まったく楽しくはありません。 マイナーな変更を加え、それらが機能するかどうかを確認できるように30秒から3分間待機する必要がある場合(システムの動作方法による)。 バグ修正時の生産性とモチベーションを改善するにはどうすればよいですか?これはほとんどのプログラマーが対処するものですか?

16
優れたプログラマーになるには、デバッグスキルが重要ですか?
ロックされています。この質問とその回答はロックされています。なぜなら、質問はトピックから外れていますが、歴史的に重要だからです。現在、新しい回答やインタラクションを受け入れていません。 プログラマーは、他の品質とともに、優れたデバッグスキルを必要としますか?特定のプログラムでエラーを見つけることができなかったが、すべてのパズルとプログラムを解決できた応募者がいる場合、その仕事を検討する必要がありますか? 編集:-パズルは、通常の赤、青、赤青のボールのようなものです。プログラムは、配列内で連続したk個のゼロを見つけるようなものです。デバッグプログラムは、> =である必要がある条件のために失敗するものですが、代わりに>です。すべてが紙の上にあります。
24 debugging 

5
メモリ破損のデバッグ
まず最初に、これは絶対的な答えのある完璧なQ&Aスタイルの質問ではないことを理解していますが、それを改善するための表現は考えられません。これに対する絶対的な解決策はないと思います。これが、Stack Overflowではなくここに投稿する理由の1つです。 先月、私はかなり古いサーバーコード(mmorpg)をより近代的で拡張/修正しやすいものに書き換えました。私はネットワーク部分から始め、サードパーティのライブラリ(libevent)を実装して、自分のものを処理しました。すべてのリファクタリングとコードの変更により、どこかでメモリ破損が発生し、どこで発生するかを見つけるのに苦労しています。 原始的なボットを実装して負荷をシミュレートしても、クラッシュが発生しない場合でも、開発/テスト環境で確実に再現することはできません(何らかの原因で発生したlibeventの問題を修正しました) 私はこれまで試しました: 地獄を破壊する-ものがクラッシュするまで無効な書き込みはありません(実稼働では1日以上かかる場合があります。1時間かかる場合があります)。これは本当に私を困惑させます。チャンス?(アドレス範囲を「広げる」方法はありますか?) コード分​​析ツール、すなわちコベリティとcppcheck。彼らはいくつかの..を指摘しましたが、コードの厄介さとエッジケースは深刻なものではありませんでした。 (undodbを介して)gdbでクラッシュするまでプロセスを記録し、逆方向に作業します。この/ sounds /は実行可能であるはずですが、オートコンプリート機能を使用してgdbをクラッシュさせるか、可能性のあるブランチが多すぎるために失われる内部libevent構造になります(1つの破損が原因でに)。ポインターが元々どの場所に/どこに割り当てられていたのかを見ることができれば、ブランチの問題のほとんどを解消できると思います。ただし、undodbを使用してvalgrindを実行することはできません。通常のgdbレコードは、使用できないほど遅くなります(valgrindと組み合わせても機能する場合)。 コードレビュー!自分で(完全に)そして何人かの友人に私のコードを見てもらうことで、それが十分に徹底的だったとは思いませんが。コードレビュー/デバッグを行うために開発者を雇うことを考えていましたが、多額の資金を投入する余裕はありません。彼が問題を見つけられなかったり、資格を持っている人がいなければ、お金はありません。 また、注意する必要があります。通常、一貫したバックトレースが取得されます。クラッシュが発生する場所はいくつかありますが、大部分は何らかの理由でソケットクラスが破損することに関連しています。ソケットではない何かを指している無効なポインタか、ソケットクラス自体が(部分的に)意味不明なもので上書きされています。よく使用される部品の1つであるため、クラッシュが最も多いと思われますが、使用されるのは最初に破損したメモリです。 全体として、この問題はほぼ2か月間(忙しく、趣味のプロジェクトが多い)忙しく、不機嫌なIRLになり、あきらめることを考えるほどイライラしています。私は問題を見つけるために他に何をすべきかについて考えることができません。 見逃した便利なテクニックはありますか?どのように対処しますか?(これについてはあまり情報がないため、それほど一般的ではありません..または私は本当に盲目ですか?) 編集: 重要な場合の仕様: gcc 4.7を介したc ++(11)の使用(debian wheezyが提供するバージョン) コードベースは約15万行です david.pfx投稿への応答で編集:(応答が遅くなって申し訳ありません) パターンを探すために、クラッシュの注意深い記録を保持していますか? はい、私はまだ周りの最近のクラッシュのダンプを持っています いくつかの場所は本当に似ていますか?どのように? さて、最新バージョン(コードを追加/削除したり、関連する構造を変更するたびに変更されるようです)では、常にアイテムタイマーメソッドでキャッチされます。基本的に、アイテムには期限が切れる特定の時間があり、更新された情報をクライアントに送信します。無効なソケットポインタは、主にそれに関連するPlayerクラス(私の知る限り有効)にあります。また、クリーンアップフェーズで、明示的に破棄されていないすべての静的クラスを(__run_exit_handlersバックトレースで)破棄する通常のシャットダウンの後、クラッシュの負荷が発生しています。ほとんどの場合std::map、1つのクラスが関与しますが、それが最初に現れるのは単なる推測です。 破損したデータはどのように見えますか?ゼロ?アスキー?パターン? まだパターンが見つかりませんでした。破損がどこから始まったのかわからないので、わかりにくいです。 ヒープ関連ですか? それは完全にヒープ関連です(gccのスタックガードを有効にしましたが、何もキャッチしませんでした)。 破損は後に発生しfree()ますか? 少し詳しく説明する必要があります。すでに解放されたオブジェクトのポインターが横になっているということですか?オブジェクトが破棄されると、すべての参照をnullに設定するので、どこかで見逃さない限り、いいえ。valgrindには表示されますが、表示されませんでした。 ネットワークトラフィック(バッファサイズ、リカバリサイクル)に特有のものはありますか? ネットワークトラフィックは生データで構成されます。したがって、char配列、(u)intX_tまたはより複雑なもののための(パディングを削除するための)パックされた構造体には、各パケットに、予想されるサイズに対して検証されるidおよびパケットサイズ自体で構成されるヘッダーがあります。サイズは10〜60バイトで、最大の(内部「起動」パケット、起動時に1回起動される)サイズは数Mbです。 多くの生産が主張します。損傷が伝播する前に、早期かつ予想どおりにクラッシュします。 私はかつてstd::map破損に関連したクラッシュを経験しました。各エンティティには「ビュー」のマップがあり、それを見ることができる各エンティティはその中にあります。前後に200バイトのバッファーを追加し、0x33で埋め、各アクセスの前にチェックしました。腐敗は魔法のように消え去りました。私は何かを動かして、他の何かを腐敗させたに違いありません。 戦略的なロギング。これにより、直前に何が起こっていたかを正確に把握できます。回答に近づいたら、ログに追加してください。 それは機能します。 必死になって、状態を保存して自動再起動できますか?私はそれを行う生産ソフトウェアのいくつかの部分を考えることができます。 やややる。このソフトウェアは、メインの「キャッシュ」プロセスと、すべてのものを取得して保存するためにすべてキャッシュにアクセスする他のワーカープロセスで構成されています。そのため、クラッシュごとに大きな進歩を失うことはありません。それでもすべてのユーザーが切断されるなど、間違いなく解決策ではありません。 並行性:スレッド化、競合状態など 「非同期」クエリを実行するmysqlスレッドがありますが、これはすべてそのままで、すべてのロックを備えた関数を介してデータベースクラスと情報を共有するだけです。 割り込み 30秒間のサイクルを完了しなかった場合に停止するロックを防ぐための割り込みタイマーがありますが、そのコードは安全なはずです: if (!tics) { abort(); } else …
23 c++  debugging  memory 

12
プロジェクトの最後にバグを修正するのはかなり費用がかかりますか?
でアンドリュー・ヘイにより、ブログ記事、以下の公理を仮定しました。 プロジェクトの最後に同じバグを修正するよりも、プロジェクトの最後にバグを修正する方が大幅にコストがかかります。 しかし、特にLess Wrongのブログ投稿を読んだ後、これは確実ではないようで、私がそれをバックアップするのを見たデータは非常に古いです。 これは今日でも公理は正確ですか?

5
保護されたメモリの前にどのようにセグメンテーションフォールトをデバッグしましたか?
さて、Cのポインターでプログラミングの間違いを犯すと、いいセグメンテーションフォールトが発生し、プログラムがクラッシュし、デバッガーはどこが間違っているのかを教えてくれます。 メモリ保護が利用できなかったとき、彼らはどうやってそれをしましたか?DOSプログラマーが、ミスをしたときにOS全体をいじり、クラッシュさせるのを見ることができます。仮想化は利用できなかったため、再起動して再試行するだけでした。それは本当にそのように行きましたか?

5
データベーステーブルはいつタイムスタンプを使用する必要がありますか?
まず、この質問はデータベース交換に属していると思いましたが、データベースよりもプログラミングソリューション全体に関連していると思います。人々がそれを最高だと思うなら、データベース交換に移行します。 データベーステーブルに作成および更新されたタイムスタンプをいつ追加する必要があるのか​​疑問に思いましたか? 最初の明らかな答えは、何かが更新されたとき(トランザクション完了日など)をビジネスロジックが知る必要がある場合、それを入力する必要があるということです。 しかし、非ビジネスロジックの場合はどうでしょうか。たとえば、いくつかのビジネスロジックが失敗し、関連するデータベースの行を確認して、1つの行が更新される前に識別することができるなど、障害の検出に役立つように行が変更された日時を知ることが本当に役立つシナリオを考えることができますエラーの原因となっている別の行。 このユースケースでは、すべてのテーブルに更新を与えてタイムスタンプを作成することは理にかなっています(アプリケーションのどの部分によっても更新されない最も単純な列挙テーブルを除く)。 すべてのテーブルにタイムスタンプを与えることは、間違いなくデータベースをすぐに停止させる素晴らしい方法です。 それでは、データベーステーブルはいつタイムスタンプの作成と更新を使用すべきですか?

弊社のサイトを使用することにより、あなたは弊社のクッキーポリシーおよびプライバシーポリシーを読み、理解したものとみなされます。
Licensed under cc by-sa 3.0 with attribution required.