命名されたISP RASの公開会議の前夜のPVS-Studioについて V.P. イヴァンニコワ

科学者コミュニティは、PVS-Studio静的コードアナライザーを実際には使い慣れていません。 11月30日と12月1日に、「プログラムの分析、モデリング、変換の技術」というイベントが、ISP RASにちなんで名付けられた公開会議の一部として開催されます。 V.P. イヴァンニコワ。 これは私たちにとって最もテーマのあるイベントの1つであり、新しい視聴者がPVS-Studioアナライザーの存在と機能について学ぶことができると確信しています。 私の意見では、これに最も関連するのは、Tizenオペレーティングシステムでのエラーの検索に関するレポートです。 残念ながら、このレポートはレビュー担当者から否定的なレビューを受けており、会議プログラムには含まれません。 それにもかかわらず、私はこの機会を利用して、Tizenコードに関する調査を要約します。









過去（2016年）、私たちはISP RASの名前にちなんで名付けられた公開会議に出席しました V.P. Ivannikovは、Tizenオペレーティングシステムに多くの注意が払われていることに気付きました。









→ ビデオリンク



Tizenは、IntelやSamsungなどの企業によって開発および管理されているオープンソースのLinuxカーネルエンジンです。



オープンソースプロジェクトをサポートし、PVS-Studio静的アナライザーと静的分析手法全体の普及により、プロジェクトの信頼性を高めています。 この目的のために、オープンプロジェクトの分析に関する記事を作成し、静的分析のツールを普及させます。 コンテストを開催します 。 特定の条件などに応じて無料のライセンスを提供します。 特に、私たちはいくつかのオープンソースプロジェクトで個別の作業を行い、それらに関係する人々に無料のライセンスとサポートを提供しています。



2016年の会議に参加する前は、Tizenが存在すること以外は何も知りませんでした。 しかし、その後、このオペレーティングシステムを使用して、オープンソースプロジェクトの開発者の間で静的分析手法を普及させることができると考えました。 同時に、これはPVS-Studioアナライザーの機能をもう一度実証する良い方法です。



その結果、一連の記事がTizenオペレーティングシステムに登場しましたが、そのうちの記事「 Tizenオペレーティングシステムでの27,000エラー 」が最も興味深いものです。 その他の記事：

1. Tizenコードの例を使用して、マイクロ最適化について話しましょう 。
2. Tizen：C＃コンポーネントは高品質であることが判明しました 。
3. Tizen：要約する 。
4. EFLコアライブラリの例を使用したPVS-Studioアナライザーの特性、誤検知の10〜15％ 。

記事は、アナライザーがTizenオペレーティングシステムコードの品質を大幅に改善できることを示しています。



行われたすべての作業の論理的結論は、会議での私たちの報告かもしれません。



しかし、読者は正しく尋ねることができます。なぜPVS-StudioアナライザーはTizenコードを改善できると思いますか？



私が説明したエラー（またはそれらのほとんど）は開発者によって修正されたという事実に基づいて意見を述べています。 さまざまなプロジェクトで以前に発見されたエラーをランダムにピックアップし、それらに何が起こったのかを調べました。 根拠がないように、これについてさらに詳しく説明します。



最初のバグ修正



そこで、27,000件のエラーに関する記事で、org.tizen.w-home-0.1.0プロジェクトのエラーを含む次のフラグメントを書きました。

static void __page_focus_changed_cb(void *data) { int i = 0; int *focus_unit = (int *)data; if (focus_unit == NULL || focus_unit < 0) { // <= _E("focus page is wrong"); return ; } .... }
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

<operatorを使用してポインターを0と比較することは意味がありません。 PVS-Studioの警告のおかげでエラーが見つかりました：V503これは無意味な比較です：ポインター<0。apps_view_circle_indicator.c 193



そのため、コードは変更されており、新しいバージョンでは次のようになります。

 if (focus_unit == NULL || (*focus_unit) < 0) {
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

そのため、この記事では、ポインターを逆参照するのを忘れたことを推測しました。



修正された2番目のバグ



プロジェクトcapi-media-codec-0.5.3。

 void extract_input_aacdec_m4a_test( App * app, unsigned char **data, int *size, bool * have_frame) { .... unsigned char buffer[100000]; .... DONE: *data = buffer; *have_frame = TRUE; if (read_size >= offset) *size = offset; else *size = read_size; }
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

以下では、エラーの本質を分析しません。エラーの説明は前の記事で見つけることができるからです。 PVS-Studioの警告のおかげでエラーが見つかりました。V507ローカル配列「バッファ」へのポインタは、この配列の範囲外に保存されています。 そのようなポインターは無効になります。 media_codec_test.c 793



プロジェクトの新しいバージョンでは、 extract_input_aacdec_m4a_test関数は単純に消えました。 したがって、間接的にではありますが、このエラーは修正されたと言えます。 おそらく、このテスト全体が冗長または不正確だったのでしょう。



修正された3番目のバグ



Bluetooth-frwk-0.2.157プロジェクト。

 typedef int gint; typedef gint gboolean; #define BT_REQUEST_ID_RANGE_MAX 245 static gboolean req_id_used[BT_REQUEST_ID_RANGE_MAX]; void _bt_init_request_id(void) { assigned_id = 0; memset(req_id_used, 0x00, BT_REQUEST_ID_RANGE_MAX); }
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

PVS-Studio警告：V512「memset」関数を呼び出すと、バッファー「req_id_used」のアンダーフローが発生します。 bt-service-util.c 38



このエラーは、バッファサイズが定数で設定されなくなったため、 sizeof演算子を使用して計算されるため、修正されました。

 memset(req_id_used, 0x00, sizeof(req_id_used));
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

この記事で説明したものから2番目の修正オプションを選択しました。



修正された4番目のバグ



プロジェクトorg.tizen.screen-reader-0.0.8。

 static void _on_atspi_event_cb(const AtspiEvent * event) { .... char buf[256] = "\0"; .... snprintf(buf, sizeof(buf), "%s, %s, ", name, _("IDS_BR_BODY_IMAGE_T_TTS")); .... snprintf(buf + strlen(buf), sizeof(buf), "%s, ", _("IDS_ACCS_BODY_SELECTED_TTS")); .... }
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

PVS-Studio警告：V512「snprintf」関数を呼び出すと、バッファー「buf + strlen（buf）」がオーバーフローします。 app_tracker.c 450



修正されたバージョンは、記事で私が提案したバリアントに対応しています。

 snprintf(buf + strlen(buf), sizeof(buf) - strlen(buf), "%s, ", _("IDS_ACCS_BODY_SELECTED_TTS"));
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

修正された5番目のバグ



プロジェクトcapi-network-http-0.0.23。

 int _read_request_body(http_transaction_h http_transaction, char **body) { .... *body = realloc(*body, new_len + 1); .... memcpy(*body + curr_len, ptr, body_size); body[new_len] = '\0'; // <= curr_len = new_len; .... }
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

PVS-Studio警告：V527 '\ 0'値が 'char'タイプポインターに割り当てられているのは奇妙です。 おそらく意味：* body [new_len] = '\ 0'。 http_request.c 370



繰り返しますが、コードは私が推奨したとおりに修正されています。

 (*body)[new_len] = '\0';
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

6番目のバグ修正



プロジェクトorg.tizen.w-wifi-1.0.229。

 static void SHA1Final(unsigned char digest[20], SHA1_CTX* context) { u32 i; unsigned char finalcount[8]; .... memset(context->count, 0, 8); memset(finalcount, 0, 8); }
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

PVS-Studio警告：V597コンパイラーは、「finalcount」バッファーのフラッシュに使用される「memset」関数呼び出しを削除できました。 プライベートデータを消去するには、memset_s（）関数を使用する必要があります。 wifi_generate_pin.c 185



ここでは、 finalcountバッファ内のデータが誤って上書きされます 。 むしろ、それらは上書きされません。コンパイラは、 memset関数呼び出しを削除する権利を持っています。 実際、これは明らかにmemset関数呼び出しを削除してfinalcountを消去するため、本当の間違いではありませんでした。 このバッファには重要なものが含まれていないため、このバッファをリセットする必要はないと思います。



それでも、コードは修正されました。つまり、著者は記事の情報を聞いていました。



7番目のバグ修正



プロジェクトorg.tizen.setting-1.0.1。

 static void __draw_remove_list(SettingRingtoneData *ad) { char *full_path = NULL; .... full_path = (char *)alloca(PATH_MAX); // <= .... if (!select_all_item) { SETTING_TRACE_ERROR("select_all_item is NULL"); free(full_path); // <= return; } .... }
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

PVS-Studio警告：V611メモリは「alloca」機能を使用して割り当てられましたが、「free」機能を使用して解放されました。 「full_path」変数の背後にある操作ロジックを調べることを検討してください。 setting-ringtone-remove.c 88



__draw_remove_list関数は別のsetting-ringtone-remove.cファイルに移動し、そのコードは修正されました。 free（full_path）関数の呼び出しは削除されました。これは単に必要ではなく、有害でさえあるためです。



興味深いことではないので、エラーについては詳しく調べませんでした。表示された7つのエラーのうち7つが修正されました。 したがって、この記事（またはそれらの一部）に記載されているエラーを読んで、注意して、修正したことは明らかです。



私の記事が役に立ち、Tizenプロジェクトが少なくとも少し良くなったことを嬉しく思います。 なぜ少し？ 私はこのOSのコードの3.3％だけを分析するために習得したからです。



読者に質問があるかもしれません。なぜこれらのエラーは私に正確に修正されたのでしょうか？ これらのエラーはすべて、開発者自身が気づいたか、他のツールを使用して発見された可能性があります。 他にどんなツールがありますか？ はい、誰でも！ 少なくともSvace静的アナライザーを使用してください。



Svaceは、Samsungが資金を提供するISP RASで開発され、Tizenオペレーティングシステムのエラー検出に特化した静的コードアナライザーです。 たとえば、最近このアナライザーは記事「 ClickHouseサンプルを使用した静的コードアナライザー 」（ o6CuFl2Q ）で言及されました。



はい。TizenOS開発者ポータルでは 、Svaceを使用してプログラムのソースコードのエラーを検出することを推奨しています。 そのため、このバージョンは非常に信じられます。

sayingにあるように、「あなたの証拠は何ですか」？



別のアナライザーではなく、PVS-Studioのおかげでエラーが正確に修正されたと判断したのはなぜですか？



ああ！ このメリットがPVS-Studioであることは簡単に証明できます！



すでに書いたように、コードの3.3％に関連する警告は十分でした。 それから私の力がなくなった。 ただし、当時のアナライザーはコードの3.3％ではなく、約5％をチェックしていました。 これらの未組み立てのレポートはまだあります。



それらを調べて、記事で説明しなかったエラーのライフヒストリを調べてみましょう。



そのため、この記事の執筆時点では見ていなかったレポートをランダムに開き、修正に値する説得力のあるエラーを探します。 amd-0.6.5プロジェクトから始めます。 名前はAMDと言っていますが、このコードはTizenを指し、Samsungの開発者によって作成されました。 これは、冒頭のコメントから明らかです。



// Copyright©2000-2017 Samsung Electronics Co.、Ltd. 無断複写・転載を禁じます。



最初の修正されていないエラー（私はそれについて書いていないので）



だから、古いコードでは、私は見る：

 static int __get_instance_info(bundle *kb, struct instance_info *info) { .... gchar *query; .... if (query == NULL || query + 1 == NULL) { .... }
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

PVS-Studio警告：V694条件（クエリ+ 1 == NULL）は、とにかく未定義の動作であるポインターオーバーフローがある場合にのみ真です。 amd_request.c 1083



式 "query + 1 == NULL"は、ポインターがオーバーフローした場合にのみ真になります。 これはできません。これは未定義の動作です。 このコードには明らかに何か問題があります。



私は新たに汲み出されたコードを見ます。 __get_instance_info関数はamd_rua.cファイルに移行されました。 ただし、本質は変わっておらず、エラーはそのまま残ります。

 if (query == NULL || query + 1 == NULL) {
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

2番目の修正されていないエラー（私はそれについて書いていないため）



プロジェクトattach-panel-camera-0.1.0。

 #define startfunc LOGD("+- START -------------------------"); #define endfunc LOGD("+- END --------------------------"); static Eina_Bool _main_view_send_result_after_transform(void *data) { startfunc main_view *view = (main_view *)data; if (view->transformtype == CAM_TRANSFORM_CROP) { DBG("crop completed, Start resize"); _main_view_ug_send_result(view, view->filename); _main_view_start_camera_preview(view->camera); view->transformtype = CAM_TRANSFORM_NONE; } return ECORE_CALLBACK_CANCEL; // <= endfunc // <= }
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

PVS-Studio警告：V779到達不能コードが検出されました。 エラーが存在する可能性があります。 main-view.c 261



到達不能コード。 ロギング関数の呼び出しは、 returnステートメントの上に移動する必要があります。 新鮮なコードを調べます。 何も変わっていない、誰もエラーを見つけていない：

  return ECORE_CALLBACK_CANCEL; // <= endfunc // <= }
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

3番目の未修正エラー（私はそれについて書いていないため）



プロジェクトaul-0.6.7。

 static gboolean run_func(void *data) { callfunc(cmd); if (strcmp(cmd, "launch_res") == 0 || strcmp(cmd, "all") == 0 || strcmp(cmd, "dbuslaunch") == 0 || strcmp(cmd, "listen_app_status") == 0 // <= || strcmp(cmd, "open_svc_res") == 0 || strcmp(cmd, "listen_app_status") == 0) // <= return 0; else g_main_loop_quit(mainloop); return 0; }
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

PVS-Studioの警告：V501「||」の左右に「strcmp（cmd、 "listen_app_status"）== 0」と同じ副次式があります。 演算子。 aul_test.c 898



文字列は「listen_app_status」と2回比較されます。 1つの比較は不必要であるか、他の比較と比較する必要がありました。



ソースコードの新しいバージョンでは、何も変更されておらず、エラーが発生しています。

これが証拠です。



理由がわかりません。 この記事で説明しなかったエラーは、Tizenコードで引き続き発生します。



残念ながら、Tizen開発コミュニティはPVS-Studioに何らかの面で慣れ親しんでいました。 はい、おそらく記事の情報に基づいて数百のエラーを修正しました。 しかし、それ以上先には行きませんでした。 誰も私に対応せず、アナライザーを使用する可能性について議論しませんでした。 むしろ、対応はありましたが、ある種の説得力がなく、興味がありませんでした。



その結果、数百のエラーが修正されました。 そして、何千もの修正が可能です！



そのため、静的コード分析を普及させ、それを正しく使用する方法を学ぶことが非常に重要です。 コードの3％を編集し、残りの97％のエラーの運命に関心がないことは非効率的です。 一般に、1回限りのチェックは無効です。静的アナライザーを定期的に使用する必要があります。



一般的に、これはなんとなく悲しいことです。



私は要約し、間違いについて悲しみ、もう一度コードのエラーのレビューに聴衆の注意を引きたいと思いました。 私は会議でのスピーチでこれらすべてのトピックに触れたかった。



「プログラムの分析、モデリング、変換のための技術」のような適切なイベントから離れることは奇妙です。 さらに、優れた実用的な結果が得られたため。 最終的に、ロシアではこの分野に関与している人はほとんどいません。



科学的な申請書を提出できないことに失望しました。 Habrahabrで書くこと、Linux.org.ruで永続的にすること、そして科学論文の形式で何かを述べることはまったく別のことです:)。 結果-拒否されたレビュー：







私は記事が不十分に書かれたことを認めます。 少し気になる点は、「この記事には分析ツールを判断するための詳細が含まれていない」ということだけです。 それでは、どうすればPVS-Studioであると書くことができますか？ 著者がAndrey Karpovであることはすぐに明らかになります。これは、申請を提出する際の匿名の条件に違反していることです。

ただし、匿名性は存在しますが、PVS-Studioの耳はどこにでもあり、27,000のエラーに関する記事があります:)。 校閲者が推測できなかったことは奇妙です。 これは、静的解析の専門家がまったく専門家ではないことが判明したことを意味します。 または彼は推測しましたが、...？ :)



まあ。 ブラバーがやった、私は認める。 次回は、理由があればもっと良くしようと思います。



ご清聴ありがとうございました。 Tizen開発者として振る舞わないでください。1回限りのチェックの結果に基づいて変更を加えます（さらに不完全です）。 静的アナライザーは開発プロセスですぐに実装する必要があり、PVS-Studioはスムーズな統合の可能性を提供します。 すべてのコードレスコードをお祈りします。



PS ISP RASの誰かがこの記事を読んで、静的コード分析のトピックに関する非公式のレポートで会議を多様化したい場合は、いつでも準備ができています。