GDBは難しいナットであることが判明しました

GDBは、これを行うのが難しいツールです。 もちろん、ブルックスが言うように、「ソフトウェア製品開発の品質は、無限のテストではなく、適切な設計によって達成されます。」 ただし、適切な設計では、論理エラー、タイプミス、NULLポインターなどから保護されません。 ここで、GDBなどのコードデバッグツールが役立ちます。 私の目標は、初期段階で多くのエラーを検出する静的コードアナライザーが、それほど有用なツールではないことを示すことです。 テストおよびデバッグフェーズの前であっても、コードでエラーを修正すれば、はるかに優れています。 静的コード分析の利点を実証するために、PVS-Studioアナライザーを使用してGDB内のエラーを調べてみましょう。

はじめに

GCCのチェックに関する最近の良い記事の後、私は同時にGDBに関する記事を書くことにしました。 今回は、記事を書くのが難しくなりました。 どうやらプロジェクトのサイズに影響します。 ただし、ソースコードのサイズを比較することは私にとって困難です。 どちらのプロジェクトにも、データのある大きなテーブルを含むファイルがあります。 これらは、コードサイズとコードの行数に大きく貢献します。 たとえば、GDBプロジェクトには、サイズが5メガバイトのi386-tbl.hファイルがあり、次の形式のテーブルが含まれています。

GCCプロジェクトの実際のコードは、GDBコードのサイズよりも数倍大きいと思います。 GCCを確認すると、記事の十分なエラーを簡単に収集でき、レポートをすばやく調べて、疑わしいものを掘り下げることはしませんでしたが、部外者がコードスニペットを理解することは困難でした。 GDBの場合、よく見る必要がありましたが、それでも疑わしい場所はほとんど見つかりませんでした。

確認する

GDBバージョン7.11.1のソースコードが検証されました。 コードは、Linuxで実行されているPVS-Studioのバージョンによって検証されました。



簡単なリファレンス。 PVS-Studioは、C、C ++、C＃で記述されたソースコードのエラーを検出する商用の静的アナライザーです。 LinuxおよびWindowsで動作します。



PVS-Studio静的アナライザーを使用してGDBをテストするには、いくつかの簡単な手順を実行する必要があります。



0）ドキュメントを読む：「 LinuxでPVS-Studioを実行する方法 」 アナライザーをアセンブリシステムに統合せずに、プロジェクトをすばやく確認できる方法を選択しました。



1）公式リポジトリから最新のソースコードをダウンロードします。

$ git clone git://sourceware.org/git/binutils-gdb.git
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

2）PVS-Studio.cfg構成ファイル、つまりoutput-fileおよびsourcetree-rootパラメーターを変更します。 私の場合：

 exclude-path = /usr/include/ exclude-path = /usr/lib64/ lic-file = /home/andr/PVS-Studio.lic output-file = /home/andr/gdb.log sourcetree-root = /home/andr/binutils-gdb
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

3）ダウンロードしたディレクトリに移動します。

 $ cd binutils-gdb
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

4）Makefileを作成します。

 $ ./configure
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

5）gdbビルドとPVS-Studioアナライザーを実行します。

 $ pvs-studio-analyzer trace -- make -j3
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

6）分析を実行します（PVS-Studio.cfg構成ファイルへのパスを指定）：

 $ pvs-studio-analyzer analyze --cfg /home/andr/PVS-Studio.cfg
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

分析が正常に完了すると、gdb.logログファイルがホームディレクトリに表示され、PVS-Studio Standaloneユーティリティを使用してWindowsで表示できます。 これは私がよく知っているので、まさに私がやったことです。



Linuxでレポートを調べたい場合は、PVS-Studio配布キットにソースコードが含まれているコンバーターユーティリティ（plog-converter）が役立ちます。 ユーティリティは* .plogファイルをさまざまな形式に変換できます（ ドキュメントを参照）。 また、コンバータを自分のニーズに合わせて調整することもできます。



重要な テキストエディタで* .logを直接開いて見ないでください。 ひどいものになります。 このファイルには、多くの冗長で重複した情報が含まれています。 そして、それがこれらのファイルがとても大きい理由です。 たとえば、ある種の警告がhファイルに適用される場合、このhファイルがcppファイルに含まれている回数と同じ回数だけファイルに表示されます。 PVS-Studio Standaloneまたはplog-converterを使用すると、これらのツールはそのような重複を自動的に削除します。



* .logファイルをQtタスクリストファイル形式に変換した後、Qt Creatorでレポートを表示すると便利だとしましょう。 次に、plog-converterユーティリティを次のように使用する必要があります。

 $ plog-converter -t tasklist -o /home/andr/gdb.tasks -r /home/andr/binutils-gdb/ -a GA:1,2,3 /home/andr/gdb.log
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

最初はGA：1,2を使用した方が良いでしょう。 3つすべての警告レベルを含めて、アナライザーの日付を開始することはお勧めできません。



このコマンドを実行すると、 gdb.tasksレポートファイルがホームディレクトリに表示され、Qt Creatorを使用して表示できます。

plog-converterオプションを表示します。

 $ plog-converter --help
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

検証結果

先ほど言ったように、今回はPVS-Studioアナライザーの機能を実証するエラーをほとんど見つけることができませんでした。 私が思うのは、GDBプロジェクトのソースコードの高品質と、それ自体がプログラマーである膨大な数のユーザーによって十分にテストされているため、プログラムの平均的なユーザーよりも注意深い、要求が厳しいという事実にあります。



それにもかかわらず、私が面白いと思うものを見てみましょう。 比較関数のエラーから始めましょう。 このエラーバグを新しいエラーパターンで強調表示します。 私は多くのプロジェクトでこのようなエラーに遭遇し、すぐにこのトピックに関する新しい記事を書くことを計画しています。これは「 最後の行の効果 」 の精神に沿ったものです。



無効な比較関数

 static int psymbol_compare (const void *addr1, const void *addr2, int length) { struct partial_symbol *sym1 = (struct partial_symbol *) addr1; struct partial_symbol *sym2 = (struct partial_symbol *) addr2; return (memcmp (&sym1->ginfo.value, &sym1->ginfo.value, sizeof (sym1->ginfo.value)) == 0 && sym1->ginfo.language == sym2->ginfo.language && PSYMBOL_DOMAIN (sym1) == PSYMBOL_DOMAIN (sym2) && PSYMBOL_CLASS (sym1) == PSYMBOL_CLASS (sym2) && sym1->ginfo.name == sym2->ginfo.name); }
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

警告PVS-Studio： V549 'memcmp'関数の最初の引数は2番目の引数と同じです。 psymtab.c 1580



memcmp（）の最初と2番目の引数は同じです。 明らかにここで彼らは書きたかった：

 memcmp (&sym1->ginfo.value, &sym2->ginfo.value, sizeof (sym1->ginfo.value))
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

正しく機能する不正なコード



静的コードアナライザーは、プログラムのソースコードを操作し、人の観点から間違いがあった場所を見つけることができます。 興味深いことに、エラーにもかかわらず、このコードは幸運のために完全に正しく機能します。 これらの興味深いケースの1つを見てみましょう。

 struct event_location * string_to_explicit_location (const char **argp, ....) { .... /* It is assumed that input beginning with '-' and a non-digit character is an explicit location. "-p" is reserved, though, for probe locations. */ if (argp == NULL || *argp == '\0' || *argp[0] != '-' || !isalpha ((*argp)[1]) || ((*argp)[0] == '-' && (*argp)[1] == 'p')) return NULL; .... }
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

PVS-Studio 警告 ： V528 「char」型へのポインターが「\ 0」値と比較されるのは奇妙です。 おそらく意味：** argp == '\ 0'。 location.c 527



このコードでは次のことに興味があります。

 .... const char **argp .... if (argp == NULL || *argp == '\0' || *argp[0] != '-'
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

リテラル'\ 0'は、空の文字列をチェックするかどうかを確認するときに使用される終端のゼロです。 これを行うには、文字列を含むバッファの最初の要素を確認し、終端にゼロがある場合、文字列は空と見なされます。 これはまさにプログラマーがここでやりたかったことです。 しかし、彼はargp変数が文字へのポインターではなく、ポインターへのポインターであることを考慮しませんでした。



したがって、正しいチェックは次のようになります。

 *argp[0] == '\0'
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

または：

 **argp == '\0'
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

ただし、このコードを書くと

 if (argp == NULL || *argp[0] == '\0' || *argp[0] != '-'
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

それは危険です。 nullポインターのチェックをもう1つ追加する必要があります。

 if (argp == NULL || *argp == NULL || *argp[0] == '\0' || *argp[0] != '-'
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

これでコードは正しいです。 ただし、冗長であることに注意してください。 最初の文字がダッシュ「-」でない場合、文字が何であるかは関係ありません。 とにかく、終端ゼロまたはその他の文字があります。 したがって、次のようにコードを簡素化できます。

 if (argp == NULL || *argp == NULL || *argp[0] != '-'
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

この正しいコードは元々あったコードと同等であることに注意してください：

 if (argp == NULL || *argp == '\0' || *argp[0] != '-'
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

全体の違いは0の書き込み方法にあり、最初の場合はNULLです。 2番目は'\ 0'です。 実際、これは同じことであり、コードは同じように動作します。



おもしろい コードが誤って記述されたという事実にもかかわらず、完全に正しく動作します。



不適切なバッファサイズの計算

 extern void read_memory (CORE_ADDR memaddr, gdb_byte *myaddr, ssize_t len); void java_value_print (....) { .... gdb_byte *buf; buf = ((gdb_byte *) alloca (gdbarch_ptr_bit (gdbarch) / HOST_CHAR_BIT)); .... read_memory (address, buf, sizeof (buf)); .... }
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

PVS-Studio警告： V579 read_memory関数は、ポインターとそのサイズを引数として受け取ります。 間違いかもしれません。 3番目の引数を調べます。 jv-valprint.c 111



このエラーは、おそらくリファクタリング中に発生しました。 ある時点で、コードは次のようなものであることを提案しようと思います。

 gdb_byte buf[gdbarch_ptr_bit (gdbarch) / HOST_CHAR_BIT)]; .... read_memory (address, buf, sizeof (buf));
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

次に、 sizeof（）演算子がバッファのサイズを正しく計算しました。 次に、彼らはalloca（）関数を使用してバッファにメモリを割り当て始めました。 その結果、 sizeof（buf）演算子はバッファーのサイズではなく、ポインターのサイズを計算します。



正しいコードは次のようになります。

 gdb_byte *buf; const size_t size = gdbarch_ptr_bit (gdbarch) / HOST_CHAR_BIT; buf = ((gdb_byte *) alloca (size)); .... read_memory (address, buf, size);
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

しかし、これで終わりではありません。最も興味深いのは、さらに私たちを待っていることです。 私は、エラーの本質とそれがどのように発生する可能性があるかについて説明し始めることにしました。 以下にさらにいくつかの行を表示すると、すべてがより興味深いものになります。

 read_memory (address, buf, sizeof (buf)); address += gdbarch_ptr_bit (gdbarch) / HOST_CHAR_BIT; /* FIXME: cagney/2003-05-24: Bogus or what. It pulls a host sized pointer out of the target and then extracts that as an address (while assuming that the address is unsigned)! */ element = extract_unsigned_integer (buf, sizeof (buf), byte_order);
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

ご覧のとおり、このコードに何か問題があることに最初に気づいたわけではありません。 少なくとも2003年以来、このコードにはエラーが残っています。 彼女がまだ矯正されていない理由は明らかではありません。



私の理解では、このコメントは次の行を参照しています。

 element = extract_unsigned_integer (buf, sizeof (buf), byte_order);
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

extract_unsigned_integer（）関数を呼び出すと、上記と同じエラーが発生しました。



PVS-Studioアナライザーは、次の行にも警告を発行します。V579 extract_unsigned_integer関数は、ポインターとそのサイズを引数として受け取ります。 間違いかもしれません。 2番目の引数を調べます。 jv-valprint.c 117



アナライザーは、 java_value_print（）関数コードでさらに2つの警告を生成します。

• V579 read_memory関数は、ポインターとそのサイズを引数として受け取ります。 間違いかもしれません。 3番目の引数を調べます。 jv-valprint.c 123
• V579 extract_unsigned_integer関数は、ポインターとそのサイズを引数として受け取ります。 間違いかもしれません。 2番目の引数を調べます。 jv-valprint.c 129

ダブル割り当て

 FILE * annotate_source (Source_File *sf, unsigned int max_width, void (*annote) (char *, unsigned int, int, void *), void *arg) { .... bfd_boolean new_line; .... for (i = 0; i < nread; ++i) { if (new_line) { (*annote) (annotation, max_width, line_num, arg); fputs (annotation, ofp); ++line_num; new_line = FALSE; } new_line = (buf[i] == '\n'); fputc (buf[i], ofp); } .... }
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

PVS-Studio警告： V519 「new_line」変数には連続して2回値が割り当てられます。 おそらくこれは間違いです。 行を確認してください：253、256。source.c 256



文字列new_line = FALSE; 意味がありません。 この直後に、 new_line変数の値が別の値に変更されます。 つまり 次のコードスニペットは非常に疑わしいものです。

  new_line = FALSE; } new_line = (buf[i] == '\n');
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

どうやらここで何らかの論理的な間違いが行われたようです。 または、最初の割り当ては不要であり、削除できます。



タイプミス

 int handle_tracepoint_bkpts (struct thread_info *tinfo, CORE_ADDR stop_pc) { int ipa_trace_buffer_is_full; CORE_ADDR ipa_stopping_tracepoint; int ipa_expr_eval_result; CORE_ADDR ipa_error_tracepoint; .... if (ipa_trace_buffer_is_full) trace_debug ("lib stopped due to full buffer."); if (ipa_stopping_tracepoint) trace_debug ("lib stopped due to tpoint"); if (ipa_stopping_tracepoint) trace_debug ("lib stopped due to error"); .... }
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

PVS-Studio警告： V581互いに並んでいる「if」演算子の条件式は同一です。 行を確認してください：4535、4537。tracepoint.c 4537



ipa_stopping_tracepoint変数がTRUEの場合、2つのデバッグメッセージが出力されます。

 lib stopped due to tpoint lib stopped due to error
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

私はコードがどのように機能するかについて詳しくはありませんが、後者の場合、条件はipa_stopping_tracepoint変数ではなくipa_error_tracepoint変数を使用する必要があるように思われます。 コードは次のようになります。

 if (ipa_trace_buffer_is_full) trace_debug ("lib stopped due to full buffer."); if (ipa_stopping_tracepoint) trace_debug ("lib stopped due to tpoint"); if (ipa_error_tracepoint) trace_debug ("lib stopped due to error");
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

breakステートメントは忘れられます



古典的な間違い。 スイッチ内のある場所では、 break ステートメントは忘れられます。

 static debug_type stab_xcoff_builtin_type (void *dhandle, struct stab_handle *info, int typenum) { .... switch (-typenum) { .... case 8: name = "unsigned int"; rettype = debug_make_int_type (dhandle, 4, TRUE); break; case 9: name = "unsigned"; rettype = debug_make_int_type (dhandle, 4, TRUE); case 10: name = "unsigned long"; rettype = debug_make_int_type (dhandle, 4, TRUE); break; .... } .... }
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

PVS-Studio警告：V519「name」変数には値が2回連続して割り当てられます。 おそらくこれは間違いです。 行を確認：3433、3436。stabs.c 3436



「unsigned long」タイプと「unsigned long」タイプのどちらを使用しているかに関係なく、「unsigned long」という名前をタイプに割り当てます。



正しいコードは次のとおりです。

 case 9: name = "unsigned"; rettype = debug_make_int_type (dhandle, 4, TRUE); break;
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

もつれたケース



次のコードでは、2つのcaseの間にbreakステートメントがないため 、 alt変数に値が2回割り当てられます。 しかし、コメントによると、プログラマーは特にbreakを使用していません。 私が理解できないコードを考えてみましょう：

 static int putop (const char *in_template, int sizeflag) { int alt = 0; .... switch (*p) { .... case '{': alt = 0; if (intel_syntax) { while (*++p != '|') if (*p == '}' || *p == '\0') abort (); } /* Fall through. */ case 'I': alt = 1; continue; .... } }
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

PVS-Studio警告：V519「alt」変数には連続して2回値が割り当てられます。 おそらくこれは間違いです。 チェック行：14098、14107。i386-dis.c 14107



だから、コメント/ *失敗。 * /は、ここでbreakステートメントが不要であることを示します。 しかし、 alt変数に値0が割り当てられる理由は明らかではありません。とにかく、変数の値は1に置き換えられます。 さらに、これら2つの割り当ての間では、 alt変数は一切使用されません。 明確ではありません...



ここでは、論理エラーまたは最初の割り当てを削除する必要があります。

おわりに

Linux用の長生きPVS-Studio！ ご覧のとおり、静的解析の利点は、オープンなWindowsプロジェクトだけでなく、オープンプログラムのLinuxコミュニティにも役立ちます。 すぐに、実績のあるプロジェクトに関する記事のリストに 、Linuxの世界のプログラムに関する記事が多数追加されると思います。

面白いものを見逃さないために、 @ Code_Analysisの twitterに登録してください 。





この記事を英語圏の聴衆と共有したい場合は、翻訳へのリンクを使用してください：Andrey karpov。 GDB-クラックするのが難しいナット：PVS-Studioで見つかったバグはわずかです。