पीवीएस-स्टूडियो के साथ एलएलवीएम 8 में कीड़े ढूंढना

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

जो लेख लिखा जाना चाहिए

सच कहूं, तो मुझे यह लेख लिखने का मन नहीं था। यह उस परियोजना के बारे में बात करने में बहुत मजेदार नहीं है जिसे हमने पहले ही एक से अधिक बार जांचा है ( 1 , 2 , 3 )। मैं इसके बजाय कुछ नया पसंद करूंगा, लेकिन मेरे पास कोई विकल्प नहीं था।

जब भी एलएलवीएम का नया संस्करण जारी होता है या क्लैंग स्टैटिक एनालाइज़र को अपडेट किया जाता है, हमें इन पंक्तियों के साथ ईमेल पढ़ने को मिलते हैं:

अरे, क्लैंग स्टैटिक एनालाइज़र के नए संस्करण को नए डायग्नोस्टिक्स मिले! पीवीएस-स्टूडियो कम प्रासंगिक हो रहा है। क्लैंग पहले की तुलना में अधिक बग का पता लगा सकता है और अब पीवीएस-स्टूडियो के साथ पकड़ बना रहा है। आप क्या कहेंगे?

इस पर मैं खुशी से जवाब दूंगा:

हम या तो चारों ओर नहीं किया गया है! हमने पीवीएस-स्टूडियो की क्षमताओं में काफी वृद्धि की है, इसलिए कोई चिंता नहीं है - हम अभी भी सबसे अच्छे हैं।

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

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

वैसे, अगर आपको आश्चर्य है कि पीवीएस-स्टूडियो बग और कमजोरियों का पता लगाने के लिए कौन सी तकनीक का उपयोग करते हैं, तो इस पोस्ट पर एक नज़र डालें।

नए और मौजूदा निदान

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

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

मौजूदा डायग्नोस्टिक्स द्वारा पाए गए दोष

स्निपेट नं। 1: कॉपी-पेस्ट करें

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

की घटना "avx512.mask.permvar।" प्रतिस्थापन दो बार जाँच की जाती है। दूसरी स्थिति स्पष्ट रूप से कुछ और जांच करने की थी, लेकिन प्रोग्रामर कॉपी की गई लाइन को बदलना भूल गया।

स्निपेट नं। 2: टाइपो

 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- स्टूडियो डायग्नोस्टिक संदेश: V501 समान उप-अभिव्यक्तियाँ हैं 'CXNameRange_WantQualifier' बाईं और दाईं ओर '|' ऑपरेटर। CIndex.cpp 7245

एक टाइपो के कारण दो बार नामित CXNameRange_WantQualifier का उपयोग किया जाता है।

स्निपेट नं। 3: ऑपरेटर पूर्वता पर भ्रम

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

PVS- स्टूडियो डायग्नोस्टिक संदेश: 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)) 

टर्नेरी ऑपरेटर वास्तव में बहुत मुश्किल है और तर्क त्रुटियों को जन्म दे सकता है। इसे सावधानी से उपयोग करें और इसके चारों ओर अतिरिक्त कोष्ठक लगाने में संकोच न करें। इस विषय पर और अधिक विस्तार से यहां चर्चा की गई है , "खंड से सावधान ?: ऑपरेटर और इसे कोष्ठक में संलग्न करें"।

स्निपेट नं। 4, 5: अशक्त सूचक

 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- स्टूडियो डायग्नोस्टिक संदेश: V522 [CWE-476] नल पॉइंटर की Lereferencing 'LHS' हो सकती है। TGParser.cpp 2152

यदि LHS सूचक शून्य होता है, तो प्रोग्राम एक चेतावनी उत्पन्न करने के लिए अपेक्षित है। इसके बजाय, यह अनुमान लगाएगा कि बहुत अशक्त सूचक: LHS-> getAsString () ।

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

RHS पॉइंटर के लिए एक समान दोषपूर्ण हैंडलर थोड़ा आगे पाया जाता है: V522 [CWE-476] अशक्त पॉइंटर 'RHS' की डेरेफेरिंग हो सकती है। TGParser.cpp 2186

स्निपेट नं। 6: एक चाल के बाद एक सूचक का उपयोग करना

 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] अशक्त सूचक 'ProgClone' की ड्राफ्टिंग हो सकती है। दुर्व्यवहार .पीसी 601

स्मार्ट पॉइंटर ProgClone पहले वस्तु स्वामित्व जारी करता है:

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

वास्तव में, ProgClone एक शून्य सूचक बन गया है - इसलिए, तकनीकी रूप से, एक शून्य सूचक थोड़ा और आगे बढ़ जाता है:

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

लेकिन ऐसा नहीं होगा! ध्यान दें कि लूप वास्तव में बिल्कुल भी निष्पादित नहीं होता है।

MiscompiledFunctions कंटेनर को पहले साफ़ किया जाता है:

 MiscompiledFunctions.clear(); 

और फिर इसका आकार लूप स्थिति में उपयोग किया जाता है:

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

जाहिर है, लूप अभी शुरू नहीं होगा। मुझे लगता है कि यह एक बग भी है, और कोड किसी भी तरह से अलग दिखने के लिए था।

मुझे लगता है कि हम यहां जो देखते हैं, वह कुख्यात त्रुटि समता है, जहां एक बग दूसरे के लिए भेस का काम करता है :)।

स्निपेट नं। 7: एक चाल के बाद एक सूचक का उपयोग करना

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

पीवीएस-स्टूडियो डायग्नोस्टिक संदेश: V522 [CWE-476] अशक्त सूचक 'टेस्ट' की ड्राफ्टिंग हो सकती है। मिसकंप्लीकेटेशन। 709

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

स्निपेट नं। 8: अशक्त सूचक

 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] अशक्त सूचक 'प्रकार' की डेरेफेरिंग हो सकती है। प्रिटीफंक्शनडॉपर। 233

त्रुटि संचालकों की तरह, डिबग डेटा को मुद्रित करने वाले परीक्षण कार्यों को आमतौर पर या तो पर्याप्त परीक्षण कवरेज नहीं मिलता है, और यह इसका एक उदाहरण है। उपयोगकर्ता को उनकी समस्याओं को हल करने में मदद करने के बजाय, फ़ंक्शन उन्हें ठीक करने के लिए इंतजार कर रहा है।

निश्चित कोड:

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

स्निपेट नं। 9: अशक्त सूचक

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

पीवीएस-स्टूडियो डायग्नोस्टिक संदेश: V522 [CWE-476] अशक्त सूचक 'Ty' की डेरेफेरिंग हो सकती है। SearchableTableEmitter.cpp 614

मुझे नहीं लगता कि आपको इस पर किसी टिप्पणी की आवश्यकता है।

स्निपेट नं। 10: टाइपो

 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; 

स्निपेट नं। 11: संदेहास्पद विराम

 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 [CWE-478] 'स्विच' स्टेटमेंट का निरीक्षण करने पर विचार करें। यह संभव है कि पहला 'केस' ऑपरेटर गायब हो। SystemZAsmParser.cpp 652

शुरुआत में एक बहुत ही संदिग्ध ब्रेक स्टेटमेंट है। यहाँ कुछ और नहीं होना चाहिए?

स्निपेट नं। 12: डेरेफेरिंग के बाद एक पॉइंटर को चेक करना

 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 [CWE-476] 'कैलली' पॉइंटर का उपयोग करने से पहले इसे nullptr के खिलाफ सत्यापित किया गया था। चेक लाइनें: 172, 174। AMDGPUInline.cpp 172

जब गेटटीटीआई फंक्शन कहा जाता है, तो कैली पॉइंटर को पहले डिरेल किया जाता है।

और फिर यह पता चला है कि सूचक को नल्टर के लिए जाँच की जानी चाहिए:

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

बहुत देर से ...

स्निपेट नं। 13 - नहीं ....: डेरेफेरिंग के बाद एक पॉइंटर को चेक करना

पिछला उदाहरण अद्वितीय नहीं है। इस स्निपेट में वही समस्या पाई गई है:

 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- स्टूडियो डायग्नोस्टिक संदेश: V595 [CWE-476] 'CalleeFn' पॉइंटर का उपयोग करने से पहले इसे nullptr के खिलाफ सत्यापित किया गया था। चेक लाइन्स: 1079, 1081. सिम्पलीफाईलाइब कॉलस। 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] 'एनडी' पॉइंटर का उपयोग करने से पहले इसे nullptr के खिलाफ सत्यापित किया गया था। जाँच लाइनें: 532, 534। SemaTemplateInstantiateDecl.cpp 532

और यहाँ:

• V595 [CWE-476] nullptr के खिलाफ सत्यापित होने से पहले 'U' पॉइंटर का उपयोग किया गया था। चेक लाइनें: 404, 407. DWARFFormValue.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 [CWE-190] '~ (आकार - 1) << 1' अभिव्यक्ति का निरीक्षण करने पर विचार करें। 64-बिट प्रकार के बाद के विस्तार के साथ 32-बिट मूल्य का बिट शिफ्टिंग। AArch64AddressingModes.h 260

यह कोड वास्तव में सही हो सकता है, लेकिन यह अजीब लग रहा है और जांच की आवश्यकता है।

मान लीजिए कि आकार चर का मूल्य 16 है; तब NImms चर निम्नलिखित मूल्य प्राप्त करने की उम्मीद है:

1111111111111111111111111111111111111111111111111111111111100000

लेकिन वास्तव में इसका मूल्य मिलेगा:

0000000000000000000000000000000011111111111111111111111111100000

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

समस्या इस प्रकार तय की जा सकती है:

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

इस प्रकार का एक और बग: V629 [CWE-190] 'Immr << 6' अभिव्यक्ति का निरीक्षण करने पर विचार करें। 64-बिट प्रकार के बाद के विस्तार के साथ 32-बिट मूल्य का बिट शिफ्टिंग। AArch64AddressingModes.h 269

स्निपेट नं। 19: कीवर्ड को मिस करना नहीं है ?

 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

यह एक बग नहीं है। यदि पहले स्टेटमेंट के अंत के बाद से जारी रहता है , तो यह मायने नहीं रखता कि उसके पास दूसरा कीवर्ड है या नहीं। व्यवहार किसी भी मामले में समान होगा। हालांकि, लापता अन्य कोड को कम पठनीय बनाता है और इसलिए, संभवतः खतरनाक है। यदि एक दिन भी गायब रहा, तो व्यवहार में भारी बदलाव आएगा। मैं दृढ़ता से और जोड़ने की सलाह देता हूं।

स्निपेट नं। 20: चार समान टाइपो

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

प्रोग्रामर ने गलती से + के बजाय + ऑपरेटर का उपयोग किया और चार अर्थहीन निर्माणों के साथ समाप्त हो गया।

स्निपेट नं। 21: अपरिभाषित व्यवहार

 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- स्टूडियो डायग्नोस्टिक संदेश: V708 [CWE-758] खतरनाक निर्माण का उपयोग किया जाता है: 'FeaturesMap [Op] = FeaturesMap.size (), जहां' FeaturesMap '' मैप 'वर्ग का है। इससे अपरिभाषित व्यवहार हो सकता है। RISCVCompressInstEmitter.cpp 490

दोषपूर्ण रेखा यह है:

 FeaturesMap[Op] = FeaturesMap.size(); 

यदि Op तत्व नहीं मिला है, तो प्रोग्राम मैप में एक नया तत्व बनाता है और इसे इस मैप में कुल तत्वों को असाइन करता है। आपको अभी नहीं पता है कि नए तत्व को जोड़ने से पहले या बाद में आकार फ़ंक्शन को बुलाया जाएगा या नहीं।

स्निपेट नं। 22 - नहीं। 24: डुप्लिकेट असाइनमेंट

 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- स्टूडियो डायग्नोस्टिक संदेश: 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

स्निपेट नं। 25 - नहीं। 27: अधिक डुप्लिकेट असाइनमेंट

ये डुप्लिकेट असाइनमेंट के थोड़े अलग संस्करणों के साथ सौदा करते हैं।

 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] 'संरेखण' चर को लगातार दो बार मान दिया गया है। शायद यह एक गलती है। चेक लाइनें: 1158, 1160। LoadStoreVectorizer.cpp 1160

यह एक बहुत ही अजीब स्निपेट है, और इसमें संभवतः एक तर्क त्रुटि है। संरेखण चर को पहले शर्त के आधार पर मान असाइन किया जाता है, और फिर इसे एक बार फिर से मान दिया जाता है, लेकिन बिना किसी पूर्व जांच के।

इसी तरह के दोष:

• V519 [CWE-563] 'इफेक्ट्स' वेरिएबल को क्रमिक रूप से दो बार मान दिया गया है। शायद यह एक गलती है। जाँच लाइनें: 152, 165। WebAssemblyRegStackify.cpp 165
• V519 [CWE-563] 'ExpectNoDerefChunk' चर को क्रमिक रूप से दो बार मान दिया गया है। शायद यह एक गलती है। चेक लाइनें: 4970, 4973। SemaType.cpp 4973

स्निपेट नं। 28: हमेशा सही स्थिति

 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 [CWE-571] एक्सप्रेशन 'नेक्स्टबाइट! = 0x90' हमेशा सच होता है। X86DisassemblerDecoder.cpp 379

चेक का कोई मतलब नहीं है। अगलाबाइट वैरिएबल 0x90 के बराबर नहीं है: यह सिर्फ पिछले चेक से तार्किक रूप से अनुसरण करता है। यह कुछ तर्क त्रुटि होनी चाहिए।

स्निपेट नं। 29 - नहीं ....: हमेशा सही / गलत परिस्थितियाँ

एक संपूर्ण स्थिति ( 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 , फ़ंक्शन वापस आ जाएगा।

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

यहाँ एक उदाहरण दिया गया है कि क्यों उन चेतावनियों की जाँच करना उबाऊ है। निम्नलिखित कोड पर चेतावनी जारी करते समय विश्लेषक पूरी तरह से सही है। लेकिन यह अभी भी बग नहीं है।

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

PVS- स्टूडियो डायग्नोस्टिक संदेश: V547 [CWE-570] अभिव्यक्ति '! HasError' हमेशा गलत है। अनवेरप्लीनपेरर.कप 1635

स्निपेट नं। 30: संदिग्ध वापसी

 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 [CWE-670] एक लूप के भीतर बिना शर्त 'वापसी'। R600OptimizeVectorRegisters.cpp 63

यह या तो एक बग या एक विशिष्ट कोडिंग तकनीक है जिसका उद्देश्य साथी प्रोग्रामरों को कुछ विचार बताना है। मेरे लिए यह कुछ भी नहीं है सिवाय इसके कि यह कोड का एक बहुत ही संदिग्ध टुकड़ा है। कृपया ऐसा कोड न लिखें :)।

थकान महसूस हो रही है? ठीक है, यह कुछ चाय या कॉफी बनाने का समय है।

नए डायग्नोस्टिक्स द्वारा पाए गए दोष

मुझे लगता है कि मौजूदा निदान के लिए 30 उदाहरण पर्याप्त हैं। अब देखते हैं कि क्या हम नए निदान के साथ कुछ भी दिलचस्प पा सकते हैं, जो पिछले चेक के बाद जोड़े गए थे। पिछले दो वर्षों में, C ++ विश्लेषक मॉड्यूल को 66 नए निदानों के साथ बढ़ाया गया था।

स्निपेट नं। 31: अगम्य कोड

 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 [CWE-561] अगम्य कोड का पता चला। यह संभव है कि कोई त्रुटि मौजूद हो। निष्पादन

जैसा कि आप देख सकते हैं, यदि कथन की दोनों शाखाएं एक वापसी विवरण के साथ समाप्त होती हैं , जिसका अर्थ है कि CtorDtorsByPriority कंटेनर को कभी भी साफ़ नहीं किया जाएगा।

स्निपेट नं। 32: अगम्य कोड

 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 [CWE-561] अगम्य कोड का पता चला। यह संभव है कि कोई त्रुटि मौजूद हो। LLParser.cpp 835

यह एक दिलचस्प है। पहले इस भाग पर एक नज़र डालें:

 return ParseTypeIdEntry(SummaryID); break; 

इस कोड के बारे में कुछ भी अजीब नहीं लगता है; ब्रेक स्टेटमेंट अनावश्यक है और इसे सुरक्षित रूप से हटाया जा सकता है। लेकिन यह इतना आसान नहीं है।

निम्न पंक्तियों द्वारा चेतावनी को ट्रिगर किया गया है:

 Lex.setIgnoreColonInIdentifiers(false); return false; 

दरअसल, यह कोड अगम्य है। स्विच स्टेटमेंट के सभी केस लेबल एक वापसी के साथ समाप्त होते हैं , और अर्थहीन अकेला ब्रेक अब हानिरहित नहीं दिखता है! क्या होगा यदि शाखाओं में से एक को वापसी के बजाय एक विराम के साथ समाप्त करना था?

स्निपेट नं। 33: सबसे महत्वपूर्ण बिट्स का आकस्मिक समाशोधन

 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 बिट मास्क का आकार पहले ऑपरेंड के आकार से कम है। यह उच्च बिट्स के नुकसान का कारण होगा। RuntimeDyld.cpp 815

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

~ (getStubAlignment () - 1)

~ (8u-1)

0xFFFFFFF8u

ध्यान दें कि DataSize वैरिएबल का प्रकार 64-बिट अहस्ताक्षरित है। तो यह पता चला है कि ऑपरेशन निष्पादित करना DataSize & 0xFFFFFFF8 परिणाम के सभी 32 सबसे महत्वपूर्ण बिट्स को साफ़ करने में परिणाम देगा। मुझे नहीं लगता कि प्रोग्रामर ऐसा चाहता था। शायद उनका मतलब था कि यह DataSize और 0xFFFFFFFFFFFFFFFFFFF8u है।

त्रुटि को ठीक करने के लिए, कोड को इस तरह से फिर से लिखना चाहिए:

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

या इस तरह:

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

स्निपेट नं। 34: खराब स्पष्ट प्रकार का रूपांतरण

 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 [CWE-190] संभावित अतिप्रवाह। 'Num_lts * स्केल' ऑपरेटर के कास्टिंग ऑपरेंड्स पर 'size_t' प्रकार पर विचार करें, परिणाम नहीं। X86ISelowering.h 1577

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

स्निपेट नं। 35: खराब कॉपी-पेस्ट

 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] दो समान कोड टुकड़े पाए गए। शायद, यह एक टाइपो है और 'Op0' के बजाय 'Op1' चर का उपयोग किया जाना चाहिए। InstCombineCompares.cpp 5507

यह नया कूल डायग्नोस्टिक उन स्थितियों का पता लगाता है, जहां कॉपी-पेस्ट का उपयोग करके एक कोड टुकड़ा लिखा जाता है, जिसमें सभी नाम बदले गए हैं।

ध्यान दें कि एक को छोड़कर सभी Op0 दूसरे ब्लॉक में Op1 में बदल गए थे। कोड को शायद इस तरह दिखना चाहिए:

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

स्निपेट नं। 36: चर को मिलाया

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

पीवीएस-स्टूडियो डायग्नोस्टिक संदेश: V1001 [CWE-563] 'मोड' वेरिएबल असाइन किया गया है, लेकिन फ़ंक्शन के अंत तक उपयोग नहीं किया जाता है। SIModeRegister.cpp 48

कक्षा के सदस्यों के लिए फ़ंक्शन तर्क के लिए समान नाम होना बहुत खतरनाक है क्योंकि आप उन्हें मिश्रण करने का जोखिम उठाते हैं। आप यहां जो देख रहे हैं, वह उसी का एक उदाहरण है। निम्नलिखित अभिव्यक्ति व्यर्थ है:

 Mode &= Mask; 

तर्क को बदल दिया जाता है लेकिन उसके बाद इसका उपयोग कभी नहीं किया जाता है। यह स्निपेट शायद इस तरह दिखना चाहिए:

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

स्निपेट नं। 37: चर मिलाया

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

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

यह एक पिछले उदाहरण के समान है। सही संस्करण:

 this->Size += this->EntrySize; 

स्निपेट नं। 38 - नहीं। 47: पॉइंटिंग पॉइंटर चेक करना

हमने कुछ समय पहले 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()); // <= .... } 

पीवीएस-स्टूडियो डायग्नोस्टिक संदेश: V1004 [CWE-476] nullptr के खिलाफ सत्यापित होने के बाद 'Ptr' पॉइंटर का उपयोग बिना सोचे-समझे किया गया। जाँच लाइनें: 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(); // <= .... } 

पीवीएस-स्टूडियो डायग्नोस्टिक संदेश: V1004 [CWE-476] nullptr के खिलाफ सत्यापित होने के बाद 'FD' पॉइंटर का उपयोग अनिश्चित रूप से किया गया था। चेक लाइनें: 3228, 3231। CGDebugInfo.cpp 3231

एफडी पॉइंटर पर ध्यान दें। यह त्रुटि सीधी है, इसलिए इस पर कोई टिप्पणी नहीं की गई है।

एक और यहाँ:

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

पीवीएस-स्टूडियो डायग्नोस्टिक संदेश: V1004 [CWE-476] 'PtrTy' पॉइंटर का उपयोग अशक्त रूप से इस्तेमाल किया गया था क्योंकि इसे nullptr के खिलाफ सत्यापित किया गया था। चेक लाइनें: 960, 965. इंटरलीव्डवॉल्डकॉम्बिनेपासपास। 965

आप उस तरह की त्रुटियों से कैसे बचते हैं? अपने कोड की समीक्षा करते समय बहुत सावधान रहें और इसे नियमित रूप से पीवीएस-स्टूडियो के साथ जांचें।

मुझे नहीं लगता कि हमें इस प्रकार के अन्य उदाहरणों की जांच करनी चाहिए, इसलिए यहां चेतावनी की एक सूची दी गई है:

• V1004 [CWE-476] nullptr के खिलाफ सत्यापित होने के बाद 'Expr' पॉइंटर का उपयोग बेवजह किया गया था। चेक लाइनें: 1049, 1078. DebugInfoMetadata.cpp 1078
• V1004 [CWE-476] नल के खिलाफ सत्यापित होने के बाद 'पीआई' पॉइंटर का उपयोग अनिश्चित रूप से किया गया था। चेक लाइन: 733, 753। LegacyPassManager.cpp 753
• V1004 [CWE-476] nullrr के खिलाफ सत्यापित होने के बाद 'StatepointCall' पॉइंटर का उपयोग गैर-जरूरी तरीके से किया गया था। चेक लाइनें: 4371, 4379. वेरिफायर.कैप 4379
• V1004 [CWE-476] nullptr के खिलाफ सत्यापित होने के बाद 'आरवी' पॉइंटर का उपयोग बेवजह किया गया था। चेक लाइनें: 2263, 2268। TGParser.cpp 2268
• V1004 [CWE-476] nullrr के खिलाफ सत्यापित होने के बाद 'CalleeFn' पॉइंटर का उपयोग बिना सोचे-समझे किया गया। चेक लाइनें: 1081, 1096. सरलीकृत लाइक कॉल। 1096
• V1004 [CWE-476] nullptr के खिलाफ सत्यापित होने के बाद 'TC' पॉइंटर का उपयोग बेवजह किया गया था। चेक लाइनें: 1819, 1824. Driver.cpp 1824

स्निपेट नं। ४ No. - नहीं। 60: महत्वपूर्ण नहीं है लेकिन फिर भी एक दोष (संभावित मेमोरी लीक)

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

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

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

लोकप्रिय समाधान xxx.emplace_back (नया X) लिखना है क्योंकि यह संकलन योग्य है : emplace_back विधि सीधे तर्कों से तत्व का निर्माण करती है और इसलिए, स्पष्ट कंस्ट्रक्टर का उपयोग कर सकती है।

लेकिन वह समाधान सुरक्षित नहीं है। यदि वेक्टर भरा हुआ है, तो मेमोरी फिर से आ जाएगी। यह ऑपरेशन विफल हो सकता है और एक std :: bad_alloc अपवाद उठाते हुए समाप्त हो सकता है। इस स्थिति में, सूचक खो जाएगा और प्रोग्राम निर्मित ऑब्जेक्ट को हटाने में सक्षम नहीं होगा।

एक सुरक्षित समाधान एक unique_ptr बनाना है, जो तब तक पॉइंटर को बनाए रखेगा जब तक कि वेक्टर मेमोरी को पुन: स्थापित करने का प्रयास नहीं करता:

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

C ++ 14 मानक आपको 'std :: make_unique' का उपयोग करने की अनुमति देता है:

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

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

इसलिए, भले ही यह कोड LLVM के लिए खतरनाक नहीं है, मैंने सोचा कि मुझे अभी भी आपको इस बग पैटर्न और इस तथ्य के बारे में बताना चाहिए कि पीवीएस-स्टूडियो अब इसका पता लगा सकता है।

इसी तरह के अन्य मामले:

• V1023 [CWE-460] added emplace_back ’विधि द्वारा is पास’ कंटेनर में मालिक के बिना एक सूचक जोड़ा जाता है। एक अपवाद के मामले में एक स्मृति रिसाव होगा। PassManager.h 546
• V1023 [CWE-460] A pointer without owner is added to the 'AAs' container by the 'emplace_back' method. A memory leak will occur in case of an exception. AliasAnalysis.h 324
• V1023 [CWE-460] A pointer without owner is added to the 'Entries' container by the 'emplace_back' method. A memory leak will occur in case of an exception. DWARFDebugFrame.cpp 519
• V1023 [CWE-460] A pointer without owner is added to the 'AllEdges' container by the 'emplace_back' method. A memory leak will occur in case of an exception. CFGMST.h 268
• V1023 [CWE-460] A pointer without owner is added to the 'VMaps' container by the 'emplace_back' method. A memory leak will occur in case of an exception. SimpleLoopUnswitch.cpp 2012
• V1023 [CWE-460] A pointer without owner is added to the 'Records' container by the 'emplace_back' method. A memory leak will occur in case of an exception. FDRLogBuilder.h 30
• V1023 [CWE-460] A pointer without owner is added to the 'PendingSubmodules' container by the 'emplace_back' method. A memory leak will occur in case of an exception. ModuleMap.cpp 810
• V1023 [CWE-460] A pointer without owner is added to the 'Objects' container by the 'emplace_back' method. A memory leak will occur in case of an exception. DebugMap.cpp 88
• V1023 [CWE-460] A pointer without owner is added to the 'Strategies' container by the 'emplace_back' method. A memory leak will occur in case of an exception. llvm-isel-fuzzer.cpp 60
• V1023 [CWE-460] A pointer without owner is added to the 'Modifiers' container by the 'emplace_back' method. A memory leak will occur in case of an exception. llvm-stress.cpp 685
• V1023 [CWE-460] A pointer without owner is added to the 'Modifiers' container by the 'emplace_back' method. A memory leak will occur in case of an exception. llvm-stress.cpp 686
• V1023 [CWE-460] A pointer without owner is added to the 'Modifiers' container by the 'emplace_back' method. A memory leak will occur in case of an exception. llvm-stress.cpp 688
• V1023 [CWE-460] A pointer without owner is added to the 'Modifiers' container by the 'emplace_back' method. A memory leak will occur in case of an exception. llvm-stress.cpp 689
• V1023 [CWE-460] A pointer without owner is added to the 'Modifiers' container by the 'emplace_back' method. A memory leak will occur in case of an exception. llvm-stress.cpp 690
• V1023 [CWE-460] A pointer without owner is added to the 'Modifiers' container by the 'emplace_back' method. A memory leak will occur in case of an exception. llvm-stress.cpp 691
• V1023 [CWE-460] A pointer without owner is added to the 'Modifiers' container by the 'emplace_back' method. A memory leak will occur in case of an exception. llvm-stress.cpp 692
• V1023 [CWE-460] A pointer without owner is added to the 'Modifiers' container by the 'emplace_back' method. A memory leak will occur in case of an exception. llvm-stress.cpp 693
• V1023 [CWE-460] A pointer without owner is added to the 'Modifiers' container by the 'emplace_back' method. A memory leak will occur in case of an exception. llvm-stress.cpp 694
• V1023 [CWE-460] A pointer without owner is added to the 'Operands' container by the 'emplace_back' method. A memory leak will occur in case of an exception. GlobalISelEmitter.cpp 1911
• V1023 [CWE-460] A pointer without owner is added to the 'Stash' container by the 'emplace_back' method. A memory leak will occur in case of an exception. GlobalISelEmitter.cpp 2100
• V1023 [CWE-460] A pointer without owner is added to the 'Matchers' container by the 'emplace_back' method. A memory leak will occur in case of an exception. GlobalISelEmitter.cpp 2702

निष्कर्ष

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

मुझे आशा है कि आपको यह लेख पढ़ने में मज़ा आया और इसने आपको अपने लिए PVS-Studio विश्लेषक की कोशिश करने के लिए प्रोत्साहित किया। विश्लेषक डाउनलोड करने और परीक्षण कुंजी प्राप्त करने के

लिए इस पृष्ठ पर जाएं ।

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

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