👩🏿‍🌾 🏝️ 🏇 PVS-Studio विश्लेषक का उपयोग करके LLVM 8 में बग का पता लगाएं 🏵️ 🤰🏾 👩🏿‍🎤

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

लेख लिखा जाना

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

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

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

इसके लिए, मैं हमेशा आत्मा में कुछ उत्तर देना चाहता हूं:

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

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

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

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

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

जैसा कि पहले ही उल्लेख किया गया है, लगभग दो साल पहले, एलएलवीएम परियोजना को एक बार फिर से सत्यापित किया गया था, और जो त्रुटियां मिली थीं, उन्हें ठीक किया गया था। अब इस लेख में त्रुटियों का एक नया भाग प्रस्तुत किया जाएगा। नए कीड़े क्यों पाए गए? इसके 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 .... }

PVS-Studio चेतावनी: 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-Studio चेतावनी: 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-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))

वैसे, टर्नरी ऑपरेटर बहुत खतरनाक है और तार्किक त्रुटियों को भड़काता है। इसके साथ बहुत सावधान रहें और कोष्ठक डालने के लिए लालच न करें। मैंने इस विषय पर यहां "अध्याय संचालक से डरें ?: और इसे कोष्ठक में संलग्न करें" अध्याय में अधिक विस्तार से विचार किया।

फ्रैगमेंट एन 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-Studio चेतावनी: V522 [CWE-476] अशक्त सूचक 'LHS' की ड्रीफरिंग होती है। TGParser.cpp 2152

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

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

RHS पॉइंटर को संसाधित करने में एक समान त्रुटि नीचे दिए गए कोड में बनाई गई है: V522 [CWE-476] अशक्त सूचक 'RHS' की डेरेफेरिंग हो सकती है। TGParser.cpp 2186

Fragment 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] अशक्त सूचक 'ProgClone' की Dereferencing हो सकती है। दुर्व्यवहार .पीसी 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) {

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

ऐसा लगता है कि हम त्रुटियों की बहुत प्रसिद्ध समानता से मिले थे! एक गलती दूसरे का अपमान करती है :)।

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

फिर से वही स्थिति। शुरुआत में, ऑब्जेक्ट की सामग्री को स्थानांतरित किया जाता है, और फिर इसका उपयोग किया जाता है जैसे कि कुछ भी नहीं हुआ था। मैं इस स्थिति को प्रोग्राम कोड में तेजी से देखता हूं, आंदोलन के शब्दार्थ सी ++ में दिखाई देने के बाद। इसके लिए मुझे 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] अशक्त सूचक 'प्रकार' की ड्राफ्टिंग हो सकती है। प्रिटीफंक्शनडॉपर। 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()); .... }

PVS-Studio चेतावनी: V522 [CWE-476] अशक्त सूचक 'Ty' की Dereferencing हो सकती है। 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; }

PVS-Studio चेतावनी: 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; .... }

PVS-Studio चेतावनी: V622 [CWE-478] 'स्विच' स्टेटमेंट का निरीक्षण करने पर विचार करें। यह संभव है कि पहला 'केस' ऑपरेटर गायब हो। SystemZAsmParser.cpp 652

शुरुआत में एक बहुत ही संदिग्ध ब्रेक स्टेटमेंट है। क्या आप यहां कुछ और लिखना भूल गए हैं?

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

जब GetTTI फ़ंक्शन कहा जाता है, तो शुरुआत में केली पॉइंटर को बंद कर दिया जाता है ।

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

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

लेकिन बहुत देर हो चुकी है ...

Fragment 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] nullptr के खिलाफ सत्यापित होने से पहले 'CalleeFn' पॉइंटर का उपयोग किया गया था। चेक लाइन्स: 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()); // <= .... }

PVS-Studio चेतावनी: V595 [CWE-476] null के खिलाफ सत्यापित होने से पहले 'ND' पॉइंटर का उपयोग किया गया था। जाँच लाइनें: 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 नंबर के साथ चेतावनी का अध्ययन करने में कोई दिलचस्पी नहीं थी। इसलिए मुझे नहीं पता कि क्या यहां सूचीबद्ध लोगों के अलावा कोई समान त्रुटियां हैं। सबसे अधिक संभावना है।

Fragment 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' अभिव्यक्ति का निरीक्षण करने पर विचार करें। 64-बिट प्रकार के बाद के विस्तार के साथ 32-बिट मूल्य का बिट शिफ्टिंग। 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' अभिव्यक्ति का निरीक्षण करने पर विचार करें। 64-बिट प्रकार के बाद के विस्तार के साथ 32-बिट मूल्य का बिट शिफ्टिंग। 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

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

Fragment 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 ()' अभिव्यक्ति का निरीक्षण करने पर विचार करें। प्रतीक। 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

संयोग से, + = ऑपरेटर के बजाय + ऑपरेटर का उपयोग किया जाता है। परिणाम अर्थहीन डिजाइन है।

Fragment 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 '' मानचित्र 'वर्ग का है। इससे अपरिभाषित व्यवहार हो सकता है। RISCVCompressInstEmitter.cpp 490

समस्या रेखा:

 FeaturesMap[Op] = FeaturesMap.size();

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

फ्रैगमेंट एन 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-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] 'संरेखण' चर को लगातार दो बार मान दिया गया है। शायद यह एक गलती है। चेक लाइनें: 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 == 0 %e। 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-Studio चेतावनी: 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 [CWE-670] एक लूप के भीतर बिना शर्त 'वापसी'। R600OptimizeVectorRegisters.cpp 63

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

क्या आप थके हुए हैं? फिर चाय या कॉफी बनाने का समय।

नए निदान द्वारा दोषों का पता लगाया गया

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

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

जैसा कि आप देख सकते हैं, यदि विवरण की दोनों शाखाएं रिटर्न स्टेटमेंट पर कॉल के साथ समाप्त होती हैं। तदनुसार, 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)

0xFFFFFFF8u

अब ध्यान दें कि DataSize वैरिएबल में 64-बिट अहस्ताक्षरित प्रकार है। यह पता चला है कि ऑपरेशन के दौरान DataSize & 0xFFFFFFF88, सभी बत्तीस उच्च-स्तरीय बिट्स रीसेट हो जाएंगे। सबसे अधिक संभावना है, यह वह नहीं है जो प्रोग्रामर चाहता था। मुझे संदेह है कि वह गणना करना चाहता था: DataSize & 0xFFFFFFFFFFFFFFFFFFF8u।

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

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

या तो:

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

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

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

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

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

नोट दूसरे खंड परिवर्तन में है कि Op0 पर OP1 । लेकिन एक जगह पर उन्होंने इसे ठीक नहीं किया। सबसे अधिक संभावना है, इसे इस तरह लिखा जाना चाहिए था:

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

Fragment N36: चर में भ्रम

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

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

फ़ंक्शन के तर्क को कक्षा के सदस्यों के समान नाम देना बहुत खतरनाक है। भ्रमित होने में बहुत आसान है। हमारे सामने सिर्फ एक ऐसा मामला है। इस अभिव्यक्ति का कोई मतलब नहीं है:

 Mode &= Mask;

फ़ंक्शन का तर्क बदलता है। और वह यह है। इस तर्क का अब उपयोग नहीं किया जाता है। सबसे अधिक संभावना है, यह इस तरह से लिखना आवश्यक था:

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

Fragment N37: चर में भ्रम

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

PVS-Studio चेतावनी: V1001 [CWE-563] 'आकार' चर असाइन किया गया है, लेकिन फ़ंक्शन के अंत तक उपयोग नहीं किया जाता है। Object.cpp 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()); // <= .... }

PVS-Studio चेतावनी: 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(); // <= .... }

PVS-Studio चेतावनी: V1004 [CWE-476] nullptr के खिलाफ सत्यापित होने के बाद 'FD' पॉइंटर का उपयोग बेवजह किया गया था। जाँच लाइनें: 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] nullptr के खिलाफ सत्यापित होने के बाद 'PtrTy' पॉइंटर का उपयोग अनिश्चित रूप से किया गया था। चेक लाइन: 960, 965. इंटरलीव्डवॉडकॉम्बिनेपपास। 965

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

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

V1004 [CWE-476] nullptr के खिलाफ सत्यापित होने के बाद 'Expr' पॉइंटर का उपयोग बेवजह किया गया था। चेक लाइनें: 1049, 1078. DebugInfoMetadata.cpp 1078
V1004 [CWE-476] नल के खिलाफ सत्यापित होने के बाद 'पीआई' पॉइंटर का उपयोग अनिश्चित रूप से किया गया था। चेक लाइन: 733, 753। LegacyPassManager.cpp 753
V1004 [CWE-476] The 'StatepointCall' pointer was used unsafely after it was verified against nullptr. Check lines: 4371, 4379. Verifier.cpp 4379
V1004 [CWE-476] The 'RV' pointer was used unsafely after it was verified against nullptr. Check lines: 2263, 2268. TGParser.cpp 2268
V1004 [CWE-476] The 'CalleeFn' pointer was used unsafely after it was verified against nullptr. Check lines: 1081, 1096. SimplifyLibCalls.cpp 1096
V1004 [CWE-476] The 'TC' pointer was used unsafely after it was verified against nullptr. Check lines: 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 :: वेक्टर <std :: unique_ptr <X >> आप केवल xxx.push_back (नया X) नहीं लिख सकते हैं , क्योंकि X * से std में कोई अंतर्निहित रूपांतरण नहीं है : : unique_ptr <X> ।

एक सामान्य समाधान 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 के लिए एक व्यावहारिक खतरा पैदा नहीं करता है, मैंने इस त्रुटि पैटर्न के बारे में बात करना उपयोगी पाया और पीवीएस-स्टूडियो विश्लेषक ने इसका पता लगाना सीखा।

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

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 चेतावनियाँ लिखीं, जिसके बाद मैं रुक गया। क्या कोई अन्य दोष है जो पीवीएस-स्टूडियो विश्लेषक एलएलवीएम में पता लगाता है? हाँ है। हालाँकि, जब मैंने लेख के लिए कोड स्निपेट लिखे, तो यह देर शाम, या बल्कि, रात भी था, और मैंने फैसला किया कि इसे राउंड ऑफ करने का समय था।

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

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

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

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

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

PVS-Studio विश्लेषक का उपयोग करके LLVM 8 में बग का पता लगाएं

लेख लिखा जाना

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

निदान द्वारा पहचाने गए दोष जो 2 साल पहले मौजूद थे

नए निदान द्वारा दोषों का पता लगाया गया

निष्कर्ष

More articles: