पीवीएस-स्टूडियो विश्लेषक का उपयोग करके एलएलवीएम 8 में बग ढूंढना

हमारे पीवीएस-स्टूडियो विश्लेषक का उपयोग करके एलएलवीएम परियोजना की अंतिम कोड जांच को दो साल से अधिक समय बीत चुका है। आइए सुनिश्चित करें कि पीवीएस-स्टूडियो विश्लेषक अभी भी त्रुटियों और संभावित कमजोरियों की पहचान करने के लिए एक अग्रणी उपकरण है। ऐसा करने के लिए, हम एलएलवीएम 8.0.0 रिलीज में नई त्रुटियों की जांच करेंगे और ढूंढेंगे।

लेख लिखा जाना है

सच कहूँ तो, मैं यह लेख लिखना नहीं चाहता था। किसी ऐसे प्रोजेक्ट के बारे में लिखना दिलचस्प नहीं है जिसे हम पहले ही कई बार जाँच चुके हैं (1, 2, 3). किसी नई चीज़ के बारे में लिखना बेहतर है, लेकिन मेरे पास कोई विकल्प नहीं है।

हर बार एलएलवीएम का एक नया संस्करण जारी या अद्यतन किया जाता है क्लैंग स्टेटिक विश्लेषक, हमें अपने मेल में निम्नलिखित प्रकार के प्रश्न प्राप्त होते हैं:

देखिए, क्लैंग स्टेटिक एनालाइजर के नए संस्करण ने नई त्रुटियां ढूंढना सीख लिया है! मुझे ऐसा लगता है कि पीवीएस-स्टूडियो के उपयोग की प्रासंगिकता कम हो रही है। क्लैंग को पहले की तुलना में अधिक त्रुटियां मिलती हैं और पीवीएस-स्टूडियो की क्षमताओं का पता चलता है। आपका इसके बारे में क्या सोचना है?

इसका मैं हमेशा कुछ इस प्रकार उत्तर देना चाहता हूँ:

हम भी खाली नहीं बैठते! हमने पीवीएस-स्टूडियो विश्लेषक की क्षमताओं में उल्लेखनीय सुधार किया है। इसलिए चिंता न करें, हम पहले की तरह आगे बढ़ते रहेंगे।

दुर्भाग्य से, यह एक ख़राब उत्तर है. इसमें कोई सबूत नहीं हैं. और इसीलिए मैं अब यह लेख लिख रहा हूं। इसलिए, एलएलवीएम प्रोजेक्ट की एक बार फिर जांच की गई और इसमें कई तरह की त्रुटियां पाई गईं। अब मैं उन्हें प्रदर्शित करूँगा जो मुझे दिलचस्प लगे। क्लैंग स्टेटिक एनालाइज़र इन त्रुटियों का पता नहीं लगा सकता (या इसकी मदद से ऐसा करना बेहद असुविधाजनक है)। पर हम यह कर सकते हैं। इसके अलावा, मैंने एक ही शाम में इन सभी त्रुटियों को ढूंढ लिया और लिख लिया।

लेकिन लेख लिखने में कई सप्ताह लग गए। मैं यह सब पाठ में डालने के लिए खुद को तैयार नहीं कर सका :)।

वैसे, यदि आप रुचि रखते हैं कि पीवीएस-स्टूडियो विश्लेषक में त्रुटियों और संभावित कमजोरियों की पहचान करने के लिए किन तकनीकों का उपयोग किया जाता है, तो मैं इससे परिचित होने का सुझाव देता हूं ध्यान दें.

नये और पुराने निदान

जैसा कि पहले ही उल्लेख किया गया है, लगभग दो साल पहले एलएलवीएम परियोजना की एक बार फिर जाँच की गई थी, और पाई गई त्रुटियों को ठीक कर दिया गया था। अब यह आलेख त्रुटियों का एक नया बैच प्रस्तुत करेगा। नए बग क्यों पाए गए? इसके 3 कारण हैं:

1. एलएलवीएम प्रोजेक्ट विकसित हो रहा है, पुराने कोड को बदल रहा है और नया कोड जोड़ रहा है। स्वाभाविक रूप से, संशोधित और लिखित कोड में नई त्रुटियाँ हैं। यह स्पष्ट रूप से दर्शाता है कि स्थैतिक विश्लेषण का उपयोग नियमित रूप से किया जाना चाहिए, कभी-कभार नहीं। हमारे लेख पीवीएस-स्टूडियो विश्लेषक की क्षमताओं को अच्छी तरह दिखाते हैं, लेकिन इसका कोड गुणवत्ता में सुधार और त्रुटियों को ठीक करने की लागत को कम करने से कोई लेना-देना नहीं है। नियमित रूप से एक स्थिर कोड विश्लेषक का प्रयोग करें!
2. हम मौजूदा निदान को अंतिम रूप दे रहे हैं और उसमें सुधार कर रहे हैं। इसलिए, विश्लेषक उन त्रुटियों की पहचान कर सकता है जिन पर उसने पिछले स्कैन के दौरान ध्यान नहीं दिया था।
3. पीवीएस-स्टूडियो में नए डायग्नोस्टिक्स सामने आए हैं जो 2 साल पहले मौजूद नहीं थे। मैंने पीवीएस-स्टूडियो के विकास को स्पष्ट रूप से दिखाने के लिए उन्हें एक अलग खंड में उजागर करने का निर्णय लिया।

निदान द्वारा पहचाने गए दोष जो 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
  ....
}

पीवीएस-स्टूडियो चेतावनी: V501 [सीडब्ल्यूई-570] '||' के बाईं और दाईं ओर समान उप-अभिव्यक्तियाँ 'Name.startswith("avx512.mask.permvar.")' हैं। ऑपरेटर। ऑटोअपग्रेड.सीपीपी 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;
  ....
}

चेतावनी पीवीएस-स्टूडियो: 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;
  ....
}

पीवीएस-स्टूडियो चेतावनी: V502 [सीडब्ल्यूई-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;
  }
  ....
}

पीवीएस-स्टूडियो चेतावनी: V522 [सीडब्ल्यूई-476] शून्य सूचक 'एलएचएस' का डीरेफ़रेंसिंग हो सकता है। टीजीपार्सर.सीपीपी 2152

यदि सूचक एलएचएस शून्य है, चेतावनी जारी की जानी चाहिए। हालाँकि, इसके बजाय, इसी शून्य सूचक को असंदर्भित किया जाएगा: LHS->getAsString().

यह एक बहुत ही सामान्य स्थिति है जब त्रुटि हैंडलर में कोई त्रुटि छिपी होती है, क्योंकि कोई भी उनका परीक्षण नहीं करता है। स्थैतिक विश्लेषक सभी पहुंच योग्य कोड की जांच करते हैं, चाहे इसका कितनी भी बार उपयोग किया गया हो। यह एक बहुत अच्छा उदाहरण है कि कैसे स्थैतिक विश्लेषण अन्य परीक्षण और त्रुटि सुरक्षा तकनीकों का पूरक है।

समान सूचक प्रबंधन त्रुटि आरएचएस ठीक नीचे दिए गए कोड में अनुमति दी गई है: V522 [CWE-476] शून्य सूचक 'आरएचएस' का डीरेफ़रेंसिंग हो सकता है। टीजीपार्सर.सीपीपी 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);
  }
  ....
}

पीवीएस-स्टूडियो चेतावनी: वी522 [सीडब्ल्यूई-476] नल पॉइंटर 'प्रोगक्लोन' की डीरेफ़रेंसिंग हो सकती है। ग़लतसंकलन.सीपीपी 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;
  }
  ....
}

पीवीएस-स्टूडियो चेतावनी: वी522 [सीडब्ल्यूई-476] नल पॉइंटर 'टेस्ट' का डीरेफ़रेंसिंग हो सकता है। ग़लतसंकलन.सीपीपी 709

फिर वही स्थिति. सबसे पहले, वस्तु की सामग्री को स्थानांतरित किया जाता है, और फिर इसका उपयोग इस तरह किया जाता है जैसे कि कुछ भी नहीं हुआ था। C++ में मूवमेंट सिमेंटिक्स दिखाई देने के बाद मैं इस स्थिति को प्रोग्राम कोड में अधिक से अधिक बार देखता हूं। यही कारण है कि मुझे C++ भाषा पसंद है! अपनी ही टांग अड़ाने के और भी नए-नए तरीके हैं। पीवीएस-स्टूडियो विश्लेषक हमेशा काम करेगा :)।

फ़्रैगमेंट 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);
}

पीवीएस-स्टूडियो चेतावनी: वी522 [सीडब्ल्यूई-476] नल पॉइंटर 'टाइप' का डीरेफ़रेंसिंग हो सकता है। प्रिटीफंक्शनडम्पर.सीपीपी 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());
   ....
}

पीवीएस-स्टूडियो चेतावनी: वी522 [सीडब्ल्यूई-476] नल पॉइंटर 'टाइ' का डीरेफ़रेंसिंग हो सकता है। 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;
}

पीवीएस-स्टूडियो चेतावनी: V570 'पहचानकर्ता->प्रकार' वैरिएबल स्वयं को सौंपा गया है। 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;
  ....
}

पीवीएस-स्टूडियो चेतावनी: V622 [सीडब्ल्यूई-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");
  ....
}

पीवीएस-स्टूडियो चेतावनी: V595 [सीडब्ल्यूई-476] 'कैली' पॉइंटर का उपयोग nullptr के विरुद्ध सत्यापित होने से पहले किया गया था। जाँच पंक्तियाँ: 172, 174. AMDGPUInline.cpp 172

सूचक कॉल प्राप्त करने वाला फ़ंक्शन को कॉल करने के समय शुरुआत में इसे डीरेफ़रेंस किया जाता है टीटीआई प्राप्त करें.

और फिर यह पता चलता है कि समानता के लिए इस सूचक की जाँच की जानी चाहिए 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()) {               // <=
  ....
}

पीवीएस-स्टूडियो चेतावनी: 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());     // <=
  ....
}

पीवीएस-स्टूडियो चेतावनी: 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 नंबर वाली चेतावनियों का अध्ययन करने में कोई दिलचस्पी नहीं रह गई। इसलिए मुझे नहीं पता कि यहां सूचीबद्ध त्रुटियों के अलावा और भी समान त्रुटियां हैं या नहीं। सबसे अधिक संभावना है कि वहाँ है.

टुकड़ा एन17, एन18: संदिग्ध बदलाव

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

पीवीएस-स्टूडियो चेतावनी: V629 [सीडब्ल्यूई-190] '~(आकार - 1) << 1' अभिव्यक्ति का निरीक्षण करने पर विचार करें। 32-बिट मान का बिट स्थानांतरण और उसके बाद 64-बिट प्रकार में विस्तार। AArch64AddressingModes.h 260

हो सकता है कि यह कोई बग न हो और कोड बिल्कुल वैसे ही काम करता है जैसा कि सोचा गया था। लेकिन यह स्पष्ट रूप से एक बहुत ही संदिग्ध जगह है और इसकी जाँच की जानी चाहिए।

मान लीजिए वेरिएबल आकार 16 के बराबर है, और फिर कोड के लेखक ने इसे एक वेरिएबल में प्राप्त करने की योजना बनाई एनएमआईएमएस अर्थ:

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

पीवीएस-स्टूडियो चेतावनी: V646 [सीडब्ल्यूई-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;
}

पीवीएस-स्टूडियो चेतावनियाँ:

• V655 [CWE-480] तारों को संयोजित किया गया था लेकिन उनका उपयोग नहीं किया गया है। 'परिणाम + Name.str()' अभिव्यक्ति का निरीक्षण करने पर विचार करें। प्रतीक.सीपीपी 32
• V655 [CWE-480] तारों को संयोजित किया गया था लेकिन उनका उपयोग नहीं किया गया है। 'परिणाम + "(ObjC क्लास)" + Name.str()' अभिव्यक्ति का निरीक्षण करने पर विचार करें। प्रतीक.सीपीपी 35
• V655 [CWE-480] तारों को संयोजित किया गया था लेकिन उनका उपयोग नहीं किया गया है। 'परिणाम + "(ओबीजेसी क्लास ईएच) " + Name.str()' अभिव्यक्ति का निरीक्षण करने पर विचार करें। प्रतीक.सीपीपी 38
• V655 [CWE-480] तारों को संयोजित किया गया था लेकिन उनका उपयोग नहीं किया गया है। 'परिणाम + "(ObjC IVar)" + Name.str()' अभिव्यक्ति का निरीक्षण करने पर विचार करें। प्रतीक.सीपीपी 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();
    }
  }
}

खतरनाक कोड स्वयं ढूंढने का प्रयास करें। और यह ध्यान भटकाने के लिए एक तस्वीर है ताकि तुरंत उत्तर पर ध्यान न दिया जाए:

पीवीएस-स्टूडियो चेतावनी: V708 [सीडब्ल्यूई-758] खतरनाक निर्माण का उपयोग किया जाता है: 'फीचरमैप[ऑप] = फीचर्समैप.साइज()', जहां 'फीचरमैप' 'मैप' वर्ग का है। इससे अपरिभाषित व्यवहार हो सकता है. 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;
  }
  ....
}

पीवीएस-स्टूडियो चेतावनी: V519 [सीडब्ल्यूई-563] 'एनटाइप' वेरिएबल को लगातार दो बार मान निर्दिष्ट किया गया है। शायद ये एक गलती है. पंक्तियाँ जाँचें: 1663, 1664। MacOObjectFile.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;
  ....
}

पीवीएस-स्टूडियो चेतावनी: V519 [CWE-563] 'संरेखण' चर को लगातार दो बार मान निर्दिष्ट किया गया है। शायद ये एक गलती है. जाँच पंक्तियाँ: 1158, 1160। LoadStoreVectorizer.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;
  }
  ....
}

पीवीएस-स्टूडियो चेतावनी: V547 [सीडब्ल्यूई-571] अभिव्यक्ति 'नेक्स्टबाइट != 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;
  ....
}

पीवीएस-स्टूडियो चेतावनी: V560 [सीडब्ल्यूई-570] सशर्त अभिव्यक्ति का एक हिस्सा हमेशा गलत होता है: रेगनो == 0एक्सई। ARMDisassembler.cpp 939

स्थिरांक 0xE दशमलव में मान 14 है। इंतिहान रेगनो == 0xe इसका कोई मतलब नहीं है क्योंकि अगर पंजीकरण संख्या > 13, तो फ़ंक्शन अपना निष्पादन पूरा कर लेगा।

आईडी V547 और V560 के साथ कई अन्य चेतावनियाँ थीं, लेकिन वैसी ही V595, मुझे इन चेतावनियों का अध्ययन करने में कोई दिलचस्पी नहीं थी। यह पहले से ही स्पष्ट था कि मेरे पास लेख लिखने के लिए पर्याप्त सामग्री थी :)। इसलिए, यह अज्ञात है कि पीवीएस-स्टूडियो का उपयोग करके एलएलवीएम में इस प्रकार की कितनी त्रुटियों की पहचान की जा सकती है।

मैं आपको एक उदाहरण दूंगा कि इन ट्रिगर्स का अध्ययन करना उबाऊ क्यों है। निम्नलिखित कोड के लिए चेतावनी जारी करने में विश्लेषक बिल्कुल सही है। लेकिन ये कोई गलती नहीं है.

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

पीवीएस-स्टूडियो चेतावनी: V547 [CWE-570] अभिव्यक्ति '!HasError' हमेशा झूठी होती है। अनरैप्डलाइनपार्सर.सीपीपी 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();
  }
  ....
}

पीवीएस-स्टूडियो चेतावनी: V612 [सीडब्ल्यूई-670] एक लूप के भीतर बिना शर्त 'वापसी'। R600ऑप्टिमाइज़वेक्टररजिस्टर्स.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();
}

पीवीएस-स्टूडियो चेतावनी: V779 [सीडब्ल्यूई-561] पहुंच योग्य कोड का पता चला। यह संभव है कि कोई त्रुटि मौजूद हो. ExecutionUtils.cpp 146

जैसा कि आप देख सकते हैं, ऑपरेटर की दोनों शाखाएँ if ऑपरेटर को कॉल के साथ समाप्त होता है वापसी. तदनुसार, कंटेनर CtorDtorsByप्रायोरिटी कभी साफ़ नहीं किया जाएगा.

फ़्रैगमेंट 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;
}

पीवीएस-स्टूडियो चेतावनी: V779 [सीडब्ल्यूई-561] पहुंच योग्य कोड का पता चला। यह संभव है कि कोई त्रुटि मौजूद हो. एलएलपीअर्स.सीपीपी 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);
  ....
}

पीवीएस-स्टूडियो चेतावनी: V784 बिट मास्क का आकार पहले ऑपरेंड के आकार से कम है। इससे उच्च बिट्स का नुकसान होगा. रनटाइमडिल्ड.सीपीपी 815

कृपया ध्यान दें कि फ़ंक्शन getStubAlignment रिटर्न प्रकार अहस्ताक्षरित. आइए अभिव्यक्ति के मान की गणना करें, यह मानते हुए कि फ़ंक्शन मान 8 लौटाता है:

~(getStubAlignment() - 1)

~(8यू-1)

0xFFFFFFFF8u

अब ध्यान दें कि वेरिएबल डेटा आकार इसमें 64-बिट अहस्ताक्षरित प्रकार है। यह पता चला है कि डेटासाइज़ और 0xFFFFFF8u ऑपरेशन करते समय, सभी बत्तीस उच्च-ऑर्डर बिट्स शून्य पर रीसेट हो जाएंगे। सबसे अधिक संभावना है, यह वह नहीं है जो प्रोग्रामर चाहता था। मुझे संदेह है कि वह गणना करना चाहता था: डेटा आकार और 0xFFFFFFFFFFFFFF8u।

त्रुटि को ठीक करने के लिए, आपको यह लिखना चाहिए:

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

पीवीएस-स्टूडियो चेतावनी: V1028 [सीडब्ल्यूई-190] संभावित अतिप्रवाह। 'NumElts * स्केल' ऑपरेटर के ऑपरेंड को '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;
  }
  ....
}

V778 [सीडब्ल्यूई-682] दो समान कोड टुकड़े पाए गए। शायद, यह एक टाइपो त्रुटि है और 'Op1' के बजाय 'Op0' वेरिएबल का उपयोग किया जाना चाहिए। InstCombineCompares.cpp 5507

यह नया दिलचस्प डायग्नोस्टिक उन स्थितियों की पहचान करता है जहां कोड का एक टुकड़ा कॉपी किया गया है और इसमें कुछ नाम बदले जाने लगे हैं, लेकिन एक जगह उन्होंने इसे ठीक नहीं किया है।

कृपया ध्यान दें कि दूसरे ब्लॉक में वे बदल गये 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;
  };
  ....
};

पीवीएस-स्टूडियो चेतावनी: V1001 [सीडब्ल्यूई-563] 'मोड' वेरिएबल असाइन किया गया है लेकिन फ़ंक्शन के अंत तक इसका उपयोग नहीं किया जाता है। 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;
}

चेतावनी पीवीएस-स्टूडियो: वी1001 [सीडब्ल्यूई-563] 'आकार' वेरिएबल असाइन किया गया है लेकिन फ़ंक्शन के अंत तक इसका उपयोग नहीं किया जाता है। ऑब्जेक्ट.सीपीपी 424

स्थिति पिछली जैसी ही है. यह लिखा जाना चाहिए:

this->Size += this->EntrySize;

फ़्रैगमेंट N38-N47: वे सूचकांक की जाँच करना भूल गए

पहले, हमने डायग्नोस्टिक ट्रिगरिंग के उदाहरण देखे थे V595. इसका सार यह है कि सूचक को शुरुआत में डीरेफ़रेंस किया जाता है, और उसके बाद ही जाँच की जाती है। युवा निदान V1004 अर्थ में विपरीत है, लेकिन बहुत सारी त्रुटियाँ भी प्रकट करता है। यह उन स्थितियों की पहचान करता है जहां शुरुआत में पॉइंटर की जांच की गई थी और फिर ऐसा करना भूल गया था। आइए एलएलवीएम के अंदर पाए जाने वाले ऐसे मामलों पर नजर डालें।

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());  // <=
  ....
}

पीवीएस-स्टूडियो चेतावनी: वी1004 [सीडब्ल्यूई-476] 'पीटीआर' पॉइंटर को 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(); // <=
  ....
}

पीवीएस-स्टूडियो चेतावनी: वी1004 [सीडब्ल्यूई-476] 'एफडी' पॉइंटर को 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());     // <=
  ....
}

पीवीएस-स्टूडियो चेतावनी: वी1004 [सीडब्ल्यूई-476] 'PtrTy' पॉइंटर को nullptr के विरुद्ध सत्यापित करने के बाद असुरक्षित रूप से उपयोग किया गया था। जाँच पंक्तियाँ: 960, 965। इंटरलीव्डलोडकॉम्बाइनपास.सीपीपी 965

ऐसी गलतियों से खुद को कैसे बचाएं? कोड-समीक्षा पर अधिक ध्यान दें और नियमित रूप से अपने कोड की जांच करने के लिए पीवीएस-स्टूडियो स्थिर विश्लेषक का उपयोग करें।

इस प्रकार की त्रुटियों वाले अन्य कोड अंशों का हवाला देने का कोई मतलब नहीं है। मैं लेख में केवल चेतावनियों की एक सूची छोड़ूंगा:

• V1004 [सीडब्ल्यूई-476] 'एक्सपीआर' पॉइंटर को nullptr के विरुद्ध सत्यापित करने के बाद असुरक्षित रूप से उपयोग किया गया था। जाँच पंक्तियाँ: 1049, 1078. DebugInfoMetadata.cpp 1078
• V1004 [CWE-476] 'PI' पॉइंटर को nullptr के विरुद्ध सत्यापित करने के बाद असुरक्षित रूप से उपयोग किया गया था। जाँच पंक्तियाँ: 733, 753। लिगेसीपासमैनेजर.सीपीपी 753
• V1004 [सीडब्ल्यूई-476] 'स्टेटपॉइंटकॉल' पॉइंटर को nullptr के विरुद्ध सत्यापित किए जाने के बाद असुरक्षित रूप से उपयोग किया गया था। जाँच पंक्तियाँ: 4371, 4379. सत्यापनकर्ता.सीपीपी 4379
• V1004 [सीडब्ल्यूई-476] 'आरवी' पॉइंटर को nullptr के विरुद्ध सत्यापित किए जाने के बाद असुरक्षित रूप से उपयोग किया गया था। जाँच पंक्तियाँ: 2263, 2268. TGParser.cpp 2268
• V1004 [CWE-476] 'CalleeFn' पॉइंटर को nullptr के विरुद्ध सत्यापित करने के बाद असुरक्षित रूप से उपयोग किया गया था। पंक्तियाँ जाँचें: 1081, 1096। SimplifyLibCalls.cpp 1096
• V1004 [सीडब्ल्यूई-476] 'टीसी' पॉइंटर को nullptr के विरुद्ध सत्यापित करने के बाद असुरक्षित रूप से उपयोग किया गया था। जाँच पंक्तियाँ: 1819, 1824। ड्राइवर.सीपीपी 1824

फ़्रैगमेंट N48-N60: गंभीर नहीं, लेकिन एक दोष (संभावित मेमोरी लीक)

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

पीवीएस-स्टूडियो चेतावनी: V1023 [सीडब्ल्यूई-460] मालिक के बिना एक पॉइंटर को 'एम्प्लेस_बैक' विधि द्वारा 'स्ट्रैटेजी' कंटेनर में जोड़ा जाता है। अपवाद की स्थिति में मेमोरी लीक हो जाएगी. llvm-isel-fuzzer.cpp 58

किसी कंटेनर के अंत में कोई तत्व जोड़ना जैसे एसटीडी::वेक्टर > आप बस लिख नहीं सकते xxx.push_back(नया एक्स), क्योंकि इसमें कोई अंतर्निहित रूपांतरण नहीं है X* в std::unique_ptr.

एक सामान्य समाधान लिखना है xxx.emplace_back(नया एक्स)चूंकि यह संकलित करता है: विधि 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>())

इस प्रकार का दोष एलएलवीएम के लिए गंभीर नहीं है। यदि मेमोरी आवंटित नहीं की जा सकती, तो कंपाइलर बस बंद हो जाएगा। हालाँकि, लंबे समय तक चलने वाले अनुप्रयोगों के लिए अपटाइम, जो मेमोरी आवंटन विफल होने पर समाप्त नहीं हो सकता है, यह एक वास्तविक ख़राब बग हो सकता है।

इसलिए, हालांकि यह कोड एलएलवीएम के लिए कोई व्यावहारिक खतरा पैदा नहीं करता है, मुझे इस त्रुटि पैटर्न के बारे में बात करना उपयोगी लगा और पीवीएस-स्टूडियो विश्लेषक ने इसे पहचानना सीख लिया है।

इस प्रकार की अन्य चेतावनियाँ:

• V1023 [CWE-460] मालिक के बिना एक पॉइंटर को 'emplace_back' विधि द्वारा 'पास' कंटेनर में जोड़ा जाता है। अपवाद की स्थिति में मेमोरी लीक हो जाएगी. पासमैनेजर.एच 546
• V1023 [CWE-460] मालिक के बिना एक पॉइंटर को 'emplace_back' विधि द्वारा 'AAs' कंटेनर में जोड़ा जाता है। अपवाद की स्थिति में मेमोरी लीक हो जाएगी. उपनामविश्लेषण.h 324
• V1023 [CWE-460] मालिक के बिना एक पॉइंटर को 'emplace_back' विधि द्वारा 'एंट्रीज़' कंटेनर में जोड़ा जाता है। अपवाद की स्थिति में मेमोरी लीक हो जाएगी. DWARFDebugFrame.cpp 519
• V1023 [CWE-460] मालिक के बिना एक पॉइंटर को 'emplace_back' विधि द्वारा 'AllEdges' कंटेनर में जोड़ा जाता है। अपवाद की स्थिति में मेमोरी लीक हो जाएगी. सीएफजीएमएसटी.एच 268
• V1023 [CWE-460] मालिक के बिना एक पॉइंटर को 'emplace_back' विधि द्वारा 'VMaps' कंटेनर में जोड़ा जाता है। अपवाद की स्थिति में मेमोरी लीक हो जाएगी. SimpleLoopUnswitch.cpp 2012
• V1023 [CWE-460] मालिक के बिना एक पॉइंटर को 'emplace_back' विधि द्वारा 'रिकॉर्ड्स' कंटेनर में जोड़ा जाता है। अपवाद की स्थिति में मेमोरी लीक हो जाएगी. FDRLogBuilder.h 30
• V1023 [CWE-460] मालिक के बिना एक पॉइंटर को 'emplace_back' विधि द्वारा 'PendingSubmodules' कंटेनर में जोड़ा जाता है। अपवाद की स्थिति में मेमोरी लीक हो जाएगी. ModuleMap.cpp 810
• V1023 [CWE-460] मालिक के बिना एक पॉइंटर को 'emplace_back' विधि द्वारा 'ऑब्जेक्ट्स' कंटेनर में जोड़ा जाता है। अपवाद की स्थिति में मेमोरी लीक हो जाएगी. डीबगमैप.सीपीपी 88
• V1023 [CWE-460] मालिक के बिना एक पॉइंटर को 'emplace_back' विधि द्वारा 'रणनीतियाँ' कंटेनर में जोड़ा जाता है। अपवाद की स्थिति में मेमोरी लीक हो जाएगी. llvm-isel-fuzzer.cpp 60
• V1023 [CWE-460] मालिक के बिना एक पॉइंटर को 'emplace_back' विधि द्वारा 'संशोधक' कंटेनर में जोड़ा जाता है। अपवाद की स्थिति में मेमोरी लीक हो जाएगी. एलएलवीएम-स्ट्रेस.सीपीपी 685
• V1023 [CWE-460] मालिक के बिना एक पॉइंटर को 'emplace_back' विधि द्वारा 'संशोधक' कंटेनर में जोड़ा जाता है। अपवाद की स्थिति में मेमोरी लीक हो जाएगी. एलएलवीएम-स्ट्रेस.सीपीपी 686
• V1023 [CWE-460] मालिक के बिना एक पॉइंटर को 'emplace_back' विधि द्वारा 'संशोधक' कंटेनर में जोड़ा जाता है। अपवाद की स्थिति में मेमोरी लीक हो जाएगी. एलएलवीएम-स्ट्रेस.सीपीपी 688
• V1023 [CWE-460] मालिक के बिना एक पॉइंटर को 'emplace_back' विधि द्वारा 'संशोधक' कंटेनर में जोड़ा जाता है। अपवाद की स्थिति में मेमोरी लीक हो जाएगी. एलएलवीएम-स्ट्रेस.सीपीपी 689
• V1023 [CWE-460] मालिक के बिना एक पॉइंटर को 'emplace_back' विधि द्वारा 'संशोधक' कंटेनर में जोड़ा जाता है। अपवाद की स्थिति में मेमोरी लीक हो जाएगी. एलएलवीएम-स्ट्रेस.सीपीपी 690
• V1023 [CWE-460] मालिक के बिना एक पॉइंटर को 'emplace_back' विधि द्वारा 'संशोधक' कंटेनर में जोड़ा जाता है। अपवाद की स्थिति में मेमोरी लीक हो जाएगी. एलएलवीएम-स्ट्रेस.सीपीपी 691
• V1023 [CWE-460] मालिक के बिना एक पॉइंटर को 'emplace_back' विधि द्वारा 'संशोधक' कंटेनर में जोड़ा जाता है। अपवाद की स्थिति में मेमोरी लीक हो जाएगी. एलएलवीएम-स्ट्रेस.सीपीपी 692
• V1023 [CWE-460] मालिक के बिना एक पॉइंटर को 'emplace_back' विधि द्वारा 'संशोधक' कंटेनर में जोड़ा जाता है। अपवाद की स्थिति में मेमोरी लीक हो जाएगी. एलएलवीएम-स्ट्रेस.सीपीपी 693
• V1023 [CWE-460] मालिक के बिना एक पॉइंटर को 'emplace_back' विधि द्वारा 'संशोधक' कंटेनर में जोड़ा जाता है। अपवाद की स्थिति में मेमोरी लीक हो जाएगी. एलएलवीएम-स्ट्रेस.सीपीपी 694
• V1023 [CWE-460] मालिक के बिना एक पॉइंटर को 'emplace_back' विधि द्वारा 'ऑपरेंड' कंटेनर में जोड़ा जाता है। अपवाद की स्थिति में मेमोरी लीक हो जाएगी. GlobalISelEmitter.cpp 1911
• V1023 [CWE-460] मालिक के बिना एक पॉइंटर को 'emplace_back' विधि द्वारा 'स्टैश' कंटेनर में जोड़ा जाता है। अपवाद की स्थिति में मेमोरी लीक हो जाएगी. GlobalISelEmitter.cpp 2100
• V1023 [सीडब्ल्यूई-460] मालिक के बिना एक पॉइंटर को 'एम्प्लेस_बैक' विधि द्वारा 'मैचर्स' कंटेनर में जोड़ा जाता है। अपवाद की स्थिति में मेमोरी लीक हो जाएगी. GlobalISelEmitter.cpp 2702

निष्कर्ष

मैंने कुल मिलाकर 60 चेतावनियाँ जारी कीं और फिर बंद कर दिया। क्या पीवीएस-स्टूडियो विश्लेषक एलएलवीएम में अन्य दोषों का पता लगाता है? हाँ मेरे पास है। हालाँकि, जब मैं लेख के लिए कोड अंश लिख रहा था, तब देर शाम, या बल्कि रात हो चुकी थी, और मैंने फैसला किया कि इसे बंद करने का समय आ गया है।

मुझे आशा है कि आपको यह दिलचस्प लगा होगा और आप पीवीएस-स्टूडियो विश्लेषक को आज़माना चाहेंगे।

आप विश्लेषक डाउनलोड कर सकते हैं और माइनस्वीपर कुंजी प्राप्त कर सकते हैं यह पृष्ठ.

सबसे महत्वपूर्ण बात यह है कि नियमित रूप से स्थैतिक विश्लेषण का उपयोग करें। एक बार की जाँचस्थैतिक विश्लेषण और पीवीएस-स्टूडियो की पद्धति को लोकप्रिय बनाने के लिए हमारे द्वारा किए गए कार्यक्रम कोई सामान्य परिदृश्य नहीं हैं।

अपने कोड की गुणवत्ता और विश्वसनीयता में सुधार करने के लिए शुभकामनाएँ!

यदि आप इस लेख को अंग्रेजी भाषी दर्शकों के साथ साझा करना चाहते हैं, तो कृपया अनुवाद लिंक का उपयोग करें: एंड्री कारपोव। पीवीएस-स्टूडियो के साथ एलएलवीएम 8 में बग ढूंढना.

स्रोत: www.habr.com