Otsime vea LLVM 8-s PVS-Studio analüsaatori abil

Kaks aastat on möödunud viimati LLVM projekti koodi PVS-Studio analüsaatoriga kontrollimisest. Veendume, et PVS-Studio on endiselt juhtiv tööriist vigade ja potentsiaalsete haavatavuste tuvastamiseks. Uurime ja leiame uusi vigu LLVM 8.0.0 väljaandes.

Artikkel, mis peaks olema kirjutatud

Ausalt öeldes, ma ei tahtnud seda artiklit kirjutada. Pole huvitav kirjutada projektist, mida oleme juba korduvalt kontrollinud (1, 2, 3). Parema meelega kirjutaksin millestki uuest, kuid valikut mul pole.

Iga kord, kui ilmub uus LLVM versioon või see uuendatakse Clang Static Analyzer, jõuavad meie postkasti sellised küsimused:

Vaadake, uus Clang Static Analyzer versioon suudab tuvastada uusi vigu! Mul on tunne, et PVS-Studio kasutamise tähtsus väheneb. Clang leiab rohkem vigu kui varem ja jõuab PVS-Studio võimalustele järele. Mida teie sellest arvate?

Sellele tahaks alati vastata millegagi taolisega:

Me ei istu ka käed ristis! Me oleme oluliselt parandanud PVS-Studio analüsaatori võimalusi. Nii et ärge muretsege, me jätkame juhtimist nagu alati.

Kahjuks on see halb vastus. Selles pole piisavalt tõendeid. Ja just seetõttu kirjutan ma nüüd seda artiklit. Seega on projekti LLVM järjekordne kontroll viinud hämmastavate vigadena. Need, mis tundusid mulle huvitavad, demonstreerin hetkel. Need vead ei suuda avastada Clang Static Analyzer (või on selle abil äärmiselt ebamugav neid otsida). Aga me saame. Ja ma leidsin ja kirjutasin üles kõik need vead ühe õhtu jooksul.

Aga artikli kirjutamine venis mitme nädala peale. Ei saanud end kuidagi sundida, et kõik see teksti vormi panna : ).

Muide, kui teid huvitab, milliseid tehnoloogiaid kasutatakse PVS-Studio analüsaatoris vigade ja potentsiaalsete haavatavuste tuvastamiseks, siis kutsun teid tutvuma selle märkmega.

Uued ja vanad diagnostikad

Nagu juba mainitud, kontrolliti projekti LLVM umbes kaks aastat tagasi ja leitud vead parandati. Nüüd esitan selles artiklis uue koguse vigu. Miks leiti uusi vigu? Sellel on 3 põhjust:

1. LLVM projekt areneb, vanas koodis tehakse muudatusi ja uut koodi lisandub. Loomulikult on muudetud ja kirjutatud koodis uusi vigu. See demonstreerib hästi, et staatilist analüüsi tuleks rakendada regulaarselt, mitte juhuslikult. Meie artiklid näitavad hästi PVS-Studio analüsaatori võimalusi, kuid see ei ole seotud koodi kvaliteedi tõstmise ja vigade parandamise kulude vähendamisega. Kasutage staatilist koodianalüsaatorit regulaarselt!
2. Täiendame ja täiustame juba olemasolevaid diagnostikaid. Seetõttu saab analüsaator tuvastada vigu, mida varasemate kontrollde käigus ei märgatud.
3. PVS-Studios on ilmunud uusi diagnostikaid, mida 2 aastat tagasi ei olnud. Otsustasin need välja tuua eraldi jaotises, et selgelt näidata PVS-Studio arengut.

Defektid, mille tuvastamisega tegeleti 2 aastat tagasi

Fragment N1: Copy-Paste

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

PVS-Studio hoiatamine: V501 [CWE-570] Vasakul ja paremal ‘||’ operaatoril on identseid alamväljendeid ‘Name.startswith(«avx512.mask.permvar.»)’. AutoUpgrade.cpp 73

Kontrollitakse kaks korda, et nimi algab alamhulga «avx512.mask.permvar.». Teises kontrollis soovis ilmselt midagi muud kirjutada, kuid unustas kopeeritud teksti muuta.

Fragment N2: Trükiviga

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 hoiatamine: V501 Vasakul ja paremal ‘|’ operaatoril on identseid alamväljendeid ‘CXNameRange_WantQualifier’. CIndex.cpp 7245

Trükivea tõttu kasutatakse kaks korda sama nimelist konstanti CXNameRange_WantQualifier.

Fragment N3: Operaatorite prioriteedi segadus

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

PVS-Studio hoiatamine: V502 [CWE-783] Võib-olla töötab ‘?:’ operaator ootamatult. ‘?:’ operaatori prioriteet on madalam kui ‘==’ operaatori prioriteet. PPCTargetTransformInfo.cpp 404

Minu arvates on see väga ilus viga. Jah, ma tean, et mul on kummalised arusaamad ilust :).

Praegu, vastavalt operaatorite prioriteetidele, arvutatakse väljend järgmiselt:

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

Praktilise poole pealt ei oma selline tingimus mõtet, kuna seda saab lühendada järgmiseks:

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

See on ilmne viga. Tõenäoliselt soovisid 0/1 võrrelda muutujaga Indeks. Koodi parandamiseks on vajalik lisada sulud ternaarse operaatori ümber:

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

Üks asi, ternearne operaator on väga ohtlik ja kutsub esile loogilisi vigu. Olge selle kasutamisel väga ettevaatlik ja ärge olge ahne, et lisada ümmarguseid sulge. Selle teema olen lähemalt käsitlenud siit, peatükis «Kartke operaatorit ?: ja sulgege see ümmarguste sulgudega».

Fragment N4, N5: Nullviide

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

PVS-Studio hoiatamine: V522 [CWE-476] Null-pointeri ‘LHS’ lahkamine võib toimuda. TGParser.cpp 2152

Kui näidik LHS osutub nulliks, siis peaks tekkima hoiatus. Kuid selle asemel toimub null-näidiku lahkamine: LHS->getAsString().

See on üsna tavaline olukord, kus viga peidab end veahaldurites, kuna neid ei testita. Statilised analüsaatorid kontrollivad kogu ligipääsetavat koodi, sõltumata sellest, kui sageli seda kasutatakse. See on väga hea näide sellest, kuidas staatiline analüüs täiendab teisi testimise ja vigade vältimise meetodeid.

Sarnane näidiku haldamise viga RHS on tehtud koodi veidi allpool: V522 [CWE-476] Null-pointeri ‘RHS’ lahkamine võib toimuda. TGParser.cpp 2186

Fragment N6: Näidiku kasutamine pärast liigutamist

static Expected
ExtractBlocks(....)
{
  ....
  std::unique_ptr ProgClone = CloneModule(BD.getProgram(), VMap);
  ....
  BD.setNewProgram(std::move(ProgClone));                                // getFunction(MisCompFunctions[i].first);  // <=
    assert(NewF && "Function not found??");
    MiscompiledFunctions.push_back(NewF);
  }
  ....
}

PVS-Studio hoiatuse: V522 [CWE-476] Null-viidatud "ProgClone" võib juhtuda. Miscompilation.cpp 601

Alguses nutikas näitaja ProgClone lakkab objekti omamisest:

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

Tegelikult, nüüd ProgClone on see null-viidatus. Seega peaks allpool toimuma null-viidatuse dereferents:

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

Kuid tegelikult ei juhtu seda! Pange tähele, et tsükkel ei toimu.

Alguses konteiner MiscompiledFunctions kustutatakse:

MiscompiledFunctions.clear();

Seejärel kasutatakse selle konteineri suurust tsükli tingimuses:

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

On lihtne näha, et tsükkel ei käivitu. Arvan, et see on samuti viga ja kood peaks olema kirjutatud muul viisil.

Tundub, et oleme kohanud seda kuulsat vigade paaritust! Üks viga varjab teist :).

Fragmendi N7: Näidiku kasutamine pärast liikumist

static Expected<bool> TestOptimizer(BugDriver &BD, std::unique_ptr<Module> Test,
                                    std::unique_ptr<Module> Safe) {
  outs() << "  Optimeerimise all olevad funktsioonid: ";
  std::unique_ptr<Module> Optimized =
      BD.runPassesOn(Test.get(), BD.getPassesToRun());
  if (!Optimized) {
    errs() << " Viga selle passide järjestuse käitamisel"
           << " sisendprogrammil!n";
    BD.setNewProgram(std::move(Test));                       // <=
    BD.EmitProgressBitcode(*Test, "pass-error", false);      // <=
    if (Error E = BD.debugOptimizerCrash())
      return std::move(E);
    return false;
  }
  ....
}

Hoiatus PVS-Studio: V522 [CWE-476] Null-punkti ‘Test’ dereferentseerimine võib toimuda. Miscompilation.cpp 709

Taaskord sama olukord. Alguses liigub objekti sisu ja seejärel kasutatakse seda nagu poleks midagi juhtunud. Kohtan seda olukorda üha sagedamini programmikoodis, pärast seda, kui C++-sse tuli liikumissemantika. Selle pärast ma armastan C++ keelt! Ilmuvad üha uusi ja uusi viise endale jalga tulistamiseks. Analüüsija PVS-Studio'l on alati tööd :).

Fragmendi N8: Null-näidik

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

PVS-Studio hoiatus: V522 [CWE-476] Null-viite ‘Type’ dereferentseerimine võib toimuda. PrettyFunctionDumper.cpp 233

Lisaks veahalduritele testitakse tavaliselt ka andmete silumisfunktsioone. See on täpselt selline juhtum. Funktsioon ootab kasutajat, kes peab oma probleemide lahendamise asemel tegelema selle parandamisega.

Õige:

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

Fragment N9: Null-viide

void SearchableTableEmitter::collectTableEntries(
    GenericTable &Table, const std::vector &Items) {
  ....
  RecTy *Ty = resolveTypes(Field.RecType, TI->getType());
  if (!Ty)                                                              // getAsString() + " vs. " +                       // getType()->getAsString());
   ....
}

PVS-Studio hoiatus: V522 [CWE-476] Null-viite ‘Ty’ dereferentseerimine võib toimuda. SearchableTableEmitter.cpp 614

Ma arvan, et kõik on selge ja selgitust ei vaja.

Fragment N10: Trüki viga

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 hoiatamine: V570 Muutuja ‘Identifier->Type’ on määratud iseendale. FormatTokenLexer.cpp 249

Pole mõtet määrata muutujat iseendale. Tõenäoliselt sooviti kirjutada:

Identifier->Type = Question->Type;

Fragment N11: Kahtlane break

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 hoiatamine: V622 [CWE-478] Kaaluge ‘switch’ lause uurimist. Tõenäoliselt on esimene ‘case’ operaator puudu. SystemZAsmParser.cpp 652

Alguses on väga kahtlane operaator break. Kas ei unustatud siia midagi veel kirjutada?

Fragment N12: Näidiku kontroll pärast dereferentsimist

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 hoiatamine: V595 [CWE-476] ‘Callee’ näidik kasutati enne, kui seda kontrolliti nullptr vastu. Kontrollige ridu: 172, 174. AMDGPUInline.cpp 172

Viit Callee dereferentseeritakse kohe funktsiooni kutsumise hetkel getTTI.

Ja siis selgub, et seda näidikut tuleks kontrollida võrdsuse osas nullptr:

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

Aga on juba liiga hilja…

Fragment N13 — N…: Näidiku kontroll pärast dereferentsimist

Koodifragmendis käsitletud olukord ei ole ainulaadne. See esineb siin:

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 hoiatatakse: V595 [CWE-476] 'CalleeFn' näidiku kasutamine enne, kui see on kontrollitud nullptr vastu. Kontrollige ridu: 1079, 1081. SimplifyLibCalls.cpp 1079

Ja siin:

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 hoiatatakse: V595 [CWE-476] 'ND' näidiku kasutamine enne, kui see on kontrollitud nullptr vastu. Kontrollige ridu: 532, 534. SemaTemplateInstantiateDecl.cpp 532

Ja siin:

• V595 [CWE-476] 'U' näidiku kasutamine enne, kui see on kontrollitud nullptr vastu. Kontrollige ridu: 404, 407. DWARFFormValue.cpp 404
• V595 [CWE-476] 'ND' näidiku kasutamine enne, kui see on kontrollitud nullptr vastu. Kontrollige ridu: 2149, 2151. SemaTemplateInstantiate.cpp 2149

Ja järgmisel hetkel muutus mulle V595 numbriga hoiatused uurida vähem huvitavaks. Seega ei tea ma, kas siin on veel analoogseid vigu peale nimetatute.

Fragment N17, N18: Kahtlane nihke

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

PVS-Studio hoiatamine: V629 [CWE-190] Kaaluge ‘~(Size — 1) << 1’ väljendi kontrollimist. 32-bitise väärtuse bititasemeline nihutamine, millele järgneb laienemine 64-bitise tüübini. AArch64AddressingModes.h 260

Võib-olla see ei ole viga, ja kood töötab just nii, nagu plaanitud. Kuid see on selgelt väga kahtlane koht ja see tuleb üle vaadata.

Oletame, et muutuja Suurus on 16, ning koodi autor plaanis, et muutuja NImms saab väärtuse:

1111111111111111111111111111111111111111111111111111111111100000

Kuid tegelikult tuleb väärtuseks:

0000000000000000000000000000000011111111111111111111111111100000

Asi on selles, et kõik arvutused toimuvad 32-bitise unsigned tüübi kasutamisel. Ja alles pärast seda laieneb see 32-bitine signaalita tüüp automaatselt uint64_ttüübiks. Sellega kaasneb see, et kõrgemad bitid on nullid.

Probleemi saab lahendada nii:

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

Sarnane olukord: V629 [CWE-190] Kaaluge ‘Immr << 6’ väljendi kontrollimist. 32-bitise väärtuse bititasemeline nihutamine, millele järgneb laienemine 64-bitise tüübini. AArch64AddressingModes.h 269

Fragment N19: Omandatud märksõna muud?

void AMDGPUAsmParser::cvtDPP(MCInst & Inst, const OperandVector & Operands) {
  ....
  if (Op.isReg() && Op.Reg.RegNo == AMDGPU::VCC) {
    // VOP2b (v_add_u32, v_sub_u32 ...) dpp kasutab "vcc" märgendit.
    // Jätame vahele.
    continue;
  } if (isRegOrImmWithInputMods(Desc, Inst.getNumOperands())) {    // <=
    Op.addRegWithFPInputModsOperands(Inst, 2);
  } else if (Op.isDPPCtrl()) {
    Op.addImmOperands(Inst, 1);
  } else if (Op.isImm()) {
    // Käsitleme valikulisi argumendi
    OptionalIdx[Op.getImmTy()] = I;
  } else {
    llvm_unreachable("Kehtetu operanditüüp");
  }
  ....
}

PVS-Studio hoiatamine: V646 [CWE-670] Kaaluge rakenduse loogika kontrollimist. On võimalik, et 'else' märksõna on puudu. AMDGPUAsmParser.cpp 5655

Siin pole vigu. Kuna esimese if then-plokk lõpeb continue, siis pole oluline, kas märksõna muud on või ei. Igal juhul töötab kood sama moodi. Siiski, puuduolev muud teeb koodi vähem arusaadavaks ja ohtlikuks. Kui hiljem continue kaob, hakkab kood tööle hoopis teistmoodi. Minu arvates on parem lisada muud.

Fragment N20: Neli sarnast trükiviga

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 hoiatused:

• V655 [CWE-480] Stringid liideti, kuid neid ei kasutata. Soovitame kontrollida väljendit ‘Result + Name.str()’. Symbol.cpp 32
• V655 [CWE-480] Stringid liideti, kuid neid ei kasutata. Soovitame kontrollida väljendit ‘Result + «(ObjC Class) » + Name.str()’. Symbol.cpp 35
• V655 [CWE-480] Stringid liideti, kuid neid ei kasutata. Soovitame kontrollida väljendit ‘Result + «(ObjC Class EH) » + Name.str()’. Symbol.cpp 38
• V655 [CWE-480] Stringid liideti, kuid neid ei kasutata. Soovitame kontrollida väljendit ‘Result + «(ObjC IVar) » + Name.str()’. Symbol.cpp 41

Juhuslikult kasutatakse operatori += asemel operatorit +. Tulemuseks on mõttetu konstruktsioon.

Fragment N21: Määramatu käitumine

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

    SmallVector 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();
    }
  }
}

Proovige iseseisvalt ohtlik kood leida. Ja see pilt on tähelepanu hajutamiseks, et te kohe vastust ei vaataks:

PVS-Studio hoiatamine: V708 [CWE-758] Ohtlik konstruktsioon on kasutusel: ‘FeaturesMap[Op] = FeaturesMap.size()’, kus ‘FeaturesMap’ on ‘map’ klass. See võib viia määramata käitumiseni. RISCVCompressInstEmitter.cpp 490

Problemaatiline rida:

FeaturesMap[Op] = FeaturesMap.size();

Kui element Op ei leitud, siis luuakse kaardis uus element ja sinna salvestatakse elementide arv. Ainult et ei ole teada, kas funktsiooni size kutsutakse välja enne või pärast uue elemendi lisamist.

Fragment N22-N24: Korduvalt määramised

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 hoiatamine: V519 [CWE-563] Muutuja ‘NType’ omistatakse järjestikku kaks korda väärtused. See võib olla eksitus. Kontrolli ridu: 1663, 1664. MachOObjectFile.cpp 1664

Arvan, et siin pole tegelikult viga. Lihtsalt üleliigne korduv omistamine. Aga ikka vale.

Sama:

• V519 [CWE-563] Muutuja ‘B.NDesc’ omistatakse järjestikku kaks korda väärtused. See võib olla eksitus. Kontrolli ridu: 1488, 1489. llvm-nm.cpp 1489
• V519 [CWE-563] Muutuja omistatakse järjestikku kaks korda väärtused. See võib olla eksitus. Kontrolli ridu: 59, 61. coff2yaml.cpp 61

Fragment N25-N27: Veel korduvad omistamised

Nüüd vaatame natuke teistsugust korduva omistamise varianti.

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

PVS-Studio hoiatus: V519 [CWE-563] Muutuja ‘Alignment’ omistatakse järjestikku kaks korda väärtused. See võib olla eksitus. Kontrolli ridu: 1158, 1160. LoadStoreVectorizer.cpp 1160

See on väga kummaline kood, mis ilmselt sisaldab loogilist viga. Alguses omistatakse muutuja Alignment väärtus sõltuvalt tingimusest. Siis toimub taas omistamine, kuid nüüd juba ilma igasuguse kontrollita.

Sarnaseid olukordi võib näha siin:

• V519 [CWE-563] Muutuja 'Effects' on järjestikku määratud kahesuguseid väärtusi. Võib-olla on see viga. Kontrollige ridu: 152, 165. WebAssemblyRegStackify.cpp 165
• V519 [CWE-563] Muutuja 'ExpectNoDerefChunk' on järjestikku määratud kahesuguseid väärtusi. Võib-olla on see viga. Kontrollige ridu: 4970, 4973. SemaType.cpp 4973

Fragment N28: Alati tõene tingimus

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 juhendi tugi             // <=
      break;
  }
  ....
}

PVS-Studio hoiatamine: V547 [CWE-571] Avalduss 'nextByte != 0x90' on alati tõene. X86DisassemblerDecoder.cpp 379

Kontroll ei oma mõtet. Muutuja nextByte on alati erinev väärtusest 0x90, mis tuleneb eelmisest kontrollist. See on mingi loogiline viga.

Fragment N29 — N…: Alati tõesed/vale tingimused

Analüsaator väljastab palju hoiatusi seoses sellega, et kogu tingimus (V547) või selle osa (V560) on alati tõene või vale. Tihti ei ole need tegelikud vead, vaid lihtsalt hoolimatu kood, makrode rakendamise tulemused jne. Siiski on mõistlik vaadata kõiki neid hoiatustega, kuna aeg-ajalt tulenevad tõelised loogilised vead. Näiteks on kahtlane see koodilõik:

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 hoiatamine: V560 [CWE-570] Üks tingimuslause osa on alati vale: RegNo == 0xe. ARMDisassembler.cpp 939

Konstant 0xE on väärtus 14 kümnendsüsteemis. Kontroll RegNo == 0xe pole mõttekas, kuna kui RegNo > 13, siis lõpetab funktsioon oma töötamise.

Oli palju teisi hoiatusi ID-ga V547 ja V560, kuid nagu oli juba selge V595, ei olnud mul nende hoiatuste uurimise vastu huvi. Niigi oli selge, et mul on piisavalt materjali artikli kirjutamiseks :). Seepärast ei ole teada, kui palju selliseid vigu võiks LLVM-is PVS-Studio abil tuvastada.

Toon näide, miks nende hoiatuste õppimine on igav. Analüsaator on täiesti õige, andes hoiatuse järgmise koodi kohta. Kuid see ei ole viga.

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

PVS-Studio hoiatamine: V547 [CWE-570] Väljend ‘!HasError’ on alati vale. UnwrappedLineParser.cpp 1635

Fragment N30: Kahtlane return

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 hoiatamine: V612 [CWE-670] Tingimusteta ‘return’ tsükli sees. R600OptimizeVectorRegisters.cpp 63

See on kas viga või spetsiifiline tehnika, mille eesmärk on midagi selgitada programmeerijatele, kes koodi loevad. Selline konstruktsioon ei selgita mulle midagi ja näeb väga kahtlane välja. Paremini ei tasu nii kirjutada :).

Väsinud? Siis on aeg teed või kohvi keeta.

Defektid, mille uued diagnostikad on tuvastanud

Arvan, et 30 vana diagnostika hoiatust on piisavalt. Vaadakem nüüd, mida huvitavat me uute diagnostikatega, mis analüsaatorisse ilmnesid, leida saame. eelnevas kontrollide. Selle aja jooksul on C++ analüsaatorisse lisandunud 66 üldist diagnostikat.

Fragment N31: Jõudmata kood

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 hoiatamine: V779 [CWE-561] Jõudmata kood tuvastatud. Võimalik, et viga on olemas. ExecutionUtils.cpp 146

Nagu näete, lõpetavad mõlemad harud operaatorit if operaatori kutsumisega return. Seega konteiner CtorDtorsByPriority ei tule kunagi tühjendamiseks.

Fragment N32: Jõudmata kood

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;
}

Hoiatus PVS-Studio: V779 [CWE-561] Jõudmata kood tuvastatud. Võimalik, et viga on olemas. LLParser.cpp 835

Huvitav olukord. Vaatame esmalt seda kohta:

return ParseTypeIdEntry(SummaryID);
break;

Esmapilgul tundub, et siin pole viga. Tundub, et operaator break siin on üleliigne osa, ja selle võib lihtsalt eemaldada. Kuid mitte kõik on nii lihtne.

Analüsaator annab hoiatuse ridade kohta:

Lex.setIgnoreColonInIdentifiers(false);
return false;

Ja tõepoolest, see kood on saavutatav. Kõik juhtumid switch lõpevad käsu kutsumisega return. Ja nüüd ei tundu üksildane break nii süütu! Äkki peaks üks haru lõppema break, mitte return?

Fragment N33: Juhuslik kõrgemate bitide nullimine

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

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

PVS-Studio hoiatamine: V784 Bitmaski suurus on väiksem kui esimese operandi suurus. See põhjustab kõrgemate bitide kadumise. RuntimeDyld.cpp 815

Pange tähele, et funktsioon getStubAlignment tagastab tüübi unsigned. Arvutame väljendi väärtuse, eeldades, et funktsioon tagastab väärtuse 8:

~(getStubAlignment() - 1)

~(8u-1)

0xFFFFFFF8‬u

Nüüd pange tähele, et muutuja DataSize omab 64-bit unsigned tüüp. See tähendab, et DataSize & 0xFFFFFFF8‬u teostamisel nullitakse kõik kolmkümmend kaks ülemist bitti. Tõenäoliselt ei olnud see, mida programmeerija soovis. Kahtlustan, et ta tahtis arvutada: DataSize & 0xFFFFFFFFFFFFFFF8‬u.

Vea parandamiseks tuleks kirjutada nii:

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

Või nii:

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

Fragment N34: Ebaõnnestunud tüüpide konverteerimine

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

PVS-Studio hoiatamine: V1028 [CWE-190] Võimalik ülejäägitus. Kaaluge operandide 'NumElts * Scale' operaatori kastmist 'size_t' tüübiks, mitte tulemust. X86ISelLowering.h 1577

Tüüpide konverteerimist kasutatakse, et vältida ülejäägitust muutuja tüüpide korrutamisel. int. Kuid siin ei kaitse tüüpide konverteerimine ülejäägi eest. Alguses korrutatakse muutujad ja alles seejärel laiendatakse 32-bitine korrutamise tulemus. size_t.

Fragment N35: Ebaõnnestunud Copy-Paste

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;
  }
  ....
}

V778 [CWE-682] Leiti sarnased koodi fragmentid. Võib-olla on see trükkimisviga ja 'Op1' muutuja peaks olema kasutatud 'Op0' asemel. InstCombineCompares.cpp 5507

See uus huvitav diagnoos tuvastab olukordi, kus koodifragmendi on kopeeritud ja nimesid on hakanud muutma, aga ühes kohas ei ole neid parandatud.

Pange tähele, et teises plokis muudeti Op0 järgnevaga Op1. Aga ühes kohas ei ole neid parandatud. Tõenäoliselt oleks pidanud kirjutama nii:

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

Fragment N36: Muutujate segadus

struct Status {
  unsigned Mask;
  unsigned Mode;

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

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

PVS-Studio hoiatamine: V1001 [CWE-563] Muutujale 'Mode' antakse väärtus, kuid seda ei kasutata funktsiooni lõpuks. SIModeRegister.cpp 48

On väga ohtlik anda funktsioonide argumentidele samu nimesid kui klassi liikmetele. On väga lihtne segadusse sattuda. See on just selline juhtum. See väljend ei oma tähendust:

Mode &= Mask;

Funktsiooni argument muutub. Ja kõik. Seda argumenti ei kasutata enam. Tõenäoliselt pidi olema nii:

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

Fragment N37: Muutuja segadus

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(Sym));
  Size += this->EntrySize;
}

PVS-Studio hoiatus: V1001 [CWE-563] Muutujale 'Size' antakse väärtus, kuid funktsiooni lõpuks ei kasutata seda. Object.cpp 424

Situatsioon on analoogne eelnevale. Peaks olema kirjutatud:

this->Size += this->EntrySize;

Fragment N38-N47: Näidik unustati kontrollida

Varem oleme vaadanud diagnostika aktiveerumise näiteid V595. Selle olemus on see, et näidik dereferenseeritakse alguses ja alles siis kontrollitakse. Uhiuus diagnostika V1004 on vastupidine, kuid samal ajal avastab väga palju vigu. See paljastab olukordi, kus indikaatorit alguses kontrolliti, kuid siis unustati seda teha. Vaadakem selliseid juhtumeid, mis leiti LLVM'is.

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

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

PVS-Studio hoiatus: V1004 [CWE-476] Pointer 'Ptr' kasutati pärast null'i vastu kontrollimist ebaohutult. Kontrollige ridu: 729, 738. TargetTransformInfoImpl.h 738

Muutuja Ptr võib olla võrdne nullptr, mida näitab kontroll:

if (Ptr != nullptr)

Kuid allpool dereferenseeritakse seda pointerit juba eelneva kontrollita:

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

Vaatame teist sarnast juhtumit.

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

PVS-Studio hoiatamine: V1004 [CWE-476] 'FD' pointerit kasutati ebaohutult pärast null-pointeriga kontrollimist. Kontrollige ridu: 3228, 3231. CGDebugInfo.cpp 3231

Pange tähele pointerit FD. Olen kindel, et probleem on selgelt nähtav ja ei vaja erilisi selgitusi.

Ja veel:

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

PVS-Studio hoiatamine: V1004 [CWE-476] 'PtrTy' pointerit kasutati ebaohutult pärast null-pointeriga kontrollimist. Kontrollige ridu: 960, 965. InterleavedLoadCombinePass.cpp 965

Kuidas end selliste vigade eest kaitsta? Olge tähelepanelikumad koodi ülevaatusel ja kasutage regulaarseks koodikontrolliks staatilist analizatorit PVS-Studio.

Muude samasuguste vigadega koodifragmentide toomine pole mõtet. Jätan artiklisse ainult hoiatuste nimekirja:

• V1004 [CWE-476] 'Expr' pointerit kasutati ebaohutult pärast null-pointeriga kontrollimist. Kontrollige ridu: 1049, 1078. DebugInfoMetadata.cpp 1078
• V1004 [CWE-476] 'PI' pointerit kasutati ebaohutult pärast null-pointeriga kontrollimist. Kontrollige ridu: 733, 753. LegacyPassManager.cpp 753
• V1004 [CWE-476] 'StatepointCall' pointerit kasutati ebaohutult pärast null-pointeriga kontrollimist. Kontrollige ridu: 4371, 4379. Verifier.cpp 4379
• V1004 [CWE-476] ‘RV’ pointerit kasutati ebaohutult pärast nullpointeriga kontrollimist. Kontrollige ridu: 2263, 2268. TGParser.cpp 2268
• V1004 [CWE-476] ‘CalleeFn’ pointerit kasutati ebaohutult pärast nullpointeriga kontrollimist. Kontrollige ridu: 1081, 1096. SimplifyLibCalls.cpp 1096
• V1004 [CWE-476] ‘TC’ pointerit kasutati ebaohutult pärast nullpointeriga kontrollimist. Kontrollige ridu: 1819, 1824. Driver.cpp 1824

Fragment N48-N60: Mitte kriitiline, aga defekt (võimalik mäluleke)

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

PVS-Studio hoiatamine: V1023 [CWE-460] Pointer, millel pole omanikku, lisatakse ‘Strategies’ konteinerisse ’emplace_back’ meetodi kaudu. Mäluleke toimub juhul, kui tekib erand. llvm-isel-fuzzer.cpp 58

Elemendi lisamiseks konteineri lõppu, tüüpi std::vector<std::unique_ptr> ei saa lihtsalt kirjutada xxx.push_back(new X), kuna ei toimu varjatud teisendamist X* ühes std::unique_ptr.

Levinud lahendus on kirjutada xxx.emplace_back(new X), kuna see kompileerub: meetod emplace_back ehitab elemendi otse argumentidest ja seega võib kasutada selgeid konstruktorit.

See ei ole ohutu. Kui vektor on täis, toimub mälu ümberjaotamine. Mälu ümberjaotamise operatsioon võib ebaõnnestuda, mille tagajärjel genereeritakse erand std::bad_alloc. Sel juhul kaob näidik ja loodud objekti ei saa kunagi kustutada.

Ohutu lahendus on loomine unique_ptr, mis omab näidikut kuni vektori katse mäluruumi uuesti eraldada:

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

Alates C++14-st saab kasutada ‘std::make_unique’:

xxx.push_back(std::make_unique())

Seda tüüpi viga ei ole LLVM jaoks kriitiline. Kui mäluruumi eraldamine ebaõnnestub, peatub kompilaatori töö lihtsalt. Kuid rakenduste jaoks, mille käivitusaeg on pikk, mis ei saa lihtsalt lõpetada, kui mäluruumi eraldamine ebaõnnestub, võib see olla tõeline ebamugavus.

Seega, kuigi see kood ei kujuta endas praktilist ohtu LLVM-ile, leidis ma kasulik rääkida sellest veapatrist ja sellest, kuidas PVS-Studio analüsaator on õppinud seda tuvastama.

Muud selle tüüpi hoiatustega:

• V1023 [CWE-460] Näidik, kellel pole omanikku, lisatakse 'Passes' konteinerisse ’emplace_back’ meetodiga. Erakordsuse korral tekib mäluleke. PassManager.h 546
• V1023 [CWE-460] Näidik, kellel pole omanikku, lisatakse 'AAs' konteinerisse ’emplace_back’ meetodiga. Erakordsuse korral tekib mäluleke. AliasAnalysis.h 324
• V1023 [CWE-460] Omanikuta omanikuta lisatakse 'Entries' konteinerisse 'emplace_back' meetodiga. Erandi korral toimub mäluleke. DWARFDebugFrame.cpp 519
• V1023 [CWE-460] Omanikuta omanik lisatakse 'AllEdges' konteinerisse 'emplace_back' meetodiga. Erandi korral toimub mäluleke. CFGMST.h 268
• V1023 [CWE-460] Omanikuta omanik lisatakse 'VMaps' konteinerisse 'emplace_back' meetodiga. Erandi korral toimub mäluleke. SimpleLoopUnswitch.cpp 2012
• V1023 [CWE-460] Omanikuta omanik lisatakse 'Records' konteinerisse 'emplace_back' meetodiga. Erandi korral toimub mäluleke. FDRLogBuilder.h 30
• V1023 [CWE-460] Omanikuta omanik lisatakse 'PendingSubmodules' konteinerisse 'emplace_back' meetodiga. Erandi korral toimub mäluleke. ModuleMap.cpp 810
• V1023 [CWE-460] Omanikuta omanik lisatakse 'Objects' konteinerisse 'emplace_back' meetodiga. Erandi korral toimub mäluleke. DebugMap.cpp 88
• V1023 [CWE-460] Omanikuta omanik lisatakse 'Strategies' konteinerisse 'emplace_back' meetodiga. Erandi korral toimub mäluleke. llvm-isel-fuzzer.cpp 60
• V1023 [CWE-460] Omanikuta omanik lisatakse 'Modifiers' konteinerisse 'emplace_back' meetodiga. Erandi korral toimub mäluleke. llvm-stress.cpp 685
• V1023 [CWE-460] Omanikuta omanik lisatakse 'Modifiers' konteinerisse 'emplace_back' meetodiga. Erandi korral toimub mäluleke. llvm-stress.cpp 686
• V1023 [CWE-460] Omanikuta omanik lisatakse 'Modifiers' konteinerisse 'emplace_back' meetodiga. Erandi korral toimub mäluleke. llvm-stress.cpp 688
• V1023 [CWE-460] Omanik, kellel ei ole omanikku, lisatakse „Modifikaatorite“ konteinerisse meetodi „emplace_back“ abil. Erandi korral tekib mälu lekkimine. llvm-stress.cpp 689
• V1023 [CWE-460] Omanikuta pointern lisatakse „Modifikaatorite“ konteinerisse meetodi „emplace_back“ abil. Erandi korral tekib mälu lekkimine. llvm-stress.cpp 690
• V1023 [CWE-460] Omanikuta pointer lisatakse „Modifikaatorite“ konteinerisse meetodi „emplace_back“ abil. Erandi korral tekib mälu lekkimine. llvm-stress.cpp 691
• V1023 [CWE-460] Omanikuta pointer lisatakse „Modifikaatorite“ konteinerisse meetodi „emplace_back“ abil. Erandi korral tekib mälu lekkimine. llvm-stress.cpp 692
• V1023 [CWE-460] Omanikuta pointer lisatakse „Modifikaatorite“ konteinerisse meetodi „emplace_back“ abil. Erandi korral tekib mälu lekkimine. llvm-stress.cpp 693
• V1023 [CWE-460] Omanikuta pointer lisatakse „Modifikaatorite“ konteinerisse meetodi „emplace_back“ abil. Erandi korral tekib mälu lekkimine. llvm-stress.cpp 694
• V1023 [CWE-460] Omanikuta pointer lisatakse „Operandide“ konteinerisse meetodi „emplace_back“ abil. Erandi korral tekib mälu lekkimine. GlobalISelEmitter.cpp 1911
• V1023 [CWE-460] Omanikuta pointer lisatakse „Stashi“ konteinerisse meetodi „emplace_back“ abil. Erandi korral tekib mälu lekkimine. GlobalISelEmitter.cpp 2100
• V1023 [CWE-460] Omanikuta pointer lisatakse „Matcherite“ konteinerisse meetodi „emplace_back“ abil. Erandi korral tekib mälu lekkimine. GlobalISelEmitter.cpp 2702

Kokkuvõte

Kokku olen koostanud 60 hoiatust, mille järel peatusin. Kas PVS-Studio analüsaator tuvastab veel muid Defekte LLVM-s? Jah, tuvastab. Kuid kui ma koostasin artikli jaoks koodilõike, oli juba hiline õhtu, pigem isegi öö, ja otsustasin, et on aeg lõpetada.

Loodan, et teile oli huvitav ja soovite proovida PVS-Studio analüsaatorit.

Saate analüsaatori alla laadida ja saada proovivõtmiseks võtme sellel lehel.

Kõige tähtsam, kasutage staatilist analüüsi regulaarselt. Ühekordsed kontrollid, mida me teeme staatilise analüüsi ja PVS-Studio metodoloogia populariseerimise eesmärgil, ei ole normaalne stsenaarium.

Edu koodi kvaliteedi ja usaldusväärsuse parandamisel!

Kui soovite seda artiklit jagada ingliskeelse auditooriumiga, siis palun kasutage tõlke linki: Andrey Karpov. Finding Bugs in LLVM 8 with PVS-Studio.

Allikas: habr.com