血管内手術のトレーニングシミュレーターのプロジェクトで静的解析をテストした方法について

プロジェクトでPVS-Studio静的コードアナライザーをどのようにテストし、このツールからどのような利点が得られるかを判断しようとしたストーリーを共有したいと思います。 この記事では、専門家向けのユニークで興味深いソフトウェアエラーについては説明しません。 静的解析によってコードに見つかったすべてのバグと欠点は、非常に散発的なものであることが判明しました。 ここでは、このツールをプロジェクトマネージャーの観点から見て説明します。 おそらく、この角度はエンジニアの評価ほど正確で明確ではありません。特定のプロジェクトの作業組織の特徴が効果を発揮します。 しかし、それでも、記事で提示された考えは、仕事で静的分析を使用することを考えている人にとって興味深いものになると思います。 または、プロジェクトの段階で、テスト段階で発見されたエラーを修正するためのリソースの大幅な損失に直面している人のために。

はじめに

私は、仮想医療シミュレーションの開発を専門とするEidos-Medicineで働いています。 これらは、教育プロセスにおけるさまざまな外科的介入のパフォーマンスをシミュレートできる特別なハードウェアおよびソフトウェアシステムです。 シミュレータを使用することで、医学生やインターンは、生きている患者に委ねられる前に、専門分野で最初の実践的なスキルを身に付けることができます。 私たちの設計チームは、血管内介入のシミュレーターを開発しています。 この領域には、蛍光透視法の制御下で行われる血管に対する多くの種類の手術が含まれます。血管形成術、ステント留置、動脈瘤のらせん塞栓術、大動脈瘤の内部人工器官置換術です。



私たちのチームは、現在の構成でプロジェクトに1年半取り組んでいます。 すべてがいつものように続きます。 コンサルティング外科医は、視覚的コンポーネントの要件に取り組みながら、外科的介入の戦術について段階的にアナリストと協力しています。 3Dアーティストは、3D CT血管造影、解剖学的アトラス、および外科医のアドバイスを使用して、シミュレーターの新しい臨床例のモデルを作成します。 トップレベルのプログラマーは、蛍光透視法の可視化、動脈内の血管内器具の動きの物理学、シミュレータ上の士官候補生の行動の論理的分析に取り組んでおり、介入の段階の正確性を修正しています。 回路設計者、マイクロコントローラープログラマー、および設計エンジニアは、シミュレーションで使用される医療機器のさまざまなシミュレーターの作業を提供し、センサーからデータを収集し、それらの予備処理とプログラムへの送信を行います。 それに応じて、上位レベルでは、情報がコントローラーへの送信用に準備され、それに基づいて、教育プロセスの慣習を最小限に抑えるように設計された、仮想介入のコースに対応する機器の指示と触覚フィードバックの効果が提供されます。



そして、作業が完了し、コンパイルされ、はんだ付けされ、結び付けられ、製粉され、組み立てられると、その結果がテスターに​​送信されます。 私たちとのテストはほとんど手作業です。 最小限の自動テスト。 新しいバージョンの開発中、テスターは自分のコンピューターでプログラムの現在のリビジョンをチェックし、パフォーマンス、安定性、作業の妥当性を確認します。 これは、バージョンの反復が非常に長いため、危険なコミットを時間内にキャッチするために必要です。 ただし、リリース候補の主なテストは、シミュレーター自体で行われます。 驚きがあるかもしれません。 誰かが通信プロトコルとコントローラーの調整で誰かを誤解しました。 または、シミュレーターで作業するときのツールシミュレーターの動きのダイナミクスは、キーボードからのデバッグコントロールとはわずかに異なり、これは物理エンジンに重大な問題をもたらします。 または、新しいバージョンで使用されている一部のサードパーティライブラリがディストリビューションに報告されていません。 多くの驚きがありますが、もちろん、トラブルのチャンピオンはフローティングエラーであり、プログラムの低下や、士官候補生がシミュレータで通常モードのエクササイズを実行できない重大な問題が発生します。







ただし、かなり単純で計算が簡単なバグに多くの時間が費やされます。 新しい機能を追加すると、多くの場合、新しいバグがプログラムに導入されます。 それらのほとんどは、バージョンの作業中であっても、プロジェクトの毎日の回帰テストの過程でキャッチされます。 新しいエラーを発見したテスターは、どの開発者がそのエラーに責任を負っているのか（偶然、必ずしも明らかではない）を判断し、Redmineでタスクを作成する必要があります。 プログラマーが問題を理解し、修正をコミットした後、追加のチェックを実行して、問題が実際に解決され、解決できることを確認する必要があります。 合計で、最もささいなケースでは半分以上の工数が得られます。 これは、バグが迅速に再現され、プログラマが問題の内容とコードで修正する必要があるものをすぐに理解する場合です。 エラーを再現するのに20〜30分かかる場合、最も速くてささいな修正の場合でも、2工数の損失を伴います。 十分な損失。 そのようなエラーの原因は、通常の不注意にあることが多いため、さらに攻撃的です。

プロジェクトの静的コード分析

プロジェクトで静的コードアナライザーを使用してみようというアイデアは、私だけではありません。 C ++ Russiaカンファレンスの同僚が私に持ってきてくれたのですが、彼はPVS-Studioの人たちに会いました。 私は現在のバージョンを考えてリリースするために一時停止し、それからすべて同じように試すことにしました。 PVS-Studioの開発者にメールで連絡し、短い連絡の後、2週間ライセンスキーを受け取り、プロジェクトのチェックを開始しました。



ここで、プロジェクトのアーキテクチャの機能についていくつかの言葉を言う必要があります。 C ++にはあまりコードがありません。 約50のライブラリだけですが、それらの一部には数十行のコードしか含まれていません。 プログラムロジックの重要な部分は、グラフィックエンジンの環境にあります。 DLLを介してC ++コードをプロジェクトに統合します。 したがって、グラフィックエンジンの環境では表されない特定の機能を実装します。 さらに、フレームごとに動的に変更したり、血管内カテーテルとガイドをレンダリングしたり、心拍や呼吸の動きをシミュレートするための多角形グリッドを作成したりするために、DLL複雑またはリソース集約型アルゴリズムに移行します。 C ++では、外科的介入をシミュレートする運動のロジックも記述されています。これにより、手術の段階の追跡と士官候補生の行動の正確性が保証されます。 その結果、プロジェクトにはいくつかの非常に小さなC ++ライブラリと、それぞれ2〜3千個を含むいくつかの中規模のライブラリがあります。 グラフィックエンジンの環境にあるプログラムロジックの部分については、静的コード分析のための興味深いツールは使用できません。 そのため、プロジェクトの一部のみをPVS-Studioでテストしました。



PVS-Studioが私のコンピューターに簡単かつ楽に立ち上がってVisual Studio 2013に統合されました。PVS-StudioチームのAndrey Karpovがユーザーマニュアルへのリンクとクイックスタートガイドのようなものを送ってくれました。静的アナライザーのインターフェースと機能は、直感的で科学的な突進技術を使用してのみ実行できます。



15分後、動脈を介してX線造影剤を拡散するプロセスのモデリングを担当するDLLコードを既にチェックしました。 このライブラリには、約4000行のコードが含まれています。 アナライザーがSolutionの最初のレベルのエラーを記録しなかったことに少し驚きました。 ただし、このソリューションはすでに数十時間のテストに合格しており、最近は安定して機能していることに注意してください。 それで、静的アナライザーは何に注意を払っていますか？



V550奇妙な正確な比較：t！=0。定義された精度の比較を使用する方がおそらく良い：fabs（A-B）> Epsilon。 objectextractpart.cpp 3401

D3DXVECTOR3 N = VectorMultiplication( VectorMultiplication(V-VP, VN), VN); float t = Qsqrt(Scalar(N, N)); if (t!=0) { N/=t; V = V - N * DistPointToSurface(V, VP, N); }
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

このライブラリでは、同様のエラーが頻繁に繰り返されます。 これが私にとって驚きだったとは言いません。 以前、このプロジェクトで浮動小数点数に関する誤った作業に遭遇しました。 ただし、ソースを体系的に確認するリソースはありませんでした。 検証の結果によれば、開発者に浮動小数点数を扱うという観点で視野を広げるために読むものを与える必要があることが明らかになりました。 私は彼にいくつかの良い記事へのリンクを投げました。 結果を見てみましょう。 このエラーがプログラムで実際の誤動作を引き起こすかどうかを明確に言うことは困難です。 現在のソリューションは、放射線不透過性物質の拡散がそれに沿ってシミュレートされる、動脈の初期多角形ネットワークの多くの要件を設定します。 要件が満たされていない場合、プログラムがクラッシュしたり、明らかに正しく動作しないことがあります。 これらの要件の一部は分析的に取得され、一部は経験的に取得されます。 要件のこの2番目の部分は、浮動小数点数の誤った処理だけで大きくなる可能性があります。 浮動小数点数の正確な比較を使用して見つかったすべてのケースがエラーであったわけではないことに注意してください。



V807パフォーマンスの低下。 'Duct.TR [cIT]'式を繰り返し使用しないように、参照を作成することを検討してください。 objectextractpart.cpp 2689

 for (k = 0; k < Duct.LIsize; k++) { cIT = Duct.ListIT[k]; if(DuctMain.TR[cIT].inScreen &&(Duct.TR[cIT].PNum > OneDev512)) { tuv[0].y = Duct.TR[cIT].v0 * Duct.TR[cIT].PNum; .... } .... }
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

ソリューション内の約20の同様のメッセージ。 興味深いことに、このライブラリには非常に高いパフォーマンス要件があります。 ベクトルと行列を扱う関数では、文字通りすべての乗算が一度に考慮され、保存する場所を探しました。 このコード例のループは、非常に多数の反復処理（最大数万回）を繰り返します。 血管造影レンダリングを提供するパーティクルシステムアルゴリズムの一部です。 透視画像の放射線不透過性物質の視覚化の特徴は、フレームの平面に垂直に向けられた血管がより暗く見えることです。 この場合、X線は血管に沿って通過します。つまり、吸収媒体のより大きな層を通過し、より減衰され、投影内のフィルムを照らしません。 プログラムでのこの効果は、動脈の多角形ネットワーク内に分散された半透明の粒子のシステムにより達成されます。 多角形メッシュは非常に詳細です。 システム内の粒子もそれぞれ非常に大きいです。 実験を行うことは興味深いでしょう。 コード内のこれらの洗練されていない場所を修正することで、1〜2ミリ秒勝つことができますか？ おそらくコンパイラはこの最適化を自動的に行いますが、ヒントを与えてはどうでしょうか。







V669メッセージ：「cIT」、「j」引数は非定数参照です。 アナライザーは、この引数が変更されている位置を判別できません。 関数にエラーが含まれている可能性があります。 objectextractpart.cpp 2406

 D3DXVECTOR3 ObjectExtractPart::GetD(D3Object& Duct, int& cIT, int& j){ return DuctMain.VP[DuctMain.TR[cIT].IP[2]].P + ( DuctMain.VP[DuctMain.TR[cIT].IP[0]].P - DuctMain.VP[DuctMain.TR[cIT].IP[2]].P + ( DuctMain.VP[DuctMain.TR[cIT].IP[1]].P - DuctMain.VP[DuctMain.TR[cIT].IP[0]].P ) * Duct.TR[cIT].tt[j].x ) * Duct.TR[cIT].tt[j].y + DuctMain.TR[cIT].CNR * Duct.TR[cIT].tt[j].z; }
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

この場合、コードは正しいです。 プログラマーのエラーは、関数パラメーターの誤った説明にのみあります。 それらはconst int＆であるべきでした。



最初の被験者で驚くほど少数の重大なエラーを発見したため、私たちは現時点でより積極的に拡大するソリューションに進みました。 次のテスト対象は、グラフィックエンジンから外科的介入をシミュレートするための演習の論理コードへの仮想介入中に何が起こっているかに関するデータ転送を提供する8つのライブラリで構成されています。 たとえば、士官候補生のエラーを通知したり、介入フェーズの完了を知らせるために、反対方向のデータ転送が同じライブラリにかかっています。 このため、グラフィックエンジンの環境に接続せずに、C ++でのみ演習のロジックを記述できます。







ここで、収穫はすでにより印象的であり、コード内に非常に危険な場所がいくつか見つかりました。



V595メッセージ： '_idiChannel'ポインターは、nullptrに対して検証される前に使用されました。 行を確認：917、918。logicinterface.cpp 917

 int instType = _idiChannel->GetActiveInstrumentTypeInGroup(instrumentId); if (_alogChannel != NULL && _idiChannel != NULL) { .... }
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

潜在的なクラッシュサイト。 これまでアプリケーションがこの段階で動作していたとき、_idiChannelポインターがNULLではなかったため、テストではこのエラーは以前には明らかになりませんでした。 しかし、今後の開発で状況が変わらないことを保証する人はいません。また、以前プロジェクトに組み込まれていたこのバグが顕在化することは保証されません。



V688 'chCameraMatrix'ローカル変数は、クラスメンバーの1つと同じ名前を持っているため、混乱を招く可能性があります。 angiographlog.cpp 323

 class ANGIOGRAPHLOG_API AngiographLog: public ILogic { .... Aco_Matrix* chCameraMatrix; Aco_Matrix* chProjectionMatrix; .... } D3DXMATRIX AngiographLog::GetCameraMatrix() { D3DXMATRIX res; Aco_Matrix* chCameraMatrix=(Aco_Matrix*)GetChild(CameraMatrix); if ( chCameraMatrix != NULL) { res = chCameraMatrix->GetMatrix(); } return res; }
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

Solutionの異なるファイルの4つのそのようなトリガー。 この場合、エラーは発生しませんでした。 しかし、将来的には、コード内で初期化されていないポインターの誤解や使用につながる可能性があります。



V522ヌルポインター「chInstrumentSubLineLengthIn」の逆参照が行われる場合があります。 instrumentdatainterface.cpp 239

 D3DXVECTOR3 InstrumentDataInterface::GetSubLineEndPos(....) { .... if(chInstrumentSubLineLengthIn != NULL) chInstrumentSubLineLengthIn->SetFloat(subLineLengthIn); else chInstrumentSubLineLengthIn->SetFloat(0.0F); .... }
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

ここで、私が想像しているように、開発者は最初に最初の2行のコードを作成しました。 それから彼は何かに気を取られました。 それは非常に重要なことです。 再びコードの作業に戻って、彼はすでに明らかな愚かさを追加していました。 それは起こります。 そしてその間に、潜在的なプログラムクラッシュの場所がコードに現れました。



ポインターを使用した作業が正しく行われなかったため、コード内や他のライブラリ内に危険な場所がありました。



V614潜在的に初期化されていないポインター 'tabAntiPowerSpheres'が使用されました。 getnewposbyheartbeat.cpp 175

 void GetNewPosByHeartBeat::_precalc() { .... STL_Table *stlAntiPowerSpheres; CSTL_Table *tabAntiPowerSpheres; stlAntiPowerSpheres = (STL_Table *)GetChild(....); if (stlAntiPowerSpheres != NULL) tabAntiPowerSpheres = stlAntiPowerSpheres->getSTL_Table(); if (tabAntiPowerSpheres != NULL) { int tableSize = tabAntiPowerSpheres->getRowCount(); .... } .... }
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

今回は、エラーが少しわかりにくくなりました。 stlAntiPowerSpheresがNULLであることが判明した場合、tabAntiPowerSpheresは初期化されずに残り、ランダムなメモリ領域を示します。 NULLのチェックに合格すると、オブジェクトのフィールドにアクセスするとプログラムがクラッシュします。 おそらく、コードのどこでも、呼び出し（STL_Table *）GetChild（CH_ANTIPOWER_SPHERES）がNULLを返さなかったため、テストではこの点が明らかになりませんでした。



最終的に、テストされていないソリューションを静的アナライザーで確認することにしました。これはまだ開発中であり、メインプロジェクトには実装されていません。 このソリューションの一環として、柔軟な文字列の独自の物理エンジンの作成に取り組んでいます。 すでに他のエラーがありました。 たとえば、ここに面白い展示があります：



V527偽の値が「bool」タイプのポインターに割り当てられるのは奇妙です。 おそらく意味：* outIsInScene = false。 rpscene.cpp 79

 bool rpScene::CheckIsRopeInScene(...., bool* outIsInScene) { if (mEngine == NULL) { outIsInScene = false; return false; } else { *outIsInScene = mEngine->CheckIsRopeInScene(ropeToCheck); return true; } }
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

ここで、この場合のアナライザーは部分的にしか正しくないことに注意できます。 outIsInSceneパラメーターはポインターであってはなりません。 とにかく、コード内のこの疑わしい場所を指摘してくれてありがとう。 本当に間違い。



ここではすべてのトリガーを提供しません。 最後に注意を引いたのは2つだけです。



V501「||」の左と右に同一のサブ式「（fabs（crossVect.x）> 1.192092896e-07F）」があります 演算子。 rpmath.h 103

 inline bool IsCollinearVectors(Vector3d vect1, Vector3d vect2) { Vector3d crossVect = Vector3dMultiply(vect1, vect2); //     ; return !((fabs(crossVect.x) > FLT_EPSILON) || (fabs(crossVect.y) > FLT_EPSILON) || (fabs(crossVect.x) > FLT_EPSILON)); }
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

ここで、一方では、プログラマーの不注意から生じたよくある間違いがあります。 しかし、一方で、プログラムの結果を直接観察し、テストで個々のメソッドのパフォーマンスをテストしない場合、そのようなエラーを見つけるのは非常に困難です。 この関数では、2つのベクトルの共線性がチェックされました。 たとえば、衝突オブジェクトを横切る弾性弦のポイントの潜在的な変位のベクトルが、特定の仮定で、交差点での衝突オブジェクトの表面の法線と同一直線上にある場合、これはリバウンドの計算方法に影響します。 しかし、多くの相互に関連する要因が物理モデルに影響を与えるため、動作中のプログラムを観察すると、1つまたは別の不適切な動作の原因を正確に言うことが常に可能とは限りません。 そして、私たちは非常に長い間この間違いに気付かなかった。



アナライザーの別の興味深い作動がありました。 最初は、アナライザーがコード自体ではなく、文字列リテラルに何かを疑っていたため、エラーが何であるかさえ理解できませんでした。



V691実証分析。 文字列リテラル「out_Radius」内にタイプミスが存在する可能性があります。 「RADIUS」という言葉は疑わしい。 rpropeinstancecommand.cpp 93

 .... mCommandsDescriptions[currCommandNr].name = "Get Rope Fragments Count(Rope;out_Count)"; .... mCommandsDescriptions[currCommandNr]. params[PARAM_NR_FRAGMENTS_COUNT].name = "out_Radius"; ....
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

しかし、アナライザーはケースについて呪いをかけていました。実際、別の文字列リテラルがあるはずです。 この時点での文字列「out_Radius」は、フラグメントからコピーアンドペーストした結果、少し高くなっています。 その後、コード内で何かが置き換えられましたが、ここで適切なout_Countに文字列リテラルを修正するのを忘れていました。



コピー元のコードは次のとおりです。

 .... mCommandsDescriptions[currCommandNr].name = "Get Rope Fragment Radius(Rope; in_FragmentNr;out_Radius)"; .... mCommandsDescriptions[currCommandNr]. params[PARAM_NR_FRAGMENT_RADIUS].name = "out_Radius"; ....
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

どうして終わったの？

このようなプロジェクトの1回限りの検証は、多くの利益をもたらさないことは明らかです。 既存のコードはすでにかなり長いテストに合格しています。 エラーはそれほど多くありません。また、存在するエラーの多くは、通常のプログラム操作中には現れません。 PVS-Studioライセンスを購入しますか？ このようなツールをプロジェクトに導入することに前向きな姿勢を持っています。 明らかに、静的分析を使用すると、テスター、さらには開発者のリソースの一部が解放されます。 Redmineでは、エラートラッカーのタスクが少なくなります。 解決されたタスクは、修正のためにテスターから返される可能性が低くなります。 ただし、最終決定を下す前に、PVS-Studioがもたらす商業的メリットを正確に評価し、これを製品自体のコストと比較する必要があります。 この評価は、このプロジェクトではC ++で動的に開発されるコードが比較的少ないという事実に大きく影響されます。 これまでのところ、このツールなしで作業を続けています。

レビュー

また、Eidos-Medicineの他のプロジェクトチームの開発者に一時的なライセンスキーを渡しました。 私は、彼らが彼らの仕事でそのような道具を必要とするかどうかについて結論を下すように試みて欲しかった。 記事でいくつかのレビューを行います。

• 腹腔鏡手術のシミュレーターの開発チームのプログラマーであるニコライは、「悪いことではありません。 初期化されていないポインターとそれらの危険な作業が見つかりました。
• 産業用ロボットのソフトウェアチームのプログラマーであるオレグは、次のように語っています。 しかし、古いプロジェクトに詰め込むのは難しいです。 〜9kの警告があります。 確かに、「古いものはすべて無視し、新しいエラーのみを探す」モードがあります（このプロジェクトのアナライザー警告の多くは、もはや一部ではないという事実によって説明されていますが、すべてのコードはC ++で記述されています。プロジェクトチームは著しく大きくなっています。）
• ローマン、産業用ロボットのソフトウェアチームのプログラマー：「便利なことですが、月に1回以上使用するのは意味がないと思います。」

Andrei Karpovは最後のコメントに応答し、記事で彼の答えを求めました。



これは非効率的な使用例であり、各記事で警告するようにしています。 簡単に言えば、エラーが早く検出されるほど良いです。 静的分析を使用してコンパイルした直後にデバッガが見つかった場合、デバッガを実行してタイプミスを探すことは意味がありません。



アナライザーを定期的に使用しない理由がその遅い動作にある場合は、作業速度を上げるためのヒントを知ることを提案します。 おそらく彼らは助けるでしょう。 そうでない場合は、常に自動夜間チェックを整理できます（すべてをより適切に整理する方法を紹介します）。



理由があまりにも多くの警告である場合、初心者はすべての警告を削除し、新しい警告のみで作業できます（ 大規模プロジェクトに静的解析を組み込む方法 ）。





この記事では、Adele Valeev enzo2uの写真を使用しました 。