PVS-Studio アナライザーを使用した LLVM 8 のバグの検索

PVS-Studio アナライザーを使用した LLVM プロジェクトの最後のコード チェックから 8.0.0 年以上が経過しました。 PVS-Studio アナライザーが依然としてエラーと潜在的な脆弱性を特定するための主要なツールであることを確認しましょう。 これを行うには、LLVM XNUMX リリースをチェックして新しいエラーを見つけます。

書く記事

正直に言うと、この記事を書きたくなかったのです。 すでに何度もチェックしているプロジェクトについて書くのは面白くありません (1, 2, 3）。 何か新しいことを書いた方が良いのですが、仕方がありません。

LLVM の新しいバージョンがリリースまたは更新されるたび Clang 静的アナライザー、メールで次のような質問を受け取ります。

見てください、Clang Static Analyzer の新しいバージョンは、新しいエラーを検出することを学習しました。 PVS-Studio を使用する関連性が低下しているように思えます。 Clang は以前よりも多くのエラーを検出し、PVS-Studio の機能に追いつきます。 あなたはこのことについてどう思いますか？

これに対して私はいつも次のように答えたいと思っています。

私たちも手をこまねいているわけではありません！ PVS-Studio アナライザーの機能が大幅に向上しました。 心配しないでください、私たちは以前と同じようにリードし続けます。

残念ながら、これは間違った答えです。 そこには証拠はありません。 そしてそれが私が今この記事を書いている理由です。 そこで、LLVM プロジェクトを再度チェックしたところ、さまざまなエラーが見つかりました。 ここでは、私にとって興味深いと思われたものを紹介します。 Clang Static Analyzer はこれらのエラーを検出できません (または、Clang Static Analyzer を使用して検出するのは非常に不便です)。 しかし、それは可能です。 さらに、私はこれらすべての間違いを一晩で見つけて書き留めました。

しかし、記事を書くのに数週間かかりました。 これをすべてテキストにまとめる気にはなれませんでした:)。

ところで、PVS-Studio アナライザーでエラーや潜在的な脆弱性を特定するためにどのようなテクノロジーが使用されているかに興味がある場合は、これを理解しておくことをお勧めします。 ノート.

新旧の診断

すでに述べたように、約 3 年前に LLVM プロジェクトが再度チェックされ、見つかったエラーが修正されました。 この記事では、新しいエラーのバッチを紹介します。 新しいバグが見つかったのはなぜですか? これには XNUMX つの理由があります。

1. LLVM プロジェクトは進化しており、古いコードを変更し、新しいコードを追加しています。 当然のことながら、変更され書かれたコードには新たなエラーが発生します。 これは、静的分析は時々ではなく定期的に使用する必要があることを明確に示しています。 私たちの記事では PVS-Studio アナライザーの機能を詳しく説明していますが、これはコード品質の向上やエラー修正コストの削減とは何の関係もありません。 静的コード アナライザーを定期的に使用してください。
2. 現在、既存の診断を完成させ、改善しています。 したがって、アナライザーは、以前のスキャンでは気付かなかったエラーを特定できます。
3. 2 年前には存在しなかった新しい診断が PVS-Studio に登場しました。 PVS-Studio の開発を明確に示すために、それらを別のセクションで強調表示することにしました。

2年前に存在した診断により特定された欠陥

フラグメント N1: コピー＆ペースト

static bool ShouldUpgradeX86Intrinsic(Function *F, StringRef Name) {
  if (Name == "addcarryx.u32" || // Added in 8.0
    ....
    Name == "avx512.mask.cvtps2pd.128" || // Added in 7.0
    Name == "avx512.mask.cvtps2pd.256" || // Added in 7.0
    Name == "avx512.cvtusi2sd" || // Added in 7.0
    Name.startswith("avx512.mask.permvar.") || // Added in 7.0     // <=
    Name.startswith("avx512.mask.permvar.") || // Added in 7.0     // <=
    Name == "sse2.pmulu.dq" || // Added in 7.0
    Name == "sse41.pmuldq" || // Added in 7.0
    Name == "avx2.pmulu.dq" || // Added in 7.0
  ....
}

PVS-Studio の警告: V６０ [CWE-570] '||' の左側と右側に同一の部分式 'Name.startswith("avx512.mask.permvar.")' があります。 オペレーター。 自動アップグレード.cpp 73

名前が部分文字列「avx512.mask.permvar.」で始まることが二重チェックされます。 XNUMX 回目のチェックでは、明らかに何か別のことを書きたかったのですが、コピーしたテキストを修正するのを忘れていました。

フラグメント N2: タイプミス

enum CXNameRefFlags {
  CXNameRange_WantQualifier = 0x1,
  CXNameRange_WantTemplateArgs = 0x2,
  CXNameRange_WantSinglePiece = 0x4
};

void AnnotateTokensWorker::HandlePostPonedChildCursor(
    CXCursor Cursor, unsigned StartTokenIndex) {
  const auto flags = CXNameRange_WantQualifier | CXNameRange_WantQualifier;
  ....
}

警告 PVS-Studio: V501 '|' の左側と右側に同一の部分式 'CXNameRange_WantQualifier' があります。 オペレーター。 CIndex.cpp 7245

タイプミスのため、同じ名前の定数が XNUMX 回使用されています CXNameRange_WantQualifier.

フラグメント N3: 演算子の優先順位の混乱

int PPCTTIImpl::getVectorInstrCost(unsigned Opcode, Type *Val, unsigned Index) {
  ....
  if (ISD == ISD::EXTRACT_VECTOR_ELT && Index == ST->isLittleEndian() ? 1 : 0)
    return 0;
  ....
}

PVS-Studio の警告: V６０ [CWE-783] おそらく、「?:」演算子が予想とは異なる方法で動作する可能性があります。 「?:」演算子は「==」演算子よりも優先順位が低くなります。 PPCTargetTransformInfo.cpp 404

私の意見では、これは非常に美しい間違いです。 はい、私が美について奇妙な考えを持っていることは知っています:)。

さて、によると、 オペレータの優先順位の場合、式は次のように評価されます。

(ISD == ISD::EXTRACT_VECTOR_ELT && (Index == ST->isLittleEndian())) ? 1 : 0

実際的な観点から見ると、このような条件は次のように要約できるため、意味がありません。

(ISD == ISD::EXTRACT_VECTOR_ELT && Index == ST->isLittleEndian())

これは明らかな間違いです。 おそらく、0/1 を変数と比較したかったのでしょう。 インデックス。 コードを修正するには、三項演算子の周囲にかっこを追加する必要があります。

if (ISD == ISD::EXTRACT_VECTOR_ELT && Index == (ST->isLittleEndian() ? 1 : 0))

ちなみに、三項演算子は論理エラーを引き起こす非常に危険な演算子です。 括弧を使用する場合は十分に注意し、むやみに括弧を使用しないでください。 このトピックをさらに詳しく調べました ここで、「?: 演算子に注意してかっこで囲む」の章に記載されています。

フラグメント N4、N5: Null ポインタ

Init *TGParser::ParseValue(Record *CurRec, RecTy *ItemType, IDParseMode Mode) {
  ....
  TypedInit *LHS = dyn_cast<TypedInit>(Result);
  ....
  LHS = dyn_cast<TypedInit>(
    UnOpInit::get(UnOpInit::CAST, LHS, StringRecTy::get())
      ->Fold(CurRec));
  if (!LHS) {
    Error(PasteLoc, Twine("can't cast '") + LHS->getAsString() +
                    "' to string");
    return nullptr;
  }
  ....
}

PVS-Studio の警告: V６０ [CWE-476] Null ポインタ 'LHS' の逆参照が発生する可能性があります。 TGParser.cpp 2152

ポインタの場合 LHS が null の場合は、警告が発行されます。 ただし、代わりに、この同じ null ポインタが逆参照されます。 LHS->getAsString().

これは、エラー ハンドラーをテストする人がいないため、エラー ハンドラーにエラーが隠蔽されている場合の非常に典型的な状況です。 静的アナライザーは、使用頻度に関係なく、到達可能なすべてのコードをチェックします。 これは、静的解析が他のテストおよびエラー保護手法をどのように補完するかを示す非常に良い例です。

同様のポインタ処理エラー RHS 以下のコードで許可されています: V522 [CWE-476] NULL ポインター 'RHS' の逆参照が発生する可能性があります。 TGParser.cpp 2186

フラグメント N6: 移動後のポインタの使用

static Expected<bool>
ExtractBlocks(....)
{
  ....
  std::unique_ptr<Module> ProgClone = CloneModule(BD.getProgram(), VMap);
  ....
  BD.setNewProgram(std::move(ProgClone));                                // <=
  MiscompiledFunctions.clear();

  for (unsigned i = 0, e = MisCompFunctions.size(); i != e; ++i) {
    Function *NewF = ProgClone->getFunction(MisCompFunctions[i].first);  // <=
    assert(NewF && "Function not found??");
    MiscompiledFunctions.push_back(NewF);
  }
  ....
}

PVS-Studio 警告: V522 [CWE-476] Null ポインター 'ProgClone' の逆参照が発生する可能性があります。 コンパイルミス.cpp 601

初めにスマートポインター プログクローン オブジェクトの所有をやめる:

BD.setNewProgram(std::move(ProgClone));

実は今、 プログクローン はヌルポインタです。 したがって、null ポインタの逆参照は以下で発生する必要があります。

Function *NewF = ProgClone->getFunction(MisCompFunctions[i].first);

しかし、実際にはそんなことは起こりません！ ループは実際には実行されないことに注意してください。

コンテナの先頭に ミスコンパイルされた関数 クリア済み:

MiscompiledFunctions.clear();

次に、このコンテナのサイズがループ条件で使用されます。

for (unsigned i = 0, e = MisCompFunctions.size(); i != e; ++i) {

ループが開始されていないことが簡単にわかります。 これもバグだと思いますので、コードを別の方法で記述する必要があります。

どうやら、あの有名な同等のエラーに遭遇したようです。 一つの間違いが別の間違いを覆い隠します:)。

フラグメント N7: 移動後のポインタの使用

static Expected<bool> TestOptimizer(BugDriver &BD, std::unique_ptr<Module> Test,
                                    std::unique_ptr<Module> Safe) {
  outs() << "  Optimizing functions being tested: ";
  std::unique_ptr<Module> Optimized =
      BD.runPassesOn(Test.get(), BD.getPassesToRun());
  if (!Optimized) {
    errs() << " Error running this sequence of passes"
           << " on the input program!n";
    BD.setNewProgram(std::move(Test));                       // <=
    BD.EmitProgressBitcode(*Test, "pass-error", false);      // <=
    if (Error E = BD.debugOptimizerCrash())
      return std::move(E);
    return false;
  }
  ....
}

PVS-Studio 警告: V522 [CWE-476] Null ポインター 'Test' の逆参照が発生する可能性があります。 コンパイルミス.cpp 709

また同じ状況。 最初はオブジェクトの内容が移動され、その後は何事もなかったかのように使用されます。 C++ に移動セマンティクスが登場して以来、プログラム コードでこの状況がますます頻繁に見られます。 これが私が C++ 言語が大好きな理由です。 自分の足を撃ち落とす新しい方法がどんどん増えています。 PVS-Studio アナライザーは常に機能します:)。

フラグメント N8: Null ポインタ

void FunctionDumper::dump(const PDBSymbolTypeFunctionArg &Symbol) {
  uint32_t TypeId = Symbol.getTypeId();
  auto Type = Symbol.getSession().getSymbolById(TypeId);
  if (Type)
    Printer << "<unknown-type>";
  else
    Type->dump(*this);
}

PVS-Studio 警告: V522 [CWE-476] NULL ポインター 'Type' の逆参照が発生する可能性があります。 プリティファンクションダンパー.cpp 233

エラー ハンドラーに加えて、デバッグ出力関数は通常テストされません。 まさにそのようなケースが私たちの目の前にあります。 この機能はユーザーを待っており、ユーザーは問題を解決する代わりに、それを修正することを強いられます。

正しい：

if (Type)
  Type->dump(*this);
else
  Printer << "<unknown-type>";

フラグメント N9: Null ポインタ

void SearchableTableEmitter::collectTableEntries(
    GenericTable &Table, const std::vector<Record *> &Items) {
  ....
  RecTy *Ty = resolveTypes(Field.RecType, TI->getType());
  if (!Ty)                                                              // <=
    PrintFatalError(Twine("Field '") + Field.Name + "' of table '" +
                    Table.Name + "' has incompatible type: " +
                    Ty->getAsString() + " vs. " +                       // <=
                    TI->getType()->getAsString());
   ....
}

PVS-Studio 警告: V522 [CWE-476] NULL ポインター 'Ty' の逆参照が発生する可能性があります。 614 検索可能なテーブルエミッター.cpp

すべてが明らかであり、説明の必要はないと思います。

フラグメント N10: タイプミス

bool FormatTokenLexer::tryMergeCSharpNullConditionals() {
  ....
  auto &Identifier = *(Tokens.end() - 2);
  auto &Question = *(Tokens.end() - 1);
  ....
  Identifier->ColumnWidth += Question->ColumnWidth;
  Identifier->Type = Identifier->Type;                    // <=
  Tokens.erase(Tokens.end() - 1);
  return true;
}

PVS-Studio の警告: V６０ 「Identifier->Type」変数はそれ自体に割り当てられます。 249

変数をそれ自体に代入しても意味がありません。 おそらく彼らは次のように書きたかったのでしょう。

Identifier->Type = Question->Type;

フラグメント N11: 不審なブレイク

void SystemZOperand::print(raw_ostream &OS) const {
  switch (Kind) {
    break;
  case KindToken:
    OS << "Token:" << getToken();
    break;
  case KindReg:
    OS << "Reg:" << SystemZInstPrinter::getRegisterName(getReg());
    break;
  ....
}

PVS-Studio の警告: V６０ [CWE-478] 「switch」ステートメントを検査することを検討してください。 最初の「case」演算子が欠落している可能性があります。 SystemZAsmParser.cpp 652

最初に非常に怪しいオペレーターがいます 破る。 ここに何か他に書き忘れていませんか?

フラグメント N12: 逆参照後のポインタのチェック

InlineCost AMDGPUInliner::getInlineCost(CallSite CS) {
  Function *Callee = CS.getCalledFunction();
  Function *Caller = CS.getCaller();
  TargetTransformInfo &TTI = TTIWP->getTTI(*Callee);

  if (!Callee || Callee->isDeclaration())
    return llvm::InlineCost::getNever("undefined callee");
  ....
}

PVS-Studio の警告: V６０ [CWE-476] 「Callee」ポインタは、nullptr に対して検証される前に利用されました。 行を確認してください: 172、174。AMDGPUInline.cpp 172

ポインタ 呼び出し先 関数の呼び出し時に先頭が逆参照される getTTI.

そして、このポインタが等しいかどうかをチェックする必要があることがわかります nullptr:

if (!Callee || Callee->isDeclaration())

でも、もう手遅れです…

フラグメント N13 - N...: 逆参照後のポインタのチェック

前のコード部分で説明した状況は特別なものではありません。 ここに表示されます:

static Value *optimizeDoubleFP(CallInst *CI, IRBuilder<> &B,
                               bool isBinary, bool isPrecise = false) {
  ....
  Function *CalleeFn = CI->getCalledFunction();
  StringRef CalleeNm = CalleeFn->getName();                 // <=
  AttributeList CalleeAt = CalleeFn->getAttributes();
  if (CalleeFn && !CalleeFn->isIntrinsic()) {               // <=
  ....
}

PVS-Studio 警告: V595 [CWE-476] 「CalleeFn」ポインターは、nullptr に対して検証される前に使用されました。 行を確認してください: 1079、1081。SimplifyLibCalls.cpp 1079

そしてここに：

void Sema::InstantiateAttrs(const MultiLevelTemplateArgumentList &TemplateArgs,
                            const Decl *Tmpl, Decl *New,
                            LateInstantiatedAttrVec *LateAttrs,
                            LocalInstantiationScope *OuterMostScope) {
  ....
  NamedDecl *ND = dyn_cast<NamedDecl>(New);
  CXXRecordDecl *ThisContext =
    dyn_cast_or_null<CXXRecordDecl>(ND->getDeclContext());         // <=
  CXXThisScopeRAII ThisScope(*this, ThisContext, Qualifiers(),
                             ND && ND->isCXXInstanceMember());     // <=
  ....
}

PVS-Studio 警告: V595 [CWE-476] nullptr に対して検証される前に、「ND」ポインターが使用されました。 行: 532、534 を確認します。 SemaTemplateInstantiateDecl.cpp 532

そしてここに：

• V595 [CWE-476] nullptr に対して検証される前に、「U」ポインタが使用されました。 行: 404、407 を確認します。DWARFormValue.cpp 404
• V595 [CWE-476] nullptr に対して検証される前に、「ND」ポインタが利用されました。 行を確認してください: 2149、2151。SemaTemplateInstantiate.cpp 2149

そして、私は番号 V595 の警告を調べることに興味がなくなりました。 したがって、ここにリストされているもの以外にも同様のエラーがあるかどうかはわかりません。 おそらくあります。

断片 N17、N18: 不審な変化

static inline bool processLogicalImmediate(uint64_t Imm, unsigned RegSize,
                                           uint64_t &Encoding) {
  ....
  unsigned Size = RegSize;
  ....
  uint64_t NImms = ~(Size-1) << 1;
  ....
}

PVS-Studio の警告: V６０ [CWE-190] '~(Size - 1) << 1' 式を検査することを検討してください。 32 ビット値のビット シフトとその後の 64 ビット型への拡張。 AArch64AddressingModes.h 260

これはバグではない可能性があり、コードは意図したとおりに正確に動作します。 しかし、これは明らかに非常に疑わしい場所であり、確認する必要があります。

変数としましょう サイズ が 16 に等しい場合、コードの作成者はそれを変数に入れることを計画しました。 NImms 値：

1111111111111111111111111111111111111111111111111111111111100000

ただし、実際には次のような結果になります。

0000000000000000000000000000000011111111111111111111111111100000

実際、すべての計算は 32 ビット符号なし型を使用して行われます。 そしてその場合にのみ、この 32 ビットの符号なし型は暗黙的に次のように展開されます。 uint64_t。 この場合、最上位ビットはゼロになります。

この状況は次のように修正できます。

uint64_t NImms = ~static_cast<uint64_t>(Size-1) << 1;

同様の状況: V629 [CWE-190] 'Immr << 6' 式の検査を検討してください。 32 ビット値のビット シフトとその後の 64 ビット型への拡張。 AArch64AddressingModes.h 269

断片 N19: キーワードが欠落しています ほかに?

void AMDGPUAsmParser::cvtDPP(MCInst &Inst, const OperandVector &Operands) {
  ....
  if (Op.isReg() && Op.Reg.RegNo == AMDGPU::VCC) {
    // VOP2b (v_add_u32, v_sub_u32 ...) dpp use "vcc" token.
    // Skip it.
    continue;
  } if (isRegOrImmWithInputMods(Desc, Inst.getNumOperands())) {    // <=
    Op.addRegWithFPInputModsOperands(Inst, 2);
  } else if (Op.isDPPCtrl()) {
    Op.addImmOperands(Inst, 1);
  } else if (Op.isImm()) {
    // Handle optional arguments
    OptionalIdx[Op.getImmTy()] = I;
  } else {
    llvm_unreachable("Invalid operand type");
  }
  ....
}

PVS-Studio の警告: V６０ [CWE-670] アプリケーションのロジックを検査することを検討してください。 「else」キーワードが欠落している可能性があります。 AMDGPUAsmParser.cpp 5655

ここに間違いはありません。 最初の then ブロック以降 if で終わる 続ける、それならどうでもいいです、キーワードがあります。 ほかに か否か。 どちらの方法でも、コードは同じように機能します。 まだ見逃した ほかに コードがより不明確で危険になります。 将来的には 続ける が消えると、コードはまったく異なる動作を開始します。 私の意見では追加した方が良いと思います ほかに.

断片 N20: 同じタイプの XNUMX つのタイプミス

LLVM_DUMP_METHOD void Symbol::dump(raw_ostream &OS) const {
  std::string Result;
  if (isUndefined())
    Result += "(undef) ";
  if (isWeakDefined())
    Result += "(weak-def) ";
  if (isWeakReferenced())
    Result += "(weak-ref) ";
  if (isThreadLocalValue())
    Result += "(tlv) ";
  switch (Kind) {
  case SymbolKind::GlobalSymbol:
    Result + Name.str();                        // <=
    break;
  case SymbolKind::ObjectiveCClass:
    Result + "(ObjC Class) " + Name.str();      // <=
    break;
  case SymbolKind::ObjectiveCClassEHType:
    Result + "(ObjC Class EH) " + Name.str();   // <=
    break;
  case SymbolKind::ObjectiveCInstanceVariable:
    Result + "(ObjC IVar) " + Name.str();       // <=
    break;
  }
  OS << Result;
}

PVS-Studio の警告:

• V655 [CWE-480] 文字列は連結されましたが、使用されていません。 「Result + Name.str()」式を検査することを検討してください。 シンボル.cpp 32
• V655 [CWE-480] 文字列は連結されましたが、使用されていません。 「Result + "(ObjC Class)" + Name.str()」式を検査することを検討してください。 シンボル.cpp 35
• V655 [CWE-480] 文字列は連結されましたが、使用されていません。 「Result + "(ObjC Class EH) " + Name.str()」式を検査することを検討してください。 シンボル.cpp 38
• V655 [CWE-480] 文字列は連結されましたが、使用されていません。 「Result + "(ObjC IVar)" + Name.str()」式を検査することを検討してください。 シンボル.cpp 41

偶然、+= 演算子の代わりに + 演算子が使用されています。 その結果、意味のないデザインが生まれてしまいます。

フラグメント N21: 未定義の動作

static void getReqFeatures(std::map<StringRef, int> &FeaturesMap,
                           const std::vector<Record *> &ReqFeatures) {
  for (auto &R : ReqFeatures) {
    StringRef AsmCondString = R->getValueAsString("AssemblerCondString");

    SmallVector<StringRef, 4> Ops;
    SplitString(AsmCondString, Ops, ",");
    assert(!Ops.empty() && "AssemblerCondString cannot be empty");

    for (auto &Op : Ops) {
      assert(!Op.empty() && "Empty operator");
      if (FeaturesMap.find(Op) == FeaturesMap.end())
        FeaturesMap[Op] = FeaturesMap.size();
    }
  }
}

危険なコードを自分で見つけてみてください。 そして、これは答えをすぐに見ないように注意をそらすための画像です。

PVS-Studio の警告: V６０ [CWE-758] 危険な構造が使用されています: 'FeatureMap[Op] = featuresMap.size()'、ここで 'FeatureMap' は 'map' クラスです。 これにより、未定義の動作が発生する可能性があります。 RISCVCompressInstEmitter.cpp 490

問題行:

FeaturesMap[Op] = FeaturesMap.size();

If 要素 Op が見つからない場合は、マップ内に新しい要素が作成され、このマップ内の要素の数がそこに書き込まれます。 関数が呼び出されるかどうかは不明です サイズ 新しい要素を追加する前または後。

フラグメント N22 ～ N24: 繰り返しの割り当て

Error MachOObjectFile::checkSymbolTable() const {
  ....
  } else {
    MachO::nlist STE = getSymbolTableEntry(SymDRI);
    NType = STE.n_type;                              // <=
    NType = STE.n_type;                              // <=
    NSect = STE.n_sect;
    NDesc = STE.n_desc;
    NStrx = STE.n_strx;
    NValue = STE.n_value;
  }
  ....
}

PVS-Studio の警告: V６０ [CWE-563] 「NType」変数に値が 1663 回連続して割り当てられています。 おそらくこれは間違いです。 行を確認してください: 1664、1664。MachOObjectFile.cpp XNUMX

ここに本当の間違いがあるとは思えません。 不必要に繰り返される課題です。 しかし、やはり大失敗。

同様に：

• V519 [CWE-563] 'B.NDesc' 変数に値が 1488 回連続して割り当てられます。 おそらくこれは間違いです。 行を確認してください: 1489、1489。llvm-nm.cpp XNUMX
• V519 [CWE-563] 変数に値が 59 回連続して割り当てられています。 おそらくこれは間違いです。 行: 61、2 を確認します。 coff61yaml.cpp XNUMX

フラグメント N25 ～ N27: さらなる再割り当て

次に、少し異なるバージョンの再割り当てを見てみましょう。

bool Vectorizer::vectorizeLoadChain(
    ArrayRef<Instruction *> Chain,
    SmallPtrSet<Instruction *, 16> *InstructionsProcessed) {
  ....
  unsigned Alignment = getAlignment(L0);
  ....
  unsigned NewAlign = getOrEnforceKnownAlignment(L0->getPointerOperand(),
                                                 StackAdjustedAlignment,
                                                 DL, L0, nullptr, &DT);
  if (NewAlign != 0)
    Alignment = NewAlign;
  Alignment = NewAlign;
  ....
}

PVS-Studio 警告: V519 [CWE-563] 「Alignment」変数に値が 1158 回連続して割り当てられています。 おそらくこれは間違いです。 行: 1160、1160 を確認します。LoadStoreVectorizer.cpp XNUMX

これは非常に奇妙なコードであり、明らかに論理エラーが含まれています。 初めは変数 アラインメント 条件に応じて値が割り当てられます。 そして再び割り当てが行われますが、チェックは行われません。

同様の状況がここでも見られます。

• V519 [CWE-563] 「Effects」変数に値が 152 回連続して割り当てられます。 おそらくこれは間違いです。 行: 165、165 を確認します。WebAssemblyRegStackify.cpp XNUMX
• V519 [CWE-563] 'ExpectNoDerefChunk' 変数に 4970 回連続して値が割り当てられます。 おそらくこれは間違いです。 チェック行: 4973、4973。SemaType.cpp XNUMX

フラグメント N28: 常に true 条件

static int readPrefixes(struct InternalInstruction* insn) {
  ....
  uint8_t byte = 0;
  uint8_t nextByte;
  ....
  if (byte == 0xf3 && (nextByte == 0x88 || nextByte == 0x89 ||
                       nextByte == 0xc6 || nextByte == 0xc7)) {
    insn->xAcquireRelease = true;
    if (nextByte != 0x90) // PAUSE instruction support             // <=
      break;
  }
  ....
}

PVS-Studio の警告: V６０ [CWE-571] 式 'nextByte != 0x90' は常に true です。 X86逆アセンブラーデコーダー.cpp 379

検査しても意味ないよ。 変数 次のバイト 常に値と等しくない 0x90、前のチェックから続きます。 これはある種の論理エラーです。

フラグメント N29 - N...: 常に true/false 条件

アナライザーは、状態全体が悪化するという警告を多数発行します (V６０) またはその一部 (V６０) は常に true または false です。 多くの場合、これらは実際のエラーではなく、単純にずさんなコードやマクロ展開の結果などです。 ただし、本物の論理エラーが時々発生するため、これらの警告をすべて確認することは意味があります。 たとえば、コードの次のセクションは疑わしいです。

static DecodeStatus DecodeGPRPairRegisterClass(MCInst &Inst, unsigned RegNo,
                                   uint64_t Address, const void *Decoder) {
  DecodeStatus S = MCDisassembler::Success;

  if (RegNo > 13)
    return MCDisassembler::Fail;

  if ((RegNo & 1) || RegNo == 0xe)
     S = MCDisassembler::SoftFail;
  ....
}

PVS-Studio の警告: V６０ [CWE-570] 条件式の一部が常に false になります: RegNo == 0xe。 ARMDisassembler.cpp 939

定数 0xE は、14 進数の値 XNUMX です。 検査 RegNo == 0xe 意味がありません。 登録番号 > 13、その後、関数は実行を完了します。

他にも ID V547 および V560 の警告が多数ありましたが、 V６０, 私はこれらの警告を研究することに興味がありませんでした。 記事を書くのに十分な材料があることはすでに明らかでした :)。 したがって、PVS-Studio を使用して LLVM でこのタイプのエラーをどれだけ特定できるかは不明です。

これらのトリガーの研究が退屈である理由の例を示します。 アナライザーが次のコードに対して警告を発行したのは完全に正しいです。 しかし、これも間違いではありません。

bool UnwrappedLineParser::parseBracedList(bool ContinueOnSemicolons,
                                          tok::TokenKind ClosingBraceKind) {
  bool HasError = false;
  ....
  HasError = true;
  if (!ContinueOnSemicolons)
    return !HasError;
  ....
}

PVS-Studio 警告: V547 [CWE-570] 式 '!HasError' は常に false です。 1635

フラグメントN30: 不審な帰還

static bool
isImplicitlyDef(MachineRegisterInfo &MRI, unsigned Reg) {
  for (MachineRegisterInfo::def_instr_iterator It = MRI.def_instr_begin(Reg),
      E = MRI.def_instr_end(); It != E; ++It) {
    return (*It).isImplicitDef();
  }
  ....
}

PVS-Studio の警告: V６０ [CWE-670] ループ内の無条件の「リターン」。 R600OptimizeVectorRegisters.cpp 63

これはエラー、またはコードを読んでいるプログラマーに何かを説明することを目的とした特定のテクニックのいずれかです。 このデザインは私には何も説明できず、非常に疑わしいように見えます。 そのように書かないほうがいいです:)。

疲れた？ 次に、お茶またはコーヒーを作る時間です。

新しい診断によって特定された欠陥

古い診断のアクティベーションは 30 回で十分だと思います。 次に、アナライザーに表示された新しい診断でどのような興味深いことが見つかるかを見てみましょう。 前へ 小切手。 この期間中に、合計 66 の汎用診断が C++ アナライザーに追加されました。

フラグメント N31: 到達不能なコード

Error CtorDtorRunner::run() {
  ....
  if (auto CtorDtorMap =
          ES.lookup(JITDylibSearchList({{&JD, true}}), std::move(Names),
                    NoDependenciesToRegister, true))
  {
    ....
    return Error::success();
  } else
    return CtorDtorMap.takeError();

  CtorDtorsByPriority.clear();

  return Error::success();
}

PVS-Studio の警告: V６０ [CWE-561] 到達不能なコードが検出されました。 エラーが存在する可能性があります。 実行ユーティリティ.cpp 146

ご覧のとおり、演算子の両方の分岐は if オペレーターへの電話で終了 return。 したがって、コンテナは、 CtorDtorsByPriority 決してクリアされません。

フラグメント N32: 到達不能なコード

bool LLParser::ParseSummaryEntry() {
  ....
  switch (Lex.getKind()) {
  case lltok::kw_gv:
    return ParseGVEntry(SummaryID);
  case lltok::kw_module:
    return ParseModuleEntry(SummaryID);
  case lltok::kw_typeid:
    return ParseTypeIdEntry(SummaryID);                        // <=
    break;                                                     // <=
  default:
    return Error(Lex.getLoc(), "unexpected summary kind");
  }
  Lex.setIgnoreColonInIdentifiers(false);                      // <=
  return false;
}

PVS-Studio 警告: V779 [CWE-561] 到達不能なコードが検出されました。 エラーが存在する可能性があります。 LLParser.cpp 835

興味深い状況です。 まずはこの場所を見てみましょう。

return ParseTypeIdEntry(SummaryID);
break;

一見すると、ここには間違いがないように見えます。 オペレーターっぽい 破る ここには余分なものがありますが、単純に削除できます。 ただし、すべてがそれほど単純ではありません。

アナライザーは次の行で警告を発行します。

Lex.setIgnoreColonInIdentifiers(false);
return false;

そして確かに、このコードは到達できません。 すべてのケース スイッチ オペレーターからの電話で終了 return。 そして今は一人では無意味 破る それほど無害には見えません！ おそらくブランチの XNUMX つは次のように終わるはずです。 破るしかしではない return?

フラグメント N33: 上位ビットのランダム リセット

unsigned getStubAlignment() override {
  if (Arch == Triple::systemz)
    return 8;
  else
    return 1;
}

Expected<unsigned>
RuntimeDyldImpl::emitSection(const ObjectFile &Obj,
                             const SectionRef &Section,
                             bool IsCode) {
  ....
  uint64_t DataSize = Section.getSize();
  ....
  if (StubBufSize > 0)
    DataSize &= ~(getStubAlignment() - 1);
  ....
}

PVS-Studio の警告: V６０ ビット マスクのサイズは、最初のオペランドのサイズよりも小さいです。 これにより、上位ビットが失われます。 ランタイムディルド.cpp 815

機能に注意してください getStubAlignment 戻り値の型 署名されていない。 関数が値 8 を返すと仮定して、式の値を計算してみましょう。

~(getStubAlignment() - 1)

~(8u-1)

0xFFFFFFFF8u

ここで、変数に注目してください。 データサイズ 64 ビットの符号なし型を持ちます。 DataSize & 0xFFFFFFF8u 操作を実行すると、上位 0 ビットがすべて 8 にリセットされることがわかります。 おそらく、これはプログラマが望んでいたものではありません。 おそらく彼は DataSize & XNUMXxFFFFFFFFFFFFFFXNUMXu を計算したかったのだと思います。

エラーを修正するには、次のように記述する必要があります。

DataSize &= ~(static_cast<uint64_t>(getStubAlignment()) - 1);

それとも：

DataSize &= ~(getStubAlignment() - 1ULL);

フラグメント N34: 明示的な型キャストの失敗

template <typename T>
void scaleShuffleMask(int Scale, ArrayRef<T> Mask,
                      SmallVectorImpl<T> &ScaledMask) {
  assert(0 < Scale && "Unexpected scaling factor");
  int NumElts = Mask.size();
  ScaledMask.assign(static_cast<size_t>(NumElts * Scale), -1);
  ....
}

PVS-Studio の警告: V６０ [CWE-190] オーバーフローの可能性があります。 'NumElts * Scale' 演算子のオペランドを結果ではなく 'size_t' 型にキャストすることを検討してください。 X86ISelLowering.h 1577

型変数を乗算する際のオーバーフローを避けるために、明示的な型キャストが使用されます。 int型。 ただし、ここでの明示的な型キャストはオーバーフローを防ぐものではありません。 まず変数が乗算され、その後で乗算の 32 ビット結果が型に展開されます。 サイズ_t.

フラグメント N35: コピー＆ペーストの失敗

Instruction *InstCombiner::visitFCmpInst(FCmpInst &I) {
  ....
  if (!match(Op0, m_PosZeroFP()) && isKnownNeverNaN(Op0, &TLI)) {
    I.setOperand(0, ConstantFP::getNullValue(Op0->getType()));
    return &I;
  }
  if (!match(Op1, m_PosZeroFP()) && isKnownNeverNaN(Op1, &TLI)) {
    I.setOperand(1, ConstantFP::getNullValue(Op0->getType()));        // <=
    return &I;
  }
  ....
}

V６０ [CWE-682] 1 つの類似したコードの断片が見つかりました。 おそらく、これはタイプミスであり、「Op0」の代わりに「Op5507」変数を使用する必要があります。 InstCombineCompares.cpp XNUMX

この新しい興味深い診断は、コードの一部がコピーされ、その中の一部の名前が変更され始めているにもかかわらず、ある場所が修正されていない状況を特定します。

XNUMX 番目のブロックでは変更されていることに注意してください Op0 на Op1。 しかし、ある場所では修正されませんでした。 おそらく次のように書かれているはずです。

if (!match(Op1, m_PosZeroFP()) && isKnownNeverNaN(Op1, &TLI)) {
  I.setOperand(1, ConstantFP::getNullValue(Op1->getType()));
  return &I;
}

フラグメント N36: 変数の混乱

struct Status {
  unsigned Mask;
  unsigned Mode;

  Status() : Mask(0), Mode(0){};

  Status(unsigned Mask, unsigned Mode) : Mask(Mask), Mode(Mode) {
    Mode &= Mask;
  };
  ....
};

PVS-Studio の警告: V６０ [CWE-563] 「Mode」変数が割り当てられていますが、関数の最後までは使用されません。 SIModeRegister.cpp 48

関数の引数にクラス メンバーと同じ名前を付けるのは非常に危険です。 非常に混乱しやすいです。 まさにそのようなケースが私たちの目の前にあります。 この表現は意味がありません:

Mode &= Mask;

関数の引数が変わります。 それだけです。 この引数はもう使用されません。 ほとんどの場合、次のように記述する必要があります。

Status(unsigned Mask, unsigned Mode) : Mask(Mask), Mode(Mode) {
  this->Mode &= Mask;
};

フラグメント N37: 変数の混乱

class SectionBase {
  ....
  uint64_t Size = 0;
  ....
};

class SymbolTableSection : public SectionBase {
  ....
};

void SymbolTableSection::addSymbol(Twine Name, uint8_t Bind, uint8_t Type,
                                   SectionBase *DefinedIn, uint64_t Value,
                                   uint8_t Visibility, uint16_t Shndx,
                                   uint64_t Size) {
  ....
  Sym.Value = Value;
  Sym.Visibility = Visibility;
  Sym.Size = Size;
  Sym.Index = Symbols.size();
  Symbols.emplace_back(llvm::make_unique<Symbol>(Sym));
  Size += this->EntrySize;
}

警告 PVS-Studio: V1001 [CWE-563] 「Size」変数が割り当てられていますが、関数の最後までは使用されません。 オブジェクト.cpp 424

状況は前回と同様です。 次のように書く必要があります:

this->Size += this->EntrySize;

断片 N38-N47: インデックスを確認するのを忘れました

前回は、診断トリガーの例について説明しました。 V６０。 その本質は、ポインタが最初に逆参照され、その後にのみチェックされることです。 若い診断者 V６０ 意味は逆ですが、多くの間違いも明らかになります。 ポインタが最初にチェックされ、その後チェックを忘れた状況を識別します。 LLVM 内で見つかったそのようなケースを見てみましょう。

int getGEPCost(Type *PointeeType, const Value *Ptr,
               ArrayRef<const Value *> Operands) {
  ....
  if (Ptr != nullptr) {                                            // <=
    assert(....);
    BaseGV = dyn_cast<GlobalValue>(Ptr->stripPointerCasts());
  }
  bool HasBaseReg = (BaseGV == nullptr);

  auto PtrSizeBits = DL.getPointerTypeSizeInBits(Ptr->getType());  // <=
  ....
}

PVS-Studio 警告: V1004 [CWE-476] 'Ptr' ポインターは、nullptr に対して検証された後、安全に使用されませんでした。 行: 729、738 を確認してください。TargetTransformInfoImpl.h 738

可変 PTR 等しいかもしれない nullptr、チェックによって証明されるように:

if (Ptr != nullptr)

ただし、このポインタより下では、事前チェックなしで逆参照されます。

auto PtrSizeBits = DL.getPointerTypeSizeInBits(Ptr->getType());

別の同様のケースを考えてみましょう。

llvm::DISubprogram *CGDebugInfo::getFunctionFwdDeclOrStub(GlobalDecl GD,
                                                          bool Stub) {
  ....
  auto *FD = dyn_cast<FunctionDecl>(GD.getDecl());
  SmallVector<QualType, 16> ArgTypes;
  if (FD)                                                                // <=
    for (const ParmVarDecl *Parm : FD->parameters())
      ArgTypes.push_back(Parm->getType());
  CallingConv CC = FD->getType()->castAs<FunctionType>()->getCallConv(); // <=
  ....
}

PVS-Studio 警告: V1004 [CWE-476] 「FD」ポインターは、nullptr に対して検証された後、安全に使用されませんでした。 行を確認してください: 3228、3231。CGDebugInfo.cpp 3231

標識に注意してください FD。 問題は明らかであり、特別な説明は必要ないと思います。

さらに：

static void computePolynomialFromPointer(Value &Ptr, Polynomial &Result,
                                         Value *&BasePtr,
                                         const DataLayout &DL) {
  PointerType *PtrTy = dyn_cast<PointerType>(Ptr.getType());
  if (!PtrTy) {                                                   // <=
    Result = Polynomial();
    BasePtr = nullptr;
  }
  unsigned PointerBits =
      DL.getIndexSizeInBits(PtrTy->getPointerAddressSpace());     // <=
  ....
}

PVS-Studio 警告: V1004 [CWE-476] 「PtrTy」ポインターは、nullptr に対して検証された後、安全に使用されませんでした。 行を確認してください: 960、965。 InterleavedLoadCombinePass.cpp 965

このようなエラーから身を守るにはどうすればよいでしょうか? コードレビューにさらに注意を払い、PVS-Studio 静的アナライザーを使用してコードを定期的にチェックしてください。

このタイプのエラーがある他のコード断片を引用することは意味がありません。 記事には警告のリストのみを残しておきます。

• V1004 [CWE-476] 'Expr' ポインタは、nullptr に対して検証された後、安全に使用されませんでした。 行を確認してください: 1049、1078。 DebugInfoMetadata.cpp 1078
• V1004 [CWE-476] nullptr に対して検証された後、「PI」ポインタが安全に使用されませんでした。 行を確認してください: 733、753。 LegacyPassManager.cpp 753
• V1004 [CWE-476] 「StatepointCall」ポインタは、nullptr に対して検証された後、安全に使用されませんでした。 行を確認してください: 4371、4379。 Verifier.cpp 4379
• V1004 [CWE-476] 「RV」ポインタは、nullptr に対して検証された後、安全に使用されませんでした。 行を確認します: 2263、2268。TGParser.cpp 2268
• V1004 [CWE-476] 'CalleeFn' ポインターは、nullptr に対して検証された後、安全に使用されませんでした。 行を確認してください: 1081、1096。SimplifyLibCalls.cpp 1096
• V1004 [CWE-476] nullptr に対して検証された後、'TC' ポインタが安全に使用されませんでした。 行を確認してください: 1819、1824。 Driver.cpp 1824

フラグメント N48 ～ N60: 重大ではありませんが、欠陥 (メモリ リークの可能性があります)

std::unique_ptr<IRMutator> createISelMutator() {
  ....
  std::vector<std::unique_ptr<IRMutationStrategy>> Strategies;
  Strategies.emplace_back(
      new InjectorIRStrategy(InjectorIRStrategy::getDefaultOps()));
  ....
}

PVS-Studio の警告: V６０ [CWE-460] 所有者のないポインタが「emplace_back」メソッドによって「Strategies」コンテナに追加されます。 例外が発生するとメモリ リークが発生します。 llvm-isel-fuzzer.cpp 58

次のようにコンテナの最後に要素を追加するには std::vector > ただ書くことはできません xxx.push_back(新しい X)からの暗黙的な変換がないため、 X* в std::unique_ptr.

一般的な解決策は次のように書くことです xxx.emplace_back(新しい X)コンパイルされるので：メソッド emplace_back 引数から直接要素を構築するため、明示的なコンストラクターを使用できます。

安全ではありません。 ベクターがいっぱいの場合、メモリが再割り当てされます。 メモリの再割り当て操作が失敗し、例外がスローされる場合があります。 std::bad_alloc。 この場合、ポインタは失われ、作成されたオブジェクトは削除されません。

安全な解決策は、 unique_ptrこれは、ベクトルがメモリの再割り当てを試みる前にポインタを所有します。

xxx.push_back(std::unique_ptr<X>(new X))

C++14 以降、「std::make_unique」を使用できます。

xxx.push_back(std::make_unique<X>())

このタイプの欠陥は、LLVM にとって重大ではありません。 メモリを割り当てられない場合、コンパイラは単に停止します。 ただし、長いアプリケーションの場合は、 稼働時間メモリ割り当てに失敗した場合に単に終了することはできませんが、これは非常に厄介なバグである可能性があります。

したがって、このコードは LLVM に対して実質的な脅威をもたらすものではありませんが、このエラー パターンと、PVS-Studio アナライザーがそれを識別する方法を学習したことについて説明することが有益であることがわかりました。

このタイプのその他の警告:

• V1023 [CWE-460] 所有者のないポインターが、「emplace_back」メソッドによって「Passes」コンテナーに追加されます。 例外が発生するとメモリ リークが発生します。 PassManager.h 546
• V1023 [CWE-460] 所有者のないポインターが 'emplace_back' メソッドによって 'AAs' コンテナーに追加されます。 例外が発生するとメモリ リークが発生します。 エイリアス分析.h 324
• V1023 [CWE-460] 所有者のないポインターが、「emplace_back」メソッドによって「Entries」コンテナーに追加されます。 例外が発生するとメモリ リークが発生します。 DWARFDebugFrame.cpp 519
• V1023 [CWE-460] 所有者のないポインターが、'emplace_back' メソッドによって 'AllEdges' コンテナーに追加されます。 例外が発生するとメモリ リークが発生します。 CFGMST.h 268
• V1023 [CWE-460] 所有者のないポインターが 'emplace_back' メソッドによって 'VMaps' コンテナーに追加されます。 例外が発生するとメモリ リークが発生します。 SimpleLoopUnswitch.cpp 2012
• V1023 [CWE-460] 所有者のないポインターが、'emplace_back' メソッドによって 'Records' コンテナーに追加されます。 例外が発生するとメモリ リークが発生します。 FDRLogBuilder.h 30
• V1023 [CWE-460] 所有者のないポインターが、'emplace_back' メソッドによって 'PendingSubmodules' コンテナーに追加されます。 例外が発生するとメモリ リークが発生します。 モジュールマップ.cpp 810
• V1023 [CWE-460] 所有者のないポインターが 'emplace_back' メソッドによって 'Objects' コンテナーに追加されます。 例外が発生するとメモリ リークが発生します。 デバッグマップ.cpp 88
• V1023 [CWE-460] 所有者のないポインターが、'emplace_back' メソッドによって 'Strategies' コンテナーに追加されます。 例外が発生するとメモリ リークが発生します。 llvm-isel-fuzzer.cpp 60
• V1023 [CWE-460] 所有者のないポインターが、'emplace_back' メソッドによって 'Modifiers' コンテナーに追加されます。 例外が発生するとメモリ リークが発生します。 llvm-ストレス.cpp 685
• V1023 [CWE-460] 所有者のないポインターが、'emplace_back' メソッドによって 'Modifiers' コンテナーに追加されます。 例外が発生するとメモリ リークが発生します。 llvm-ストレス.cpp 686
• V1023 [CWE-460] 所有者のないポインターが、'emplace_back' メソッドによって 'Modifiers' コンテナーに追加されます。 例外が発生するとメモリ リークが発生します。 llvm-ストレス.cpp 688
• V1023 [CWE-460] 所有者のないポインターが、'emplace_back' メソッドによって 'Modifiers' コンテナーに追加されます。 例外が発生するとメモリ リークが発生します。 llvm-ストレス.cpp 689
• V1023 [CWE-460] 所有者のないポインターが、'emplace_back' メソッドによって 'Modifiers' コンテナーに追加されます。 例外が発生するとメモリ リークが発生します。 llvm-ストレス.cpp 690
• V1023 [CWE-460] 所有者のないポインターが、'emplace_back' メソッドによって 'Modifiers' コンテナーに追加されます。 例外が発生するとメモリ リークが発生します。 llvm-ストレス.cpp 691
• V1023 [CWE-460] 所有者のないポインターが、'emplace_back' メソッドによって 'Modifiers' コンテナーに追加されます。 例外が発生するとメモリ リークが発生します。 llvm-ストレス.cpp 692
• V1023 [CWE-460] 所有者のないポインターが、'emplace_back' メソッドによって 'Modifiers' コンテナーに追加されます。 例外が発生するとメモリ リークが発生します。 llvm-ストレス.cpp 693
• V1023 [CWE-460] 所有者のないポインターが、'emplace_back' メソッドによって 'Modifiers' コンテナーに追加されます。 例外が発生するとメモリ リークが発生します。 llvm-ストレス.cpp 694
• V1023 [CWE-460] 所有者のないポインターが、'emplace_back' メソッドによって 'Operands' コンテナーに追加されます。 例外が発生するとメモリ リークが発生します。 GlobalISelEmitter.cpp 1911
• V1023 [CWE-460] 所有者のないポインターが、'emplace_back' メソッドによって 'Stash' コンテナーに追加されます。 例外が発生するとメモリ リークが発生します。 GlobalISelEmitter.cpp 2100
• V1023 [CWE-460] 所有者のないポインターが、「emplace_back」メソッドによって「Matchers」コンテナーに追加されます。 例外が発生するとメモリ リークが発生します。 GlobalISelEmitter.cpp 2702

まとめ

合計60回の警告を発して停止しました。 PVS-Studio アナライザーが LLVM で検出する他の欠陥はありますか? はい、あります。 しかし、記事用のコードの断片を書き出していると、夕方、というか夜になってしまったので、もう終わりにしようと決心しました。

興味を持っていただき、PVS-Studio アナライザーを試してみていただければ幸いです。

アナライザーをダウンロードして、マインスイーパのキーを入手できます。 このページ.

最も重要なことは、静的分析を定期的に使用することです。 XNUMX回限りのチェック、静的解析の方法論と PVS-Studio を普及させるために当社が実施するシナリオは通常のシナリオではありません。

コードの品質と信頼性が向上するよう頑張ってください。

この記事を英語圏の読者と共有したい場合は、翻訳リンクを使用してください: Andrey Karpov。 PVS-Studio を使用した LLVM 8 のバグの検索.

出所： habr.com