შეცდომების პოვნა LLVM 8-ში PVS-Studio ანალიზატორის გამოყენებით

ორ წელზე მეტი გავიდა LLVM პროექტის ბოლო კოდის შემოწმებიდან ჩვენი PVS-Studio ანალიზატორის გამოყენებით. მოდით დავრწმუნდეთ, რომ PVS-Studio ანალიზატორი კვლავ არის შეცდომების და პოტენციური დაუცველობის იდენტიფიცირების წამყვანი ინსტრუმენტი. ამისათვის ჩვენ შევამოწმებთ და ვიპოვით ახალ შეცდომებს LLVM 8.0.0 გამოშვებაში.

დასაწერი სტატია

მართალი გითხრათ, არ მინდოდა ამ სტატიის დაწერა. არ არის საინტერესო პროექტზე წერა, რომელიც უკვე რამდენჯერმე გადავამოწმეთ (1, 2, 3). ჯობია ახალზე დავწერო, მაგრამ არჩევანი არ მაქვს.

ყოველ ჯერზე, როდესაც LLVM-ის ახალი ვერსია გამოდის ან განახლდება Clang სტატიკური ანალიზატორი, ჩვენ ვიღებთ შემდეგი ტიპის კითხვებს ჩვენს ფოსტაზე:

ნახეთ, Clang Static Analyzer-ის ახალმა ვერსიამ ისწავლა ახალი შეცდომების პოვნა! მეჩვენება, რომ PVS-Studio-ს გამოყენების აქტუალობა მცირდება. Clang აღმოაჩენს უფრო მეტ შეცდომას, ვიდრე ადრე და ემთხვევა PVS-Studio-ს შესაძლებლობებს. Რას ფიქრობ ამის შესახებ?

ამაზე ყოველთვის მინდა ვუპასუხო:

არც ჩვენ ვიჯდებით უსაქმოდ! ჩვენ მნიშვნელოვნად გავაუმჯობესეთ PVS-Studio ანალიზატორის შესაძლებლობები. ასე რომ არ ინერვიულოთ, ჩვენ ვაგრძელებთ ლიდერობას, როგორც ადრე.

სამწუხაროდ, ეს ცუდი პასუხია. მასში არანაირი მტკიცებულება არ არის. და სწორედ ამიტომ ვწერ ამ სტატიას ახლა. ასე რომ, LLVM პროექტი კიდევ ერთხელ შემოწმდა და მასში მრავალი შეცდომა იქნა ნაპოვნი. ახლა მე ვაჩვენებ მათ, რაც ჩემთვის საინტერესო ჩანდა. Clang Static Analyzer ვერ პოულობს ამ შეცდომებს (ან ძალიან მოუხერხებელია ამის გაკეთება მისი დახმარებით). მაგრამ ჩვენ შეგვიძლია. მეტიც, ყველა ეს შეცდომა ერთ საღამოს ვიპოვე და ჩავწერე.

მაგრამ სტატიის დაწერას რამდენიმე კვირა დასჭირდა. უბრალოდ, თავს ვერ ვიტანდი, რომ ეს ყველაფერი ტექსტში გადამეტანა :).

სხვათა შორის, თუ გაინტერესებთ რა ტექნოლოგიები გამოიყენება PVS-Studio ანალიზატორში შეცდომების და პოტენციური დაუცველობის დასადგენად, მაშინ გირჩევთ გაეცნოთ ამას შენიშვნა.

ახალი და ძველი დიაგნოსტიკა

როგორც უკვე აღვნიშნეთ, დაახლოებით ორი წლის წინ LLVM პროექტი კიდევ ერთხელ შემოწმდა და აღმოჩენილი შეცდომები გამოსწორდა. ახლა ეს სტატია წარმოგიდგენთ შეცდომების ახალ ჯგუფს. რატომ აღმოაჩინეს ახალი შეცდომები? ამის 3 მიზეზი არსებობს:

1. LLVM პროექტი ვითარდება, ცვლის ძველ კოდს და ამატებს ახალ კოდს. ბუნებრივია, არის ახალი შეცდომები შეცვლილ და დაწერილ კოდში. ეს ნათლად აჩვენებს, რომ სტატიკური ანალიზი რეგულარულად უნდა იქნას გამოყენებული და არა ხანდახან. ჩვენი სტატიები კარგად აჩვენებს PVS-Studio ანალიზატორის შესაძლებლობებს, მაგრამ ამას არაფერი აქვს საერთო კოდის ხარისხის გაუმჯობესებასთან და შეცდომების გამოსწორების ღირებულების შემცირებასთან. რეგულარულად გამოიყენეთ სტატიკური კოდის ანალიზატორი!
2. ჩვენ ვასრულებთ და ვაუმჯობესებთ არსებულ დიაგნოზს. ამრიგად, ანალიზატორს შეუძლია დაადგინოს შეცდომები, რომლებიც მან ვერ შეამჩნია წინა სკანირების დროს.
3. PVS-Studio-ში გამოჩნდა ახალი დიაგნოსტიკა, რომელიც არ არსებობდა 2 წლის წინ. მე გადავწყვიტე გამოვყო ისინი ცალკეულ განყოფილებაში, რათა ნათლად მეჩვენებინა PVS-Studio-ს განვითარება.

დეფექტები გამოვლენილი დიაგნოსტიკით, რომელიც არსებობდა 2 წლის წინ

ფრაგმენტი N1: Copy-Paste

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 გაფრთხილება: V501 [CWE-570] არის იდენტური ქვეგამოთქმები "Name.startswith("avx512.mask.permvar.")" "||"-ის მარცხნივ და მარჯვნივ. ოპერატორი. AutoUpgrade.cpp 73

ორჯერ შემოწმდება, რომ სახელი იწყება ქვესტრიქონით "avx512.mask.permvar.". მეორე შემოწმებაზე აშკარად სხვა რამის დაწერა უნდოდათ, მაგრამ გადაწერილი ტექსტის გასწორება დაავიწყდათ.

ფრაგმენტი 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

ბეჭდვითი შეცდომის გამო, იგივე სახელწოდების მუდმივი გამოიყენება ორჯერ 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 გაფრთხილება: V502 [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: ნულოვანი მაჩვენებელი

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 გაფრთხილება: V522 [CWE-476] შეიძლება მოხდეს ნული მაჩვენებლის 'LHS'-ის გაუქმება. TGParser.cpp 2152

თუ მაჩვენებელი LHS ნულოვანია, გაფრთხილება უნდა გაიცეს. თუმცა, ამის ნაცვლად, იგივე ნულოვანი მაჩვენებელი გაუქმდება: 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));

სინამდვილეში, ახლა პროგკლონი არის ნულოვანი მაჩვენებელი. ამიტომ, ნულოვანი მაჩვენებლის გაუქმება უნდა მოხდეს მხოლოდ ქვემოთ:

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 მაჩვენებლის "ტესტი" გაუქმება. არასწორი შედგენა.cpp 709

ისევ იგივე სიტუაცია. თავდაპირველად, ობიექტის შინაარსი გადაადგილდება, შემდეგ კი გამოიყენება ისე, თითქოს არაფერი მომხდარა. მე უფრო და უფრო ხშირად ვხედავ ამ სიტუაციას პროგრამის კოდში მას შემდეგ, რაც მოძრაობის სემანტიკა გამოჩნდა C++-ში. ამიტომ მიყვარს C++ ენა! სულ უფრო და უფრო მეტი ახალი გზა არსებობს საკუთარი ფეხის მოსაშორებლად. PVS-Studio ანალიზატორი ყოველთვის იმუშავებს :).

ფრაგმენტი N8: ნულოვანი მაჩვენებელი

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 მაჩვენებლის 'ტიპის' გაუქმება. PrettyFunctionDumper.cpp 233

შეცდომების დამმუშავებლების გარდა, ამობეჭდვის გამართვის ფუნქციები, როგორც წესი, არ ტესტირება. ჩვენთან სწორედ ასეთი შემთხვევაა. ფუნქცია ელოდება მომხმარებელს, რომელიც იმის ნაცვლად, რომ მოაგვაროს თავისი პრობლემები, იძულებული იქნება მისი გამოსწორება.

სწორად:

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

ფრაგმენტი N9: ნულოვანი მაჩვენებელი

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'-ის გაუქმება. SearchableTableEmitter.cpp 614

ვფიქრობ, ყველაფერი ნათელია და არ საჭიროებს ახსნას.

ფრაგმენტი 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 გაფრთხილება: V570 ცვლადი 'Identifier->Type' ენიჭება თავის თავს. FormatTokenLexer.cpp 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 გაფრთხილება: V622 [CWE-478] განიხილეთ "გადამრთველი" განაცხადის შემოწმება. შესაძლებელია, რომ პირველი „საქმის“ ოპერატორი აკლია. 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 გაფრთხილება: V595 [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] 'ND' მაჩვენებელი გამოიყენებოდა მანამ, სანამ ის გადამოწმებული იქნებოდა nullptr-თან მიმართებაში. შეამოწმეთ ხაზები: 532, 534. SemaTemplateInstantiateDecl.cpp 532

Და აქ:

• V595 [CWE-476] 'U' მაჩვენებელი გამოიყენებოდა მანამ, სანამ იგი გადამოწმებული იქნებოდა nullptr-ის წინააღმდეგ. შეამოწმეთ ხაზები: 404, 407. DWARFormValue.cpp 404
• V595 [CWE-476] 'ND' მაჩვენებელი გამოიყენებოდა მანამ, სანამ იგი გადამოწმებული იქნებოდა nullptr-თან მიმართებაში. შეამოწმეთ ხაზები: 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 გაფრთხილება: V629 [CWE-190] განიხილეთ '~(ზომა - 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 გაფრთხილება: V646 [CWE-670] განიხილეთ აპლიკაციის ლოგიკის შემოწმება. შესაძლებელია, რომ „სხვა“ საკვანძო სიტყვა აკლია. AMDGPUAsmParser.cpp 5655

აქ შეცდომა არ არის. პირველის მაშინდელი ბლოკიდან მოყოლებული if მთავრდება გაგრძელდება, მაშინ არ აქვს მნიშვნელობა, არის საკვანძო სიტყვა სხვა თუ არა. ნებისმიერ შემთხვევაში, კოდი ერთნაირად იმუშავებს. მაინც გაუშვა სხვა ხდის კოდს უფრო გაურკვეველს და საშიშს. თუ მომავალში გაგრძელდება ქრება, კოდი დაიწყებს მუშაობას სრულიად განსხვავებულად. ჩემი აზრით ჯობია დავამატო სხვა.

ფრაგმენტი N20: იგივე ტიპის ოთხი შეცდომა

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] სტრიქონები იყო დაკავშირებული, მაგრამ არ გამოიყენება. იფიქრეთ "შედეგი + "(ObjC Class)" + Name.str()" გამოხატვის შემოწმებაზე. სიმბოლო.cpp 35
• V655 [CWE-480] სტრიქონები იყო დაკავშირებული, მაგრამ არ გამოიყენება. იფიქრეთ "შედეგი + "(ObjC Class EH) " + Name.str()" გამოხატვის შემოწმება. სიმბოლო.cpp 38
• V655 [CWE-480] სტრიქონები იყო დაკავშირებული, მაგრამ არ გამოიყენება. იფიქრეთ "შედეგი + "(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 გაფრთხილება: V708 [CWE-758] გამოიყენება საშიში კონსტრუქცია: 'FeaturesMap[Op] = FeaturesMap.size()', სადაც 'FeaturesMap' არის 'map' კლასის. ამან შეიძლება გამოიწვიოს გაურკვეველი ქცევა. RISCVCompressInstEmitter.cpp 490

პრობლემის ხაზი:

FeaturesMap[Op] = FeaturesMap.size();

თუ ელემენტი 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 გაფრთხილება: V519 [CWE-563] 'NType' ცვლადს ენიჭება მნიშვნელობები ზედიზედ ორჯერ. ალბათ ეს შეცდომაა. შეამოწმეთ ხაზები: 1663, 1664. MachOObjectFile.cpp 1664

არა მგონია, აქ რეალური შეცდომა იყოს. უბრალოდ არასაჭირო განმეორებითი დავალება. მაგრამ მაინც შეცდომაა.

ანალოგიურად:

• V519 [CWE-563] 'B.NDesc' ცვლადს ენიჭება მნიშვნელობები ზედიზედ ორჯერ. ალბათ ეს შეცდომაა. შეამოწმეთ ხაზები: 1488, 1489. llvm-nm.cpp 1489
• V519 [CWE-563] ცვლადს ენიჭება მნიშვნელობები ზედიზედ ორჯერ. ალბათ ეს შეცდომაა. შეამოწმეთ ხაზები: 59, 61. coff2yaml.cpp 61

ფრაგმენტი 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. LoadStoreVetorizer.cpp 1160

ეს არის ძალიან უცნაური კოდი, რომელიც აშკარად შეიცავს ლოგიკურ შეცდომას. დასაწყისში, ცვლადი ვიზირების მნიშვნელობა ენიჭება მდგომარეობიდან გამომდინარე. და შემდეგ დავალება კვლავ ხდება, მაგრამ ახლა ყოველგვარი შემოწმების გარეშე.

მსგავსი სიტუაციები შეგიძლიათ ნახოთ აქ:

• V519 [CWE-563] "ეფექტები" ცვლადს ენიჭება მნიშვნელობები ზედიზედ ორჯერ. ალბათ ეს შეცდომაა. შეამოწმეთ ხაზები: 152, 165. WebAssemblyRegStackify.cpp 165
• V519 [CWE-563] 'ExpectNoDerefChunk' ცვლადს ენიჭება მნიშვნელობები ზედიზედ ორჯერ. ალბათ ეს შეცდომაა. შეამოწმეთ ხაზები: 4970, 4973. SemaType.cpp 4973

ფრაგმენტი N28: ყოველთვის ჭეშმარიტი მდგომარეობა

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 გაფრთხილება: V547 [CWE-571] გამოთქმა 'nextByte != 0x90' ყოველთვის მართალია. X86DisassemblerDecoder.cpp 379

შემოწმებას აზრი არ აქვს. ცვლადი შემდეგი ბაიტი ყოველთვის არ უდრის ღირებულებას 0x90, რომელიც გამომდინარეობს წინა შემოწმებიდან. ეს არის ერთგვარი ლოგიკური შეცდომა.

ფრაგმენტი N29 - N...: ყოველთვის მართალია/მცდარი პირობები

ანალიზატორი გასცემს ბევრ გაფრთხილებას, რომ მთელი მდგომარეობა (V547) ან მისი ნაწილი (V560) ყოველთვის მართალია ან მცდარი. ხშირად ეს არ არის რეალური შეცდომები, არამედ უბრალოდ დაუდევარი კოდი, მაკრო გაფართოების შედეგი და მსგავსი. თუმცა, აზრი აქვს ყველა ამ გაფრთხილებას, რადგან ჭეშმარიტი ლოგიკური შეცდომები დროდადრო ხდება. მაგალითად, კოდის ეს განყოფილება საეჭვოა:

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 გაფრთხილება: V560 [CWE-570] პირობითი გამოხატვის ნაწილი ყოველთვის მცდარია: RegNo == 0xe. ARMdisassembler.cpp 939

მუდმივი 0xE არის მნიშვნელობა 14 ათწილადში. ექსპერტიზა RegNo == 0xe აზრი არ აქვს, რადგან თუ RegNo > 13, შემდეგ ფუნქცია დაასრულებს მის შესრულებას.

იყო მრავალი სხვა გაფრთხილება ID V547 და V560, მაგრამ როგორც V595მე არ მაინტერესებდა ამ გაფრთხილებების შესწავლა. უკვე გასაგები იყო, რომ საკმარისი მასალა მქონდა სტატიის დასაწერად :). ამიტომ, უცნობია, ამ ტიპის რამდენი შეცდომის იდენტიფიცირება შეიძლება LLVM-ში PVS-Studio-ს გამოყენებით.

მე მოგცემთ მაგალითს, თუ რატომ არის ამ ტრიგერების შესწავლა მოსაწყენი. ანალიზატორი აბსოლუტურად მართალია გაფრთხილების გაცემისას შემდეგი კოდისთვის. მაგრამ ეს არ არის შეცდომა.

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

PVS-Studio გაფრთხილება: V547 [CWE-570] გამოთქმა '!HasError' ყოველთვის მცდარია. UnwrappedLineParser.cpp 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 გაფრთხილება: V612 [CWE-670] უპირობო "დაბრუნება" მარყუჟში. R600OptimizeVectorRegisters.cpp 63

ეს არის შეცდომა ან კონკრეტული ტექნიკა, რომელიც მიზნად ისახავს პროგრამისტებისთვის რაღაცის ახსნას, რომლებიც კითხულობენ კოდს. ეს დიზაინი არაფერს ამიხსნის და ძალიან საეჭვოდ გამოიყურება. ჯობია ასე არ დაწერო :).

დაიღალა? მაშინ ჩაის ან ყავის მომზადების დროა.

ახალი დიაგნოსტიკით გამოვლენილი დეფექტები

ძველი დიაგნოსტიკის 30 გააქტიურება მგონი საკმარისია. მოდით ახლა ვნახოთ, რა საინტერესო რამ შეიძლება მოიძებნოს ახალი დიაგნოსტიკით, რომელიც შემდეგ გამოჩნდა ანალიზატორში წინა ჩეკები. ამ დროის განმავლობაში C++ ანალიზატორს დაემატა სულ 66 ზოგადი დანიშნულების დიაგნოსტიკა.

ფრაგმენტი 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 გაფრთხილება: V779 [CWE-561] აღმოჩენილია მიუწვდომელი კოდი. შესაძლებელია, რომ შეცდომა იყოს. ExecutionUtils.cpp 146

როგორც ხედავთ, ოპერატორის ორივე ფილიალი if მთავრდება ოპერატორთან ზარით დაბრუნების. შესაბამისად, კონტეინერი 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;

და მართლაც, ეს კოდი მიუწვდომელია. ყველა საქმეში გადართოთ მთავრდება ოპერატორის ზარით დაბრუნების. ახლა კი უაზრო მარტო შესვენება არც ისე უვნებლად გამოიყურება! ალბათ ერთ-ერთი ფილიალი უნდა დასრულდეს შესვენებაარა დაბრუნების?

ფრაგმენტი 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 გაფრთხილება: V784 ბიტის ნიღბის ზომა პირველი ოპერანდის ზომაზე ნაკლებია. ეს გამოიწვევს უფრო მაღალი ბიტების დაკარგვას. RuntimeDyld.cpp 815

გთხოვთ გაითვალისწინოთ, რომ ფუნქცია getStubAlignment აბრუნებს ტიპს ხელმოწერილი. მოდით გამოვთვალოთ გამოხატვის მნიშვნელობა, ვივარაუდოთ, რომ ფუნქცია დააბრუნებს მნიშვნელობას 8:

~(getStubAlignment() - 1)

~ (8u-1)

0xFFFFFFFF8u

ახლა შეამჩნიეთ, რომ ცვლადი მონაცემთა ზომა აქვს 64 ბიტიანი ხელმოუწერელი ტიპი. გამოდის, რომ DataSize & 0xFFFFFFF8u ოპერაციების შესრულებისას ოცდათორმეტივე მაღალი რიგის ბიტი ნულამდე იქნება გადატვირთული. სავარაუდოდ, ეს არ არის ის, რაც პროგრამისტს სურდა. ეჭვი მაქვს, რომ მას სურდა გამოთვლა: DataSize & 0xFFFFFFFFFFFFFFFFFF8u.

შეცდომის გამოსასწორებლად, თქვენ უნდა დაწეროთ ეს:

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 გაფრთხილება: V1028 [CWE-190] შესაძლო გადინება. განვიხილოთ "NumElts * Scale" ოპერატორის ოპერანდების გადაცემა "size_t" ტიპისთვის და არა შედეგი. X86ISelLowering.h 1577

აშკარა ტიპის ჩამოსხმა გამოიყენება, რათა თავიდან იქნას აცილებული ტიპის ცვლადების გამრავლება int. თუმცა, აშკარა ტიპის ჩამოსხმა აქ არ იცავს გადინებისგან. ჯერ ცვლადები გამრავლდება და მხოლოდ ამის შემდეგ გამრავლების 32-ბიტიანი შედეგი გაფართოვდება ტიპზე size_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;
  }
  ....
}

V778 [CWE-682] ნაპოვნია ორი მსგავსი კოდის ფრაგმენტი. შესაძლოა, ეს შეცდომაა და 'Op1' ცვლადი უნდა იყოს გამოყენებული 'Op0'-ის ნაცვლად. InstCombineCompares.cpp 5507

ეს ახალი საინტერესო დიაგნოსტიკა განსაზღვრავს სიტუაციებს, როდესაც კოდის ნაწილი დაკოპირებულია და მასში არსებული ზოგიერთი სახელწოდება დაიწყო, მაგრამ ერთ ადგილას მათ არ გაუსწორებიათ.

გთხოვთ გაითვალისწინოთ, რომ მეორე ბლოკში ისინი შეიცვალა ოპ 0 on ოპ 1. მაგრამ ერთ ადგილას არ გაასწორეს. დიდი ალბათობით ასე უნდა ეწერა:

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

ფრაგმენტი N36: Variable Confusion

struct Status {
  unsigned Mask;
  unsigned Mode;

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

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

PVS-Studio გაფრთხილება: V1001 [CWE-563] „Mode“ ცვლადი მინიჭებულია, მაგრამ არ გამოიყენება ფუნქციის ბოლომდე. SIModeRegister.cpp 48

ძალზე საშიშია ფუნქციის არგუმენტების იგივე სახელების მინიჭება, როგორც კლასის წევრები. ძალიან ადვილია დაბნეულობა. ჩვენთან სწორედ ასეთი შემთხვევაა. ამ გამოთქმას აზრი არ აქვს:

Mode &= Mask;

ფუნქციის არგუმენტი იცვლება. Სულ ეს არის. ეს არგუმენტი აღარ გამოიყენება. დიდი ალბათობით ასე უნდა დაგეწერა:

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

ფრაგმენტი N37: Variable Confusion

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: დაავიწყდათ ინდექსის შემოწმება

ადრე ჩვენ განვიხილეთ დიაგნოსტიკური ტრიგერების მაგალითები V595. მისი არსი იმაში მდგომარეობს, რომ მაჩვენებლის თავიდან აცილება ხდება და მხოლოდ ამის შემდეგ შემოწმდება. ახალგაზრდა დიაგნოსტიკა V1004 არის საპირისპირო მნიშვნელობით, მაგრამ ასევე ავლენს უამრავ შეცდომას. ის განსაზღვრავს სიტუაციებს, როდესაც კურსორი თავიდან შემოწმდა და შემდეგ დაავიწყდა ამის გაკეთება. მოდით გადავხედოთ 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

ცვალებადი პტრ შეიძლება იყოს თანაბარი 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

როგორ დავიცვათ თავი ასეთი შეცდომებისგან? იყავით უფრო ყურადღებიანი Code-Review-ზე და გამოიყენეთ PVS-Studio სტატიკური ანალიზატორი თქვენი კოდის რეგულარულად შესამოწმებლად.

ამ ტიპის შეცდომებით სხვა კოდის ფრაგმენტების ციტირებას აზრი არ აქვს. სტატიაში დავტოვებ მხოლოდ გაფრთხილებების ჩამონათვალს:

• V1004 [CWE-476] 'Expr' მაჩვენებელი გამოყენებული იქნა არაუსაფრთხო, მას შემდეგ, რაც დადასტურდა nullptr-თან მიმართებაში. შეამოწმეთ ხაზები: 1049, 1078. DebugInfoMetadata.cpp 1078
• V1004 [CWE-476] 'PI' მაჩვენებელი გამოყენებული იქნა არაუსაფრთხო, მას შემდეგ, რაც დადასტურდა nullptr-თან მიმართებაში. შეამოწმეთ ხაზები: 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] 'TC' მაჩვენებელი გამოყენებული იქნა არაუსაფრთხო მას შემდეგ, რაც ის გადამოწმებული იქნა nullptr-თან მიმართებაში. შეამოწმეთ ხაზები: 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 გაფრთხილება: V1023 [CWE-460] მითითება მფლობელის გარეშე ემატება „სტრატეგიების“ კონტეინერს „emplace_back“ მეთოდით. გამონაკლისის შემთხვევაში მოხდება მეხსიერების გაჟონვა. llvm-isel-fuzzer.cpp 58

ელემენტის დასამატებლად კონტეინერის ბოლოს, როგორიცაა std:: ვექტორი > უბრალოდ წერა არ შეგიძლია xxx.push_back (ახალი X), ვინაიდან არ არსებობს ნაგულისხმევი კონვერტაცია X* в std::unique_ptr.

საერთო გამოსავალი არის წერა xxx.emplace_back(ახალი X)ვინაიდან იგი ადგენს: მეთოდს emplace_back აგებს ელემენტს უშუალოდ მისი არგუმენტებიდან და, შესაბამისად, შეუძლია გამოიყენოს ექსპლიციტური კონსტრუქტორები.

ეს არ არის უსაფრთხო. თუ ვექტორი სავსეა, მაშინ მეხსიერება ხელახლა გამოიყოფა. მეხსიერების გადანაწილების ოპერაცია შეიძლება წარუმატებელი იყოს, რის შედეგადაც გამონაკლისი ხდება std::bad_alloc. ამ შემთხვევაში, მაჩვენებელი დაიკარგება და შექმნილი ობიექტი არასოდეს წაიშლება.

უსაფრთხო გამოსავალი არის შექმნა უნიკალური_პტრრომელიც ფლობს მაჩვენებელს, სანამ ვექტორი შეეცდება მეხსიერების გადანაწილებას:

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] კურსორი მფლობელის გარეშე ემატება 'Passes' კონტეინერს 'emplace_back' მეთოდით. გამონაკლისის შემთხვევაში მოხდება მეხსიერების გაჟონვა. PassManager.h 546
• V1023 [CWE-460] მაჩვენებელი მფლობელის გარეშე ემატება 'AAs' კონტეინერს 'emplace_back' მეთოდით. გამონაკლისის შემთხვევაში მოხდება მეხსიერების გაჟონვა. AliasAnalysis.h 324
• V1023 [CWE-460] „Entries“ კონტეინერს „emplace_back“ მეთოდით ემატება მაჩვენებლის მფლობელის გარეშე. გამონაკლისის შემთხვევაში მოხდება მეხსიერების გაჟონვა. DWARFDebugFrame.cpp 519
• V1023 [CWE-460] კურსორი მფლობელის გარეშე ემატება 'AllEdges' კონტეინერს 'emplace_back' მეთოდით. გამონაკლისის შემთხვევაში მოხდება მეხსიერების გაჟონვა. CFGMST.h 268
• V1023 [CWE-460] „VMaps“ კონტეინერს „emplace_back“ მეთოდით ემატება მაჩვენებელი მფლობელის გარეშე. გამონაკლისის შემთხვევაში მოხდება მეხსიერების გაჟონვა. SimpleLoopUnswitch.cpp 2012 წ
• V1023 [CWE-460] კურსორი მფლობელის გარეშე ემატება 'Records' კონტეინერს 'emplace_back' მეთოდით. გამონაკლისის შემთხვევაში მოხდება მეხსიერების გაჟონვა. FDRLogBuilder.h 30
• V1023 [CWE-460] მაჩვენებლის მფლობელის გარეშე ემატება 'PendingSubmodules' კონტეინერს 'emplace_back' მეთოდით. გამონაკლისის შემთხვევაში მოხდება მეხსიერების გაჟონვა. ModuleMap.cpp 810
• V1023 [CWE-460] მაჩვენებლის მფლობელის გარეშე ემატება 'Objects' კონტეინერს 'emplace_back' მეთოდით. გამონაკლისის შემთხვევაში მოხდება მეხსიერების გაჟონვა. DebugMap.cpp 88
• V1023 [CWE-460] „სტრატეგიების“ კონტეინერს ემატება მაჩვენებლის მფლობელის გარეშე „emplace_back“ მეთოდით. გამონაკლისის შემთხვევაში მოხდება მეხსიერების გაჟონვა. llvm-isel-fuzzer.cpp 60
• V1023 [CWE-460] მაჩვენებელი მფლობელის გარეშე ემატება 'Modifiers' კონტეინერს 'emplace_back' მეთოდით. გამონაკლისის შემთხვევაში მოხდება მეხსიერების გაჟონვა. llvm-stress.cpp 685
• V1023 [CWE-460] მაჩვენებელი მფლობელის გარეშე ემატება 'Modifiers' კონტეინერს 'emplace_back' მეთოდით. გამონაკლისის შემთხვევაში მოხდება მეხსიერების გაჟონვა. llvm-stress.cpp 686
• V1023 [CWE-460] მაჩვენებელი მფლობელის გარეშე ემატება 'Modifiers' კონტეინერს 'emplace_back' მეთოდით. გამონაკლისის შემთხვევაში მოხდება მეხსიერების გაჟონვა. llvm-stress.cpp 688
• V1023 [CWE-460] მაჩვენებელი მფლობელის გარეშე ემატება 'Modifiers' კონტეინერს 'emplace_back' მეთოდით. გამონაკლისის შემთხვევაში მოხდება მეხსიერების გაჟონვა. llvm-stress.cpp 689
• V1023 [CWE-460] მაჩვენებელი მფლობელის გარეშე ემატება 'Modifiers' კონტეინერს 'emplace_back' მეთოდით. გამონაკლისის შემთხვევაში მოხდება მეხსიერების გაჟონვა. llvm-stress.cpp 690
• V1023 [CWE-460] მაჩვენებელი მფლობელის გარეშე ემატება 'Modifiers' კონტეინერს 'emplace_back' მეთოდით. გამონაკლისის შემთხვევაში მოხდება მეხსიერების გაჟონვა. llvm-stress.cpp 691
• V1023 [CWE-460] მაჩვენებელი მფლობელის გარეშე ემატება 'Modifiers' კონტეინერს 'emplace_back' მეთოდით. გამონაკლისის შემთხვევაში მოხდება მეხსიერების გაჟონვა. llvm-stress.cpp 692
• V1023 [CWE-460] მაჩვენებელი მფლობელის გარეშე ემატება 'Modifiers' კონტეინერს 'emplace_back' მეთოდით. გამონაკლისის შემთხვევაში მოხდება მეხსიერების გაჟონვა. llvm-stress.cpp 693
• V1023 [CWE-460] მაჩვენებელი მფლობელის გარეშე ემატება 'Modifiers' კონტეინერს 'emplace_back' მეთოდით. გამონაკლისის შემთხვევაში მოხდება მეხსიერების გაჟონვა. llvm-stress.cpp 694
• V1023 [CWE-460] მაჩვენებლის მფლობელის გარეშე ემატება 'Operands' კონტეინერს 'emplace_back' მეთოდით. გამონაკლისის შემთხვევაში მოხდება მეხსიერების გაჟონვა. GlobalISelEmitter.cpp 1911 წ
• V1023 [CWE-460] კურსორი მფლობელის გარეშე ემატება 'Stash' კონტეინერს 'emplace_back' მეთოდით. გამონაკლისის შემთხვევაში მოხდება მეხსიერების გაჟონვა. GlobalISelEmitter.cpp 2100
• V1023 [CWE-460] მაჩვენებლის მფლობელის გარეშე ემატება 'Matchers' კონტეინერს 'emplace_back' მეთოდით. გამონაკლისის შემთხვევაში მოხდება მეხსიერების გაჟონვა. GlobalISelEmitter.cpp 2702

დასკვნა

სულ 60 გაფრთხილება გავუკეთე და მერე გავჩერდი. არის თუ არა სხვა დეფექტები, რომლებსაც PVS-Studio ანალიზატორი აღმოაჩენს LLVM-ში? Დიახ მაქვს. თუმცა, როცა სტატიისთვის კოდის ფრაგმენტებს ვწერდი, გვიან საღამო იყო, უფრო სწორად, ღამეც კი იყო და გადავწყვიტე, რომ დრო იყო, დღე დამერქვა.

იმედი მაქვს, რომ თქვენთვის საინტერესო აღმოჩნდა და გსურთ სცადოთ PVS-Studio ანალიზატორი.

შეგიძლიათ ჩამოტვირთოთ ანალიზატორი და მიიღოთ მაღაროელების გასაღები აქ ეს გვერდი.

რაც მთავარია, რეგულარულად გამოიყენეთ სტატიკური ანალიზი. ერთჯერადი შემოწმებებიჩვენს მიერ განხორციელებული სტატიკური ანალიზის მეთოდოლოგიის პოპულარიზაციის მიზნით და PVS-Studio არ არის ნორმალური სცენარი.

წარმატებებს გისურვებთ თქვენი კოდის ხარისხისა და სანდოობის გაუმჯობესებაში!

თუ გსურთ გაუზიაროთ ეს სტატია ინგლისურენოვან აუდიტორიას, გთხოვთ, გამოიყენოთ თარგმანის ბმული: ანდრეი კარპოვი. შეცდომების პოვნა LLVM 8-ში PVS-Studio-ით.

წყარო: www.habr.com