מציאת באגים ב-LLVM 8 באמצעות מנתח PVS-Studio

יותר משנתיים חלפו מאז בדיקת הקוד האחרונה של פרויקט LLVM באמצעות מנתח ה-PVS-Studio שלנו. בואו נוודא שהנתח PVS-Studio הוא עדיין כלי מוביל לזיהוי שגיאות ופגיעויות פוטנציאליות. לשם כך, נבדוק ונמצא שגיאות חדשות במהדורת LLVM 8.0.0.

מאמר שייכתב

למען האמת, לא רציתי לכתוב את המאמר הזה. לא מעניין לכתוב על פרויקט שכבר בדקנו כמה פעמים (1, 2, 3). עדיף לכתוב על משהו חדש, אבל אין לי ברירה.

בכל פעם שמתפרסמת או מתעדכנת גרסה חדשה של LLVM מנתח סטטי קלאנג, אנו מקבלים בדואר שלנו שאלות מהסוג הבא:

תראה, הגרסה החדשה של Clang Static Analyzer למדה למצוא שגיאות חדשות! נראה לי שהרלוונטיות של השימוש ב-PVS-Studio הולכת ופוחתת. קלאנג מוצא יותר שגיאות מבעבר ומשיג את היכולות של PVS-Studio. מה אתה חושב על זה?

על זה אני תמיד רוצה לענות משהו כמו:

גם אנחנו לא יושבים בחוסר מעש! שיפרנו משמעותית את היכולות של מנתח ה-PVS-Studio. אז אל דאגה, אנחנו ממשיכים להוביל כמו פעם.

למרבה הצער, זו תשובה גרועה. אין בו הוכחות. וזו הסיבה שאני כותב את המאמר הזה עכשיו. אז, פרויקט LLVM נבדק שוב ונמצאו בו מגוון שגיאות. כעת אדגים את אלה שנראו לי מעניינים. Clang Static Analyzer לא יכול למצוא את השגיאות הללו (או שזה מאוד לא נוח לעשות זאת בעזרתו). אבל אנחנו יכולים. יתר על כן, מצאתי ורשמתי את כל השגיאות הללו בערב אחד.

אבל כתיבת המאמר ארכה מספר שבועות. פשוט לא הצלחתי להכניס את כל זה לטקסט :).

אגב, אם אתה מעוניין באילו טכנולוגיות נעשה שימוש בניתוח PVS-Studio לזיהוי שגיאות ופגיעויות פוטנציאליות, אז אני מציע להכיר את זה הערה.

אבחון חדש וישן

כפי שכבר צוין, לפני כשנתיים נבדק שוב פרויקט LLVM, והטעויות שנמצאו תוקנו. כעת מאמר זה יציג קבוצה חדשה של שגיאות. מדוע נמצאו באגים חדשים? יש לכך 3 סיבות:

1. פרויקט LLVM מתפתח, משנה קוד ישן ומוסיף קוד חדש. באופן טבעי, יש שגיאות חדשות בקוד המשתנה והכתוב. זה מדגים בבירור שיש להשתמש בניתוח סטטי באופן קבוע, ולא מדי פעם. המאמרים שלנו מציגים היטב את היכולות של מנתח PVS-Studio, אבל אין לזה שום קשר לשיפור איכות הקוד והפחתת עלות תיקון השגיאות. השתמש במנתח קוד סטטי באופן קבוע!
2. אנו מסיימים ומשפרים את האבחון הקיים. לכן, המנתח יכול לזהות שגיאות שלא הבחין בהן במהלך סריקות קודמות.
3. ב-PVS-Studio הופיעו אבחונים חדשים שלא היו קיימים לפני שנתיים. החלטתי להדגיש אותם בסעיף נפרד כדי להראות בבירור את הפיתוח של PVS-Studio.

ליקויים שזוהו על ידי אבחון שהיו קיימים לפני שנתיים

קטע 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.". בבדיקה השנייה, ברור שהם רצו לכתוב משהו אחר, אבל שכחו לתקן את הטקסט שהועתק.

קטע N2: שגיאת הקלדה

enum CXNameRefFlags {
  CXNameRange_WantQualifier = 0x1,
  CXNameRange_WantTemplateArgs = 0x2,
  CXNameRange_WantSinglePiece = 0x4
};

void AnnotateTokensWorker::HandlePostPonedChildCursor(
    CXCursor Cursor, unsigned StartTokenIndex) {
  const auto flags = CXNameRange_WantQualifier | CXNameRange_WantQualifier;
  ....
}

אזהרה PVS-Studio: V501 ישנם תתי ביטויים זהים 'CXNameRange_WantQualifier' משמאל ומימין ל'|' מַפעִיל. CIndex.cpp 7245

עקב שגיאת הקלדה, אותו קבוע בשם משמש פעמיים CXNameRange_WantQualifier.

קטע N3: בלבול עם קדימות מפעיל

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

אזהרת PVS-Studio: V502 [CWE-783] אולי המפעיל '?:' פועל בצורה שונה ממה שהיה צפוי. לאופרטור '?:' יש עדיפות נמוכה יותר מאופרטור '=='. PPCTargetTransformInfo.cpp 404

לדעתי זו טעות מאוד יפה. כן, אני יודע שיש לי רעיונות מוזרים על יופי :).

עכשיו, לפי סדרי עדיפויות של המפעיל, הביטוי מוערך באופן הבא:

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

מנקודת מבט מעשית, תנאי כזה אינו הגיוני, מכיוון שניתן לצמצם אותו ל:

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

זו טעות ברורה. סביר להניח שהם רצו להשוות 0/1 עם משתנה מדד. כדי לתקן את הקוד עליך להוסיף סוגריים מסביב לאופרטור הטרינרי:

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

אגב, המפעיל השלישי מסוכן מאוד ומעורר טעויות לוגיות. היזהר מאוד עם זה ואל תהיה חמדן בסוגריים. הסתכלתי על הנושא הזה ביתר פירוט כאן, בפרק "היזהרו מה-?: מפעיל וסגרו אותו בסוגריים."

קטע N4, N5: מצביע אפס

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

אזהרת PVS-Studio: V522 [CWE-476] ניתוק מצביע האפס 'LHS' עשוי להתבצע. TGParser.cpp 2152

אם המצביע LHS בטל, יש לתת אזהרה. עם זאת, במקום זאת, אותו מצביע ריק יקבל את ההפניה: LHS->getAsString().

זהו מצב אופייני מאוד כאשר שגיאה מוסתרת במטפל בשגיאות, מכיוון שאף אחד לא בודק אותן. מנתחים סטטיים בודקים את כל הקוד שניתן להגיע אליו, לא משנה באיזו תדירות נעשה בו שימוש. זוהי דוגמה טובה מאוד לאופן שבו ניתוח סטטי משלים טכניקות אחרות של בדיקות והגנה מפני שגיאות.

שגיאת טיפול דומה במצביע RHS מותר בקוד ממש למטה: V522 [CWE-476] ייתכן שיתרחש ניתוק מצביע האפס 'RHS'. TGParser.cpp 2186

קטע N6: שימוש במצביע לאחר תנועה

static Expected<bool>
ExtractBlocks(....)
{
  ....
  std::unique_ptr<Module> ProgClone = CloneModule(BD.getProgram(), VMap);
  ....
  BD.setNewProgram(std::move(ProgClone));                                // <=
  MiscompiledFunctions.clear();

  for (unsigned i = 0, e = MisCompFunctions.size(); i != e; ++i) {
    Function *NewF = ProgClone->getFunction(MisCompFunctions[i].first);  // <=
    assert(NewF && "Function not found??");
    MiscompiledFunctions.push_back(NewF);
  }
  ....
}

אזהרת PVS-Studio: V522 [CWE-476] ייתכן שיתרחש ניתוק מצביע האפס 'ProgClone'. Miscompilation.cpp 601

בהתחלה מצביע חכם ProgClone מפסיק להחזיק בחפץ:

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

למעשה, עכשיו ProgClone הוא מצביע ריק. לכן, הפניית מצביע אפס צריכה להתרחש ממש מתחת:

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

אבל, במציאות, זה לא יקרה! שימו לב שהלולאה לא מבוצעת בפועל.

בתחילת המיכל פונקציות שגויות מְבוּעָר:

MiscompiledFunctions.clear();

לאחר מכן, הגודל של מיכל זה משמש במצב הלולאה:

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

קל לראות שהלולאה לא מתחילה. אני חושב שזה גם באג ויש לכתוב את הקוד אחרת.

נראה שנתקלנו באותו שוויון מפורסם של טעויות! טעות אחת מחפה על אחרת :).

קטע N7: שימוש במצביע לאחר תנועה

static Expected<bool> TestOptimizer(BugDriver &BD, std::unique_ptr<Module> Test,
                                    std::unique_ptr<Module> Safe) {
  outs() << "  Optimizing functions being tested: ";
  std::unique_ptr<Module> Optimized =
      BD.runPassesOn(Test.get(), BD.getPassesToRun());
  if (!Optimized) {
    errs() << " Error running this sequence of passes"
           << " on the input program!n";
    BD.setNewProgram(std::move(Test));                       // <=
    BD.EmitProgressBitcode(*Test, "pass-error", false);      // <=
    if (Error E = BD.debugOptimizerCrash())
      return std::move(E);
    return false;
  }
  ....
}

אזהרת PVS-Studio: V522 [CWE-476] עשויה להתבצע ביטול הפניה של מצביע האפס 'בדיקה'. Miscompilation.cpp 709

שוב אותו מצב. בהתחלה מזיזים את תוכן החפץ, ואז משתמשים בו כאילו כלום לא קרה. אני רואה את המצב הזה לעתים קרובות יותר ויותר בקוד התוכנית לאחר שסמנטיקה של תנועה הופיעה ב-C++. זו הסיבה שאני אוהב את שפת C++! יש עוד ועוד דרכים חדשות לירות את הרגל שלך. לנתח PVS-Studio תמיד תהיה עבודה :).

קטע N8: מצביע אפס

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

אזהרת PVS-Studio: V522 [CWE-476] עשויה להתבצע ניתוק מצביע האפס 'Type'. PrettyFunctionDumper.cpp 233

בנוסף למטפלי שגיאות, פונקציות תדפיס איתור באגים בדרך כלל אינן נבדקות. יש לנו בדיוק מקרה כזה לפנינו. הפונקציה ממתינה למשתמש, שבמקום לפתור את הבעיות שלו, ייאלץ לתקן אותה.

נכון:

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

קטע N9: מצביע אפס

void SearchableTableEmitter::collectTableEntries(
    GenericTable &Table, const std::vector<Record *> &Items) {
  ....
  RecTy *Ty = resolveTypes(Field.RecType, TI->getType());
  if (!Ty)                                                              // <=
    PrintFatalError(Twine("Field '") + Field.Name + "' of table '" +
                    Table.Name + "' has incompatible type: " +
                    Ty->getAsString() + " vs. " +                       // <=
                    TI->getType()->getAsString());
   ....
}

אזהרת PVS-Studio: V522 [CWE-476] ניתוק מצביע האפס 'Ty' עשוי להתבצע. SearchableTableEmitter.cpp 614

אני חושב שהכל ברור ולא דורש הסבר.

קטע N10: שגיאת הקלדה

bool FormatTokenLexer::tryMergeCSharpNullConditionals() {
  ....
  auto &Identifier = *(Tokens.end() - 2);
  auto &Question = *(Tokens.end() - 1);
  ....
  Identifier->ColumnWidth += Question->ColumnWidth;
  Identifier->Type = Identifier->Type;                    // <=
  Tokens.erase(Tokens.end() - 1);
  return true;
}

אזהרת PVS-Studio: V570 המשתנה 'מזהה->סוג' מוקצה לעצמו. FormatTokenLexer.cpp 249

אין טעם להקצות משתנה לעצמו. סביר להניח שהם רצו לכתוב:

Identifier->Type = Question->Type;

קטע N11: שבירה חשודה

void SystemZOperand::print(raw_ostream &OS) const {
  switch (Kind) {
    break;
  case KindToken:
    OS << "Token:" << getToken();
    break;
  case KindReg:
    OS << "Reg:" << SystemZInstPrinter::getRegisterName(getReg());
    break;
  ....
}

אזהרת PVS-Studio: V622 [CWE-478] שקול לבדוק את הצהרת 'החלפה'. ייתכן שהמפעיל הראשון של 'המקרה' חסר. SystemZAsmParser.cpp 652

יש מפעיל מאוד חשוד בהתחלה לשבור. שכחת לכתוב פה משהו אחר?

קטע N12: בדיקת מצביע לאחר הרחקה

InlineCost AMDGPUInliner::getInlineCost(CallSite CS) {
  Function *Callee = CS.getCalledFunction();
  Function *Caller = CS.getCaller();
  TargetTransformInfo &TTI = TTIWP->getTTI(*Callee);

  if (!Callee || Callee->isDeclaration())
    return llvm::InlineCost::getNever("undefined callee");
  ....
}

אזהרת PVS-Studio: V595 [CWE-476] המצביע 'Callee' נוצל לפני שהוא אומת כנגד nullptr. קווי בדיקה: 172, 174. AMDGPUInline.cpp 172

המדד קלי בהתחלה מורחקת בזמן קריאת הפונקציה getTTI.

ואז מתברר שצריך לבדוק את המצביע הזה לשוויון nullptr:

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

אבל זה מאוחר מדי…

קטע N13 - N...: בדיקת מצביע לאחר הרחקה

המצב שנדון בקטע הקוד הקודם אינו ייחודי. זה מופיע כאן:

static Value *optimizeDoubleFP(CallInst *CI, IRBuilder<> &B,
                               bool isBinary, bool isPrecise = false) {
  ....
  Function *CalleeFn = CI->getCalledFunction();
  StringRef CalleeNm = CalleeFn->getName();                 // <=
  AttributeList CalleeAt = CalleeFn->getAttributes();
  if (CalleeFn && !CalleeFn->isIntrinsic()) {               // <=
  ....
}

אזהרת PVS-Studio: V595 [CWE-476] המצביע 'CalleeFn' נוצל לפני שהוא אומת כנגד nullptr. קווי בדיקה: 1079, 1081. SimplifyLibCalls.cpp 1079

והנה:

void Sema::InstantiateAttrs(const MultiLevelTemplateArgumentList &TemplateArgs,
                            const Decl *Tmpl, Decl *New,
                            LateInstantiatedAttrVec *LateAttrs,
                            LocalInstantiationScope *OuterMostScope) {
  ....
  NamedDecl *ND = dyn_cast<NamedDecl>(New);
  CXXRecordDecl *ThisContext =
    dyn_cast_or_null<CXXRecordDecl>(ND->getDeclContext());         // <=
  CXXThisScopeRAII ThisScope(*this, ThisContext, Qualifiers(),
                             ND && ND->isCXXInstanceMember());     // <=
  ....
}

אזהרת PVS-Studio: V595 [CWE-476] נעשה שימוש במצביע 'ND' לפני שהוא אומת כנגד nullptr. קווי בדיקה: 532, 534. SemaTemplateInstantiateDecl.cpp 532

והנה:

• V595 [CWE-476] נעשה שימוש במצביע 'U' לפני שהוא אומת כנגד nullptr. קווי בדיקה: 404, 407. DWARFormValue.cpp 404
• V595 [CWE-476] המצביע 'ND' נוצל לפני שהוא אומת כנגד nullptr. קווי בדיקה: 2149, 2151. SemaTemplateInstantiate.cpp 2149

ואז נעשיתי לא מעוניין ללמוד את האזהרות עם מספר V595. אז אני לא יודע אם יש עוד שגיאות דומות מלבד אלה הרשומות כאן. סביר להניח שיש.

קטע N17, N18: תזוזה חשודה

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

אזהרת PVS-Studio: V629 [CWE-190] שקול לבדוק את הביטוי '~(גודל - 1) << 1'. הסטת סיביות של ערך 32 סיביות עם הרחבה לאחר מכן לסוג 64 סיביות. AArch64AddressingModes.h 260

יכול להיות שזה לא באג והקוד עובד בדיוק כמתוכנן. אבל ברור שזה מקום מאוד חשוד וצריך לבדוק אותו.

נגיד המשתנה מידה שווה ל-16, ואז מחבר הקוד תכנן לקבל אותו במשתנה NImms ערך:

1111111111111111111111111111111111111111111111111111111111100000

עם זאת, במציאות התוצאה תהיה:

0000000000000000000000000000000011111111111111111111111111100000

העובדה היא שכל החישובים מתרחשים באמצעות סוג 32 סיביות ללא סימן. ורק אז, סוג 32 סיביות לא חתום זה יורחב באופן מרומז uint64_t. במקרה זה, הביטים המשמעותיים ביותר יהיו אפס.

אתה יכול לתקן את המצב כך:

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

מצב דומה: V629 [CWE-190] שקול לבדוק את הביטוי 'Immr << 6'. הסטת סיביות של ערך 32 סיביות עם הרחבה לאחר מכן לסוג 64 סיביות. AArch64AddressingModes.h 269

קטע N19: מילת מפתח חסרה אחר?

void AMDGPUAsmParser::cvtDPP(MCInst &Inst, const OperandVector &Operands) {
  ....
  if (Op.isReg() && Op.Reg.RegNo == AMDGPU::VCC) {
    // VOP2b (v_add_u32, v_sub_u32 ...) dpp use "vcc" token.
    // Skip it.
    continue;
  } if (isRegOrImmWithInputMods(Desc, Inst.getNumOperands())) {    // <=
    Op.addRegWithFPInputModsOperands(Inst, 2);
  } else if (Op.isDPPCtrl()) {
    Op.addImmOperands(Inst, 1);
  } else if (Op.isImm()) {
    // Handle optional arguments
    OptionalIdx[Op.getImmTy()] = I;
  } else {
    llvm_unreachable("Invalid operand type");
  }
  ....
}

אזהרת PVS-Studio: V646 [CWE-670] שקול לבדוק את ההיגיון של היישום. ייתכן שמילת המפתח 'אחר' חסרה. AMDGPUAsmParser.cpp 5655

אין כאן טעות. מאז הבלוק אז של הראשון if מסתיים עם להמשיך, אז זה לא משנה, יש מילת מפתח אחר או שלא. בכל מקרה הקוד יעבוד אותו הדבר. עדיין מתגעגע אחר הופך את הקוד ליותר לא ברור ומסוכן. אם בעתיד להמשיך נעלם, הקוד יתחיל לעבוד אחרת לגמרי. לדעתי עדיף להוסיף אחר.

קטע N20: ארבע שגיאות הקלדה מאותו סוג

LLVM_DUMP_METHOD void Symbol::dump(raw_ostream &OS) const {
  std::string Result;
  if (isUndefined())
    Result += "(undef) ";
  if (isWeakDefined())
    Result += "(weak-def) ";
  if (isWeakReferenced())
    Result += "(weak-ref) ";
  if (isThreadLocalValue())
    Result += "(tlv) ";
  switch (Kind) {
  case SymbolKind::GlobalSymbol:
    Result + Name.str();                        // <=
    break;
  case SymbolKind::ObjectiveCClass:
    Result + "(ObjC Class) " + Name.str();      // <=
    break;
  case SymbolKind::ObjectiveCClassEHType:
    Result + "(ObjC Class EH) " + Name.str();   // <=
    break;
  case SymbolKind::ObjectiveCInstanceVariable:
    Result + "(ObjC IVar) " + Name.str();       // <=
    break;
  }
  OS << Result;
}

אזהרות PVS-Studio:

• V655 [CWE-480] המחרוזות היו משורשרות אך אינן בשימוש. שקול לבדוק את הביטוי 'Result + Name.str()'. Symbol.cpp 32
• V655 [CWE-480] המחרוזות היו משורשרות אך אינן בשימוש. שקול לבדוק את הביטוי 'Result + "(ObjC Class)" + Name.str()'. Symbol.cpp 35
• V655 [CWE-480] המחרוזות היו משורשרות אך אינן בשימוש. שקול לבדוק את הביטוי 'Result + "(ObjC Class EH) " + Name.str()'. Symbol.cpp 38
• V655 [CWE-480] המחרוזות היו משורשרות אך אינן בשימוש. שקול לבדוק את הביטוי 'Result + "(ObjC IVar)" + Name.str()'. Symbol.cpp 41

במקרה, האופרטור + משמש במקום האופרטור +=. התוצאה היא עיצובים חסרי משמעות.

קטע N21: התנהגות לא מוגדרת

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

    SmallVector<StringRef, 4> Ops;
    SplitString(AsmCondString, Ops, ",");
    assert(!Ops.empty() && "AssemblerCondString cannot be empty");

    for (auto &Op : Ops) {
      assert(!Op.empty() && "Empty operator");
      if (FeaturesMap.find(Op) == FeaturesMap.end())
        FeaturesMap[Op] = FeaturesMap.size();
    }
  }
}

נסה למצוא את הקוד המסוכן בעצמך. וזו תמונה להסיח את תשומת הלב כדי לא להסתכל מיד על התשובה:

אזהרת PVS-Studio: V708 [CWE-758] נעשה שימוש בבנייה מסוכנת: 'FeaturesMap[Op] = FeaturesMap.size()', כאשר 'FeaturesMap' הוא במחלקת 'map'. זה עלול להוביל להתנהגות לא מוגדרת. RISCVCompressInstEmitter.cpp 490

שורת הבעיה:

FeaturesMap[Op] = FeaturesMap.size();

אם אלמנט Op לא נמצא, אז נוצר אלמנט חדש במפה וכתוב שם מספר האלמנטים במפה זו. פשוט לא ידוע אם הפונקציה תיקרא גודל לפני או אחרי הוספת רכיב חדש.

קטע N22-N24: מטלות חוזרות

Error MachOObjectFile::checkSymbolTable() const {
  ....
  } else {
    MachO::nlist STE = getSymbolTableEntry(SymDRI);
    NType = STE.n_type;                              // <=
    NType = STE.n_type;                              // <=
    NSect = STE.n_sect;
    NDesc = STE.n_desc;
    NStrx = STE.n_strx;
    NValue = STE.n_value;
  }
  ....
}

אזהרת PVS-Studio: V519 [CWE-563] למשתנה 'NType' מוקצים ערכים פעמיים ברציפות. אולי זו טעות. קווי בדיקה: 1663, 1664. MachOObjectFile.cpp 1664

אני לא חושב שיש כאן טעות אמיתית. פשוט משימה חוזרת מיותרת. אבל עדיין טעות.

באופן דומה:

• V519 [CWE-563] למשתנה 'B.NDesc' מוקצים ערכים פעמיים ברציפות. אולי זו טעות. קווי בדיקה: 1488, 1489. llvm-nm.cpp 1489
• V519 [CWE-563] למשתנה מוקצים ערכים פעמיים ברציפות. אולי זו טעות. קווי בדיקה: 59, 61. coff2yaml.cpp 61

קטע N25-N27: עוד הקצאות מחדש

עכשיו בואו נסתכל על גרסה קצת שונה של שיבוץ מחדש.

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

אזהרת PVS-Studio: V519 [CWE-563] למשתנה 'יישור' מוקצים ערכים פעמיים ברציפות. אולי זו טעות. קווי בדיקה: 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;
  }
  ....
}

אזהרת PVS-Studio: V547 [CWE-571] הביטוי 'nextByte != 0x90' הוא תמיד נכון. X86DisassemblerDecoder.cpp 379

בדיקה לא הגיונית. מִשְׁתַנֶה nextByte תמיד לא שווה לערך 0x90, העולה מהבדיקה הקודמת. זו איזושהי טעות לוגית.

קטע N29 - N...: תנאים נכונים/שקריים תמיד

המנתח מוציא אזהרות רבות שהמצב כולו (V547) או חלק ממנו (V560) תמיד נכון או לא נכון. לעתים קרובות אלה לא שגיאות אמיתיות, אלא פשוט קוד מרושל, תוצאה של הרחבת מאקרו וכדומה. עם זאת, הגיוני להסתכל על כל האזהרות הללו, שכן שגיאות לוגיות אמיתיות מתרחשות מעת לעת. לדוגמה, קטע הקוד הזה חשוד:

static DecodeStatus DecodeGPRPairRegisterClass(MCInst &Inst, unsigned RegNo,
                                   uint64_t Address, const void *Decoder) {
  DecodeStatus S = MCDisassembler::Success;

  if (RegNo > 13)
    return MCDisassembler::Fail;

  if ((RegNo & 1) || RegNo == 0xe)
     S = MCDisassembler::SoftFail;
  ....
}

אזהרת PVS-Studio: V560 [CWE-570] חלק מהביטוי המותנה הוא תמיד שקר: RegNo == 0xe. ARMDisassembler.cpp 939

הקבוע 0xE הוא הערך 14 בעשרוני. בְּדִיקָה RegNo == 0xe לא הגיוני כי אם RegNo > 13, אז הפונקציה תשלים את ביצועה.

היו אזהרות רבות אחרות עם מזהי V547 ו-V560, אבל כמו עם V595, לא הייתי מעוניין ללמוד את האזהרות הללו. כבר היה ברור שיש לי מספיק חומר כדי לכתוב מאמר :). לכן, לא ידוע כמה שגיאות מסוג זה ניתן לזהות ב-LLVM באמצעות PVS-Studio.

אני אתן לך דוגמה מדוע לימוד הטריגרים הללו משעמם. המנתח צודק בהחלט בהנפקת אזהרה עבור הקוד הבא. אבל זו לא טעות.

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

אזהרת PVS-Studio: V547 [CWE-570] ביטוי '!HasError' הוא תמיד שקר. UnwrappedLineParser.cpp 1635

קטע N30: ​​חזרה חשודה

static bool
isImplicitlyDef(MachineRegisterInfo &MRI, unsigned Reg) {
  for (MachineRegisterInfo::def_instr_iterator It = MRI.def_instr_begin(Reg),
      E = MRI.def_instr_end(); It != E; ++It) {
    return (*It).isImplicitDef();
  }
  ....
}

אזהרת PVS-Studio: V612 [CWE-670] 'החזרה' ללא תנאי בתוך לולאה. R600OptimizeVectorRegisters.cpp 63

זו שגיאה או טכניקה ספציפית שנועדה להסביר משהו למתכנתים הקוראים את הקוד. העיצוב הזה לא מסביר לי כלום ונראה מאוד חשוד. עדיף לא לכתוב ככה :).

עייף? אז הגיע הזמן להכין תה או קפה.

ליקויים שזוהו על ידי אבחון חדש

אני חושב ש-30 הפעלות של אבחון ישן מספיקות. כעת נראה אילו דברים מעניינים ניתן למצוא עם האבחון החדש שהופיע בנתח לאחר מכן קודם המחאות. במהלך תקופה זו, נוספו סה"כ 66 אבחונים למטרות כלליות לנתח C++.

קטע N31: קוד בלתי ניתן להשגה

Error CtorDtorRunner::run() {
  ....
  if (auto CtorDtorMap =
          ES.lookup(JITDylibSearchList({{&JD, true}}), std::move(Names),
                    NoDependenciesToRegister, true))
  {
    ....
    return Error::success();
  } else
    return CtorDtorMap.takeError();

  CtorDtorsByPriority.clear();

  return Error::success();
}

אזהרת PVS-Studio: V779 [CWE-561] זוהה קוד בלתי ניתן להשגה. ייתכן שקיימת שגיאה. ExecutionUtils.cpp 146

כפי שאתה יכול לראות, שני הסניפים של המפעיל if מסתיים בשיחה למוקדנית לַחֲזוֹר. בהתאם לכך, המכולה CtorDtorsByPriority לעולם לא ינוקה.

קטע N32: קוד בלתי ניתן להשגה

bool LLParser::ParseSummaryEntry() {
  ....
  switch (Lex.getKind()) {
  case lltok::kw_gv:
    return ParseGVEntry(SummaryID);
  case lltok::kw_module:
    return ParseModuleEntry(SummaryID);
  case lltok::kw_typeid:
    return ParseTypeIdEntry(SummaryID);                        // <=
    break;                                                     // <=
  default:
    return Error(Lex.getLoc(), "unexpected summary kind");
  }
  Lex.setIgnoreColonInIdentifiers(false);                      // <=
  return false;
}

אזהרת PVS-Studio: V779 [CWE-561] זוהה קוד בלתי ניתן להשגה. ייתכן שקיימת שגיאה. LLParser.cpp 835

מצב מעניין. בואו נסתכל על המקום הזה תחילה:

return ParseTypeIdEntry(SummaryID);
break;

במבט ראשון נראה שאין כאן טעות. זה נראה כמו המפעיל לשבור יש כאן אחד נוסף, ואתה יכול פשוט למחוק אותו. עם זאת, לא הכל כל כך פשוט.

המנתח מוציא אזהרה בקווים:

Lex.setIgnoreColonInIdentifiers(false);
return false;

ואכן, הקוד הזה אינו ניתן להשגה. כל המקרים ב להחליף מסתיים בשיחה מהמפעיל לַחֲזוֹר. ועכשיו חסר טעם לבד לשבור לא נראה כל כך לא מזיק! אולי אחד הענפים צריך לסיים עם לשבוראבל לא לַחֲזוֹר?

קטע N33: איפוס אקראי של ביטים גבוהים

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

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

אזהרת PVS-Studio: V784 גודל מסיכת הסיביות קטן מגודל האופרנד הראשון. זה יגרום לאובדן של ביטים גבוהים יותר. RuntimeDyld.cpp 815

שימו לב שהפונקציה getStubAlignment סוג מחזיר לא חתום. בוא נחשב את הערך של הביטוי, בהנחה שהפונקציה מחזירה את הערך 8:

~(getStubAlignment() - 1)

~(8u-1)

0xFFFFFFFF8u

עכשיו שימו לב שהמשתנה גודל נתונים יש סוג 64 סיביות לא חתום. מסתבר שכאשר מבצעים את פעולת DataSize & 0xFFFFFFF8u, כל שלושים ושניים הביטים בסדר גבוה יאופסו לאפס. סביר להניח שזה לא מה שהמתכנת רצה. אני חושד שהוא רצה לחשב: DataSize & 0xFFFFFFFFFFFFFFF8u.

כדי לתקן את השגיאה, עליך לכתוב את זה:

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

או כך:

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

קטע N34: ליהוק סוג מפורש שנכשל

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

אזהרת PVS-Studio: V1028 [CWE-190] הצפה אפשרית. שקול להטיל אופרנדים של האופרטור 'NumElts * Scale' לסוג 'size_t', לא לתוצאה. X86ISelLowering.h 1577

ליהוק סוג מפורש משמש כדי למנוע הצפת יתר בעת הכפלת משתני סוג int. עם זאת, ליהוק סוג מפורש כאן אינו מגן מפני הצפת יתר. ראשית, המשתנים יוכפלו, ורק לאחר מכן תוצאת 32 הסיביות של הכפל תורחב לסוג גודל_ט.

קטע N35: העתק-הדבק נכשל

Instruction *InstCombiner::visitFCmpInst(FCmpInst &I) {
  ....
  if (!match(Op0, m_PosZeroFP()) && isKnownNeverNaN(Op0, &TLI)) {
    I.setOperand(0, ConstantFP::getNullValue(Op0->getType()));
    return &I;
  }
  if (!match(Op1, m_PosZeroFP()) && isKnownNeverNaN(Op1, &TLI)) {
    I.setOperand(1, ConstantFP::getNullValue(Op0->getType()));        // <=
    return &I;
  }
  ....
}

V778 [CWE-682] נמצאו שני קטעי קוד דומים. אולי זו טעות הקלדה ויש להשתמש במשתנה 'Op1' במקום 'Op0'. InstCombineCompares.cpp 5507

האבחון המעניין החדש הזה מזהה מצבים שבהם קטע קוד הועתק ושמות מסוימים בו החלו להשתנות, אך במקום אחד לא תיקנו אותו.

שימו לב שבגוש השני הם השתנו 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;
  };
  ....
};

אזהרת PVS-Studio: V1001 [CWE-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;
}

אזהרה PVS-Studio: V1001 [CWE-563] המשתנה 'גודל' מוקצה אך אינו בשימוש עד סוף הפונקציה. Object.cpp 424

המצב דומה למצב הקודם. צריך להיות כתוב:

this->Size += this->EntrySize;

שבר N38-N47: שכחו לבדוק את האינדקס

בעבר, בדקנו דוגמאות להפעלת אבחון V595. המהות שלו היא שהמצביע מורחק בהתחלה, ורק אז בודק. אבחון צעיר V1004 הוא הפוך במשמעות, אבל גם חושף הרבה שגיאות. הוא מזהה מצבים שבהם המצביע נבדק בהתחלה ולאחר מכן נשכח לעשות זאת. בואו נסתכל על מקרים כאלה שנמצאו בתוך LLVM.

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

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

אזהרת PVS-Studio: V1004 [CWE-476] במצביע 'Ptr' נעשה שימוש לא בטוח לאחר שהוא אומת כנגד nullptr. קווי בדיקה: 729, 738. TargetTransformInfoImpl.h 738

משתנה 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] במצביע 'FD' נעשה שימוש לא בטוח לאחר שאומת נגד nullptr. קווי בדיקה: 3228, 3231. CGDebugInfo.cpp 3231

שימו לב לשלט FD. אני בטוח שהבעיה נראית בבירור ואין צורך בהסבר מיוחד.

ובהמשך:

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

אזהרת PVS-Studio: V1004 [CWE-476] במצביע 'PtrTy' נעשה שימוש לא בטוח לאחר שהוא אומת כנגד nullptr. קווי בדיקה: 960, 965. InterleavedLoadCombinePass.cpp 965

איך להגן על עצמך מפני שגיאות כאלה? היו קשובים יותר לגבי Code-Review והשתמשו בנתח הסטטי PVS-Studio כדי לבדוק באופן קבוע את הקוד שלכם.

אין טעם לצטט קטעי קוד אחרים עם שגיאות מסוג זה. אני אשאיר רק רשימה של אזהרות במאמר:

• V1004 [CWE-476] במצביע 'Expr' נעשה שימוש לא בטוח לאחר שהוא אומת כנגד nullptr. קווי בדיקה: 1049, 1078. DebugInfoMetadata.cpp 1078
• V1004 [CWE-476] במצביע 'PI' נעשה שימוש לא בטוח לאחר שהוא אומת כנגד nullptr. קווי בדיקה: 733, 753. LegacyPassManager.cpp 753
• V1004 [CWE-476] במצביע 'StatepointCall' נעשה שימוש לא בטוח לאחר שהוא אומת כנגד nullptr. קווי בדיקה: 4371, 4379. Verifier.cpp 4379
• V1004 [CWE-476] במצביע 'RV' נעשה שימוש לא בטוח לאחר שהוא אומת כנגד nullptr. קווי בדיקה: 2263, 2268. TGParser.cpp 2268
• V1004 [CWE-476] במצביע 'CalleeFn' נעשה שימוש לא בטוח לאחר שהוא אומת כנגד nullptr. קווי בדיקה: 1081, 1096. SimplifyLibCalls.cpp 1096
• V1004 [CWE-476] במצביע 'TC' נעשה שימוש לא בטוח לאחר שהוא אומת כנגד nullptr. קווי בדיקה: 1819, 1824. Driver.cpp 1824

קטע N48-N60: לא קריטי, אבל פגם (דליפת זיכרון אפשרית)

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

אזהרת PVS-Studio: V1023 [CWE-460] מצביע ללא בעלים נוסף למיכל 'אסטרטגיות' בשיטת 'emplace_back'. דליפת זיכרון תתרחש במקרה של חריגה. llvm-isel-fuzzer.cpp 58

כדי להוסיף אלמנט לקצה מיכל כמו std::vector > אתה לא יכול פשוט לכתוב xxx.push_back(חדש X), כיון שאין המרה מרומזת מ X* в std::unique_ptr.

פתרון נפוץ הוא לכתוב xxx.emplace_back(חדש X)מאז זה קומפילציה: שיטה emplace_back בונה אלמנט ישירות מארגומנטים ולכן יכול להשתמש בבונים מפורשים.

זה לא בטוח. אם הווקטור מלא, הזיכרון מוקצה מחדש. פעולת ההקצאה מחדש של הזיכרון עלולה להיכשל, וכתוצאה מכך נזרק חריג std::bad_alloc. במקרה זה, המצביע יאבד והאובייקט שנוצר לעולם לא יימחק.

פתרון בטוח הוא ליצור ייחודי_פטראשר יהיה הבעלים של המצביע לפני שהווקטור ינסה להקצות מחדש זיכרון:

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

מאז C++14, אתה יכול להשתמש ב-'std::make_unique':

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

סוג זה של פגם אינו קריטי עבור LLVM. אם לא ניתן להקצות זיכרון, המהדר פשוט יפסיק. עם זאת, עבור יישומים עם ארוך זמן פעילות, אשר לא יכול פשוט להסתיים אם הקצאת זיכרון נכשלת, זה יכול להיות באג ממש מגעיל.

לכן, למרות שקוד זה אינו מהווה סכנה מעשית ל-LLVM, מצאתי שימושי לדבר על דפוס השגיאה הזה ושהנתח PVS-Studio למד לזהות אותו.

אזהרות נוספות מסוג זה:

• V1023 [CWE-460] מצביע ללא בעלים מתווסף למיכל 'Passes' בשיטת 'emplace_back'. דליפת זיכרון תתרחש במקרה של חריגה. PassManager.h 546
• V1023 [CWE-460] מצביע ללא בעלים נוסף למיכל 'AAs' בשיטת 'emplace_back'. דליפת זיכרון תתרחש במקרה של חריגה. AliasAnalysis.h 324
• V1023 [CWE-460] מצביע ללא בעלים נוסף למיכל 'כניסות' בשיטת 'emplace_back'. דליפת זיכרון תתרחש במקרה של חריגה. DWARFDebugFrame.cpp 519
• V1023 [CWE-460] מצביע ללא בעלים נוסף למיכל 'AllEdges' בשיטת 'emplace_back'. דליפת זיכרון תתרחש במקרה של חריגה. CFGMST.h 268
• V1023 [CWE-460] מצביע ללא בעלים נוסף למיכל 'VMaps' בשיטת 'emplace_back'. דליפת זיכרון תתרחש במקרה של חריגה. SimpleLoopUnswitch.cpp 2012
• V1023 [CWE-460] מצביע ללא בעלים נוסף למיכל 'רשומות' בשיטת 'emplace_back'. דליפת זיכרון תתרחש במקרה של חריגה. FDRLogBuilder.h 30
• V1023 [CWE-460] מצביע ללא בעלים נוסף למיכל 'PendingSubmodules' בשיטת 'emplace_back'. דליפת זיכרון תתרחש במקרה של חריגה. ModuleMap.cpp 810
• V1023 [CWE-460] מצביע ללא בעלים נוסף למיכל 'אובייקטים' בשיטת 'emplace_back'. דליפת זיכרון תתרחש במקרה של חריגה. DebugMap.cpp 88
• V1023 [CWE-460] מצביע ללא בעלים נוסף למיכל 'אסטרטגיות' בשיטת 'emplace_back'. דליפת זיכרון תתרחש במקרה של חריגה. llvm-isel-fuzzer.cpp 60
• V1023 [CWE-460] מצביע ללא בעלים מתווסף למיכל 'משנים' בשיטת 'emplace_back'. דליפת זיכרון תתרחש במקרה של חריגה. llvm-stress.cpp 685
• V1023 [CWE-460] מצביע ללא בעלים מתווסף למיכל 'משנים' בשיטת 'emplace_back'. דליפת זיכרון תתרחש במקרה של חריגה. llvm-stress.cpp 686
• V1023 [CWE-460] מצביע ללא בעלים מתווסף למיכל 'משנים' בשיטת 'emplace_back'. דליפת זיכרון תתרחש במקרה של חריגה. llvm-stress.cpp 688
• V1023 [CWE-460] מצביע ללא בעלים מתווסף למיכל 'משנים' בשיטת 'emplace_back'. דליפת זיכרון תתרחש במקרה של חריגה. llvm-stress.cpp 689
• V1023 [CWE-460] מצביע ללא בעלים מתווסף למיכל 'משנים' בשיטת 'emplace_back'. דליפת זיכרון תתרחש במקרה של חריגה. llvm-stress.cpp 690
• V1023 [CWE-460] מצביע ללא בעלים מתווסף למיכל 'משנים' בשיטת 'emplace_back'. דליפת זיכרון תתרחש במקרה של חריגה. llvm-stress.cpp 691
• V1023 [CWE-460] מצביע ללא בעלים מתווסף למיכל 'משנים' בשיטת 'emplace_back'. דליפת זיכרון תתרחש במקרה של חריגה. llvm-stress.cpp 692
• V1023 [CWE-460] מצביע ללא בעלים מתווסף למיכל 'משנים' בשיטת 'emplace_back'. דליפת זיכרון תתרחש במקרה של חריגה. llvm-stress.cpp 693
• V1023 [CWE-460] מצביע ללא בעלים מתווסף למיכל 'משנים' בשיטת 'emplace_back'. דליפת זיכרון תתרחש במקרה של חריגה. llvm-stress.cpp 694
• V1023 [CWE-460] מצביע ללא בעלים נוסף למיכל 'Operands' בשיטת 'emplace_back'. דליפת זיכרון תתרחש במקרה של חריגה. GlobalISelEmitter.cpp 1911
• V1023 [CWE-460] מצביע ללא בעלים נוסף למיכל 'Stash' בשיטת 'emplace_back'. דליפת זיכרון תתרחש במקרה של חריגה. GlobalISelEmitter.cpp 2100
• V1023 [CWE-460] מצביע ללא בעלים נוסף למיכל 'Matchers' בשיטת 'emplace_back'. דליפת זיכרון תתרחש במקרה של חריגה. GlobalISelEmitter.cpp 2702

מסקנה

הוצאתי 60 אזהרות בסך הכל ואז הפסקתי. האם ישנם פגמים נוספים שהנתח PVS-Studio מזהה ב-LLVM? כן יש לי. עם זאת, כשכתבתי קטעי קוד למאמר, זה היה מאוחר בערב, או ליתר דיוק אפילו לילה, והחלטתי שהגיע הזמן לקרוא לזה יום.

אני מקווה שמצאתם את זה מעניין ותרצו לנסות את מנתח PVS-Studio.

אתה יכול להוריד את המנתח ולקבל את מפתח שולה המוקשים בכתובת דף זה.

והכי חשוב, השתמש בניתוח סטטי באופן קבוע. צ'קים חד פעמיים, שבוצעו על ידנו על מנת להפיץ את המתודולוגיה של ניתוח סטטי ו-PVS-Studio אינם תרחיש נורמלי.

בהצלחה בשיפור האיכות והאמינות של הקוד שלך!

אם אתה רוצה לשתף מאמר זה עם קהל דובר אנגלית, אנא השתמש בקישור התרגום: אנדריי קרפוב. איתור באגים ב-LLVM 8 עם PVS-Studio.

מקור: www.habr.com