പിവിഎസ്-സ്റ്റുഡിയോ അനലൈസർ ഉപയോഗിച്ച് LLVM 8-ൽ ബഗുകൾ കണ്ടെത്തുന്നു

ഞങ്ങളുടെ PVS-Studio അനലൈസർ ഉപയോഗിച്ച് LLVM പ്രോജക്‌റ്റിന്റെ അവസാന കോഡ് പരിശോധന കഴിഞ്ഞ് രണ്ട് വർഷത്തിലേറെയായി. പിവിഎസ്-സ്റ്റുഡിയോ അനലൈസർ ഇപ്പോഴും പിശകുകളും സാധ്യതയുള്ള കേടുപാടുകളും തിരിച്ചറിയുന്നതിനുള്ള ഒരു പ്രധാന ഉപകരണമാണെന്ന് ഉറപ്പാക്കാം. ഇത് ചെയ്യുന്നതിന്, LLVM 8.0.0 പതിപ്പിൽ ഞങ്ങൾ പുതിയ പിശകുകൾ പരിശോധിക്കുകയും കണ്ടെത്തുകയും ചെയ്യും.

എഴുതേണ്ട ലേഖനം

സത്യം പറഞ്ഞാൽ, ഈ ലേഖനം എഴുതാൻ ഞാൻ ആഗ്രഹിച്ചില്ല. ഞങ്ങൾ ഇതിനകം നിരവധി തവണ പരിശോധിച്ച ഒരു പ്രോജക്റ്റിനെക്കുറിച്ച് എഴുതുന്നത് രസകരമല്ല (1, 2, 3). പുതിയ കാര്യങ്ങളെക്കുറിച്ച് എഴുതുന്നതാണ് നല്ലത്, പക്ഷേ എനിക്ക് മറ്റ് മാർഗമില്ല.

ഓരോ തവണയും LLVM-ന്റെ ഒരു പുതിയ പതിപ്പ് പുറത്തിറങ്ങുകയോ അപ്ഡേറ്റ് ചെയ്യുകയോ ചെയ്യുന്നു ക്ലാങ് സ്റ്റാറ്റിക് അനലൈസർ, ഞങ്ങളുടെ മെയിലിൽ ഇനിപ്പറയുന്ന തരത്തിലുള്ള ചോദ്യങ്ങൾ ഞങ്ങൾക്ക് ലഭിക്കുന്നു:

നോക്കൂ, Clang സ്റ്റാറ്റിക് അനലൈസറിന്റെ പുതിയ പതിപ്പ് പുതിയ പിശകുകൾ കണ്ടെത്താൻ പഠിച്ചു! PVS-Studio ഉപയോഗിക്കുന്നതിന്റെ പ്രസക്തി കുറയുന്നതായി എനിക്ക് തോന്നുന്നു. ക്ലാങ് മുമ്പത്തേതിനേക്കാൾ കൂടുതൽ പിശകുകൾ കണ്ടെത്തുകയും പിവിഎസ്-സ്റ്റുഡിയോയുടെ കഴിവുകൾ മനസ്സിലാക്കുകയും ചെയ്യുന്നു. ഇതിനെ കുറിച്ചു താങ്കൾ എന്ത് കരുതുന്നു?

ഇതിന് ഞാൻ എപ്പോഴും ഇതുപോലെ എന്തെങ്കിലും ഉത്തരം നൽകാൻ ആഗ്രഹിക്കുന്നു:

ഞങ്ങളും വെറുതെ ഇരിക്കാറില്ല! പിവിഎസ്-സ്റ്റുഡിയോ അനലൈസറിന്റെ കഴിവുകൾ ഞങ്ങൾ ഗണ്യമായി മെച്ചപ്പെടുത്തി. അതിനാൽ വിഷമിക്കേണ്ട, ഞങ്ങൾ മുമ്പത്തെപ്പോലെ ലീഡ് തുടരുന്നു.

നിർഭാഗ്യവശാൽ, ഇതൊരു മോശം ഉത്തരമാണ്. അതിൽ തെളിവുകളൊന്നുമില്ല. അതുകൊണ്ടാണ് ഞാൻ ഇപ്പോൾ ഈ ലേഖനം എഴുതുന്നത്. അതിനാൽ, LLVM പ്രോജക്റ്റ് ഒരിക്കൽ കൂടി പരിശോധിക്കുകയും അതിൽ പലതരം പിശകുകൾ കണ്ടെത്തുകയും ചെയ്തു. എനിക്ക് രസകരമായി തോന്നിയവ ഞാൻ ഇപ്പോൾ പ്രദർശിപ്പിക്കും. ക്ലാങ് സ്റ്റാറ്റിക് അനലൈസറിന് ഈ പിശകുകൾ കണ്ടെത്താൻ കഴിയില്ല (അല്ലെങ്കിൽ അതിന്റെ സഹായത്തോടെ ഇത് ചെയ്യുന്നത് വളരെ അസൗകര്യമാണ്). പക്ഷേ നമുക്ക് കഴിയും. മാത്രമല്ല, ഈ പിശകുകളെല്ലാം ഞാൻ ഒരു വൈകുന്നേരം കണ്ടെത്തി എഴുതി.

എന്നാൽ ലേഖനം എഴുതാൻ ഏതാനും ആഴ്ചകൾ എടുത്തു. ഇതെല്ലാം ടെക്‌സ്‌റ്റിലേക്ക് മാറ്റാൻ എനിക്ക് എന്നെത്തന്നെ ധൈര്യപ്പെടുത്താൻ കഴിഞ്ഞില്ല :).

വഴിയിൽ, പിശകുകളും സാധ്യതയുള്ള കേടുപാടുകളും തിരിച്ചറിയാൻ പിവിഎസ്-സ്റ്റുഡിയോ അനലൈസറിൽ എന്ത് സാങ്കേതികവിദ്യകളാണ് ഉപയോഗിക്കുന്നതെന്ന് നിങ്ങൾക്ക് താൽപ്പര്യമുണ്ടെങ്കിൽ, ഇത് പരിചയപ്പെടാൻ ഞാൻ നിർദ്ദേശിക്കുന്നു. കുറിപ്പ്.

പുതിയതും പഴയതുമായ ഡയഗ്നോസ്റ്റിക്സ്

ഇതിനകം സൂചിപ്പിച്ചതുപോലെ, ഏകദേശം രണ്ട് വർഷം മുമ്പ് LLVM പ്രോജക്റ്റ് വീണ്ടും പരിശോധിക്കുകയും കണ്ടെത്തിയ പിശകുകൾ ശരിയാക്കുകയും ചെയ്തു. ഇപ്പോൾ ഈ ലേഖനം പിശകുകളുടെ ഒരു പുതിയ ബാച്ച് അവതരിപ്പിക്കും. എന്തുകൊണ്ടാണ് പുതിയ ബഗുകൾ കണ്ടെത്തിയത്? ഇതിന് 3 കാരണങ്ങളുണ്ട്:

1. LLVM പ്രോജക്റ്റ് വികസിച്ചുകൊണ്ടിരിക്കുന്നു, പഴയ കോഡ് മാറ്റുകയും പുതിയ കോഡ് ചേർക്കുകയും ചെയ്യുന്നു. സ്വാഭാവികമായും, പരിഷ്കരിച്ചതും എഴുതിയതുമായ കോഡിൽ പുതിയ പിശകുകൾ ഉണ്ട്. സ്ഥിരമായ വിശകലനം പതിവായി ഉപയോഗിക്കണമെന്ന് ഇത് വ്യക്തമായി തെളിയിക്കുന്നു, ഇടയ്ക്കിടെയല്ല. ഞങ്ങളുടെ ലേഖനങ്ങൾ പിവിഎസ്-സ്റ്റുഡിയോ അനലൈസറിന്റെ കഴിവുകൾ നന്നായി കാണിക്കുന്നു, എന്നാൽ കോഡ് ഗുണനിലവാരം മെച്ചപ്പെടുത്തുന്നതിനും പിശകുകൾ പരിഹരിക്കുന്നതിനുള്ള ചെലവ് കുറയ്ക്കുന്നതിനുമായി ഇതിന് യാതൊരു ബന്ധവുമില്ല. സ്ഥിരമായി ഒരു സ്റ്റാറ്റിക് കോഡ് അനലൈസർ ഉപയോഗിക്കുക!
2. ഞങ്ങൾ നിലവിലുള്ള ഡയഗ്നോസ്റ്റിക്സ് അന്തിമമാക്കുകയും മെച്ചപ്പെടുത്തുകയും ചെയ്യുന്നു. അതിനാൽ, അനലൈസർ മുമ്പത്തെ സ്കാനുകളിൽ ശ്രദ്ധിക്കാത്ത പിശകുകൾ തിരിച്ചറിയാൻ കഴിയും.
3. 2 വർഷം മുമ്പ് നിലവിലില്ലാത്ത പുതിയ ഡയഗ്നോസ്റ്റിക്സ് പിവിഎസ്-സ്റ്റുഡിയോയിൽ പ്രത്യക്ഷപ്പെട്ടു. പിവിഎസ്-സ്റ്റുഡിയോയുടെ വികസനം വ്യക്തമായി കാണിക്കാൻ ഒരു പ്രത്യേക വിഭാഗത്തിൽ അവരെ ഹൈലൈറ്റ് ചെയ്യാൻ ഞാൻ തീരുമാനിച്ചു.

2 വർഷം മുമ്പ് നിലനിന്നിരുന്ന ഡയഗ്നോസ്റ്റിക്സ് വഴി തിരിച്ചറിഞ്ഞ വൈകല്യങ്ങൾ

ശകലം N1: പകർത്തുക-ഒട്ടിക്കുക

static bool ShouldUpgradeX86Intrinsic(Function *F, StringRef Name) {
  if (Name == "addcarryx.u32" || // Added in 8.0
    ....
    Name == "avx512.mask.cvtps2pd.128" || // Added in 7.0
    Name == "avx512.mask.cvtps2pd.256" || // Added in 7.0
    Name == "avx512.cvtusi2sd" || // Added in 7.0
    Name.startswith("avx512.mask.permvar.") || // Added in 7.0     // <=
    Name.startswith("avx512.mask.permvar.") || // Added in 7.0     // <=
    Name == "sse2.pmulu.dq" || // Added in 7.0
    Name == "sse41.pmuldq" || // Added in 7.0
    Name == "avx2.pmulu.dq" || // Added in 7.0
  ....
}

PVS-സ്റ്റുഡിയോ മുന്നറിയിപ്പ്: 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-സ്റ്റുഡിയോ മുന്നറിയിപ്പ്: 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-സ്റ്റുഡിയോ മുന്നറിയിപ്പ്: V522 [CWE-476] നൾ പോയിന്റർ 'LHS' ന്റെ ഡിറഫറൻസിങ് നടന്നേക്കാം. TGPparser.cpp 2152

പോയിന്റർ ആണെങ്കിൽ LHS അസാധുവാണ്, മുന്നറിയിപ്പ് നൽകണം. എന്നിരുന്നാലും, പകരം, ഇതേ നൾ പോയിന്റർ ഒഴിവാക്കപ്പെടും: LHS->getAsString().

ഒരു പിശക് ഹാൻഡ്‌ലറിൽ ഒരു പിശക് മറഞ്ഞിരിക്കുമ്പോൾ ഇത് വളരെ സാധാരണമായ ഒരു സാഹചര്യമാണ്, കാരണം ആരും അവ പരിശോധിക്കുന്നില്ല. എത്ര തവണ ഉപയോഗിച്ചാലും, എത്തിച്ചേരാവുന്ന എല്ലാ കോഡുകളും സ്റ്റാറ്റിക് അനലൈസറുകൾ പരിശോധിക്കുന്നു. സ്റ്റാറ്റിക് വിശകലനം മറ്റ് ടെസ്റ്റിംഗും പിശക് പരിരക്ഷണ സാങ്കേതികതകളും എങ്ങനെ പൂർത്തീകരിക്കുന്നു എന്നതിന്റെ മികച്ച ഉദാഹരണമാണിത്.

സമാനമായ പോയിന്റർ കൈകാര്യം ചെയ്യൽ പിശക് HRH ചുവടെയുള്ള കോഡിൽ അനുവദനീയം: V522 [CWE-476] നൾ പോയിന്റർ 'RHS' ന്റെ ഡിറഫറൻസിങ് നടന്നേക്കാം. TGPparser.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] നൾ പോയിന്റർ 'പ്രോഗ്ക്ലോൺ' ഡീറഫറൻസിങ് നടന്നേക്കാം. Miscompilation.cpp 601

തുടക്കത്തിൽ ഒരു സ്മാർട്ട് പോയിന്റർ പ്രോഗ്ക്ലോൺ വസ്തുവിനെ സ്വന്തമാക്കുന്നത് നിർത്തുന്നു:

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

വാസ്തവത്തിൽ, ഇപ്പോൾ പ്രോഗ്ക്ലോൺ ഒരു നൾ പോയിന്റർ ആണ്. അതിനാൽ, ഒരു നൾ പോയിന്റർ ഡെറഫറൻസ് താഴെ സംഭവിക്കണം:

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

പക്ഷേ, വാസ്തവത്തിൽ, ഇത് സംഭവിക്കില്ല! ലൂപ്പ് യഥാർത്ഥത്തിൽ എക്സിക്യൂട്ട് ചെയ്തിട്ടില്ല എന്നത് ശ്രദ്ധിക്കുക.

കണ്ടെയ്നറിന്റെ തുടക്കത്തിൽ തെറ്റായി സമാഹരിച്ച പ്രവർത്തനങ്ങൾ മായ്ച്ചു:

MiscompiledFunctions.clear();

അടുത്തതായി, ഈ കണ്ടെയ്നറിന്റെ വലുപ്പം ലൂപ്പ് അവസ്ഥയിൽ ഉപയോഗിക്കുന്നു:

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

ലൂപ്പ് ആരംഭിക്കുന്നില്ലെന്ന് കാണാൻ എളുപ്പമാണ്. ഇതും ഒരു ബഗ് ആണെന്ന് തോന്നുന്നു, കോഡ് വ്യത്യസ്തമായി എഴുതണം.

തെറ്റുകളുടെ പ്രസിദ്ധമായ സമത്വം ഞങ്ങൾ നേരിട്ടതായി തോന്നുന്നു! ഒരു തെറ്റ് മറ്റൊന്നിനെ മറയ്ക്കുന്നു :).

ശകലം N7: നീങ്ങിയ ശേഷം പോയിന്റർ ഉപയോഗിക്കുന്നു

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

PVS-Studio മുന്നറിയിപ്പ്: V522 [CWE-476] നൾ പോയിന്റർ 'ടെസ്റ്റ്' ഡീറഫറൻസിങ് നടന്നേക്കാം. Miscompilation.cpp 709

വീണ്ടും അതേ അവസ്ഥ. ആദ്യം, ഒബ്ജക്റ്റിന്റെ ഉള്ളടക്കങ്ങൾ നീക്കി, പിന്നീട് ഒന്നും സംഭവിക്കാത്തതുപോലെ ഉപയോഗിക്കുന്നു. C++ ൽ മൂവ്മെന്റ് സെമാന്റിക്‌സ് പ്രത്യക്ഷപ്പെട്ടതിന് ശേഷം പ്രോഗ്രാം കോഡിൽ ഞാൻ ഈ സാഹചര്യം കൂടുതൽ കൂടുതൽ കാണുന്നു. അതുകൊണ്ടാണ് ഞാൻ C++ ഭാഷയെ ഇഷ്ടപ്പെടുന്നത്! നിങ്ങളുടെ സ്വന്തം കാലിൽ നിന്ന് വെടിവയ്ക്കാൻ കൂടുതൽ കൂടുതൽ പുതിയ വഴികളുണ്ട്. പിവിഎസ്-സ്റ്റുഡിയോ അനലൈസറിന് എല്ലായ്‌പ്പോഴും ജോലി ഉണ്ടായിരിക്കും :).

ശകലം N8: നൾ പോയിന്റർ

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

PVS-Studio മുന്നറിയിപ്പ്: V522 [CWE-476] നൾ പോയിന്റർ 'ടൈപ്പ്' ഡീറഫറൻസിങ് നടന്നേക്കാം. 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-സ്റ്റുഡിയോ മുന്നറിയിപ്പ്: 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-സ്റ്റുഡിയോ മുന്നറിയിപ്പ്: 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-സ്റ്റുഡിയോ മുന്നറിയിപ്പ്: 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] nullptr-നെതിരെ പരിശോധിച്ചുറപ്പിക്കുന്നതിന് മുമ്പ് 'ND' പോയിന്റർ ഉപയോഗിച്ചു. ലൈനുകൾ പരിശോധിക്കുക: 532, 534. SemaTemplateInstantiateDecl.cpp 532

പിന്നെ ഇവിടെ:

• V595 [CWE-476] nullptr-നെതിരെ സ്ഥിരീകരിക്കുന്നതിന് മുമ്പ് 'U' പോയിന്റർ ഉപയോഗിച്ചു. ചെക്ക് ലൈനുകൾ: 404, 407. DWARFormValue.cpp 404
• V595 [CWE-476] nullptr-നെതിരെ സ്ഥിരീകരിക്കുന്നതിന് മുമ്പ് 'ND' പോയിന്റർ ഉപയോഗിച്ചു. ലൈനുകൾ പരിശോധിക്കുക: 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-സ്റ്റുഡിയോ മുന്നറിയിപ്പ്: V629 [CWE-190] '~(വലിപ്പം - 1) << 1' എക്സ്പ്രഷൻ പരിശോധിക്കുന്നത് പരിഗണിക്കുക. 32-ബിറ്റ് മൂല്യത്തിന്റെ ബിറ്റ് ഷിഫ്റ്റിംഗ്, തുടർന്നുള്ള വിപുലീകരണത്തോടെ 64-ബിറ്റ് തരത്തിലേക്ക്. AArch64AddressingModes.h 260

ഇതൊരു ബഗ് ആയിരിക്കില്ല, കോഡ് ഉദ്ദേശിച്ചതുപോലെ തന്നെ പ്രവർത്തിക്കുന്നു. എന്നാൽ ഇത് വളരെ സംശയാസ്പദമായ സ്ഥലമാണ്, അത് പരിശോധിക്കേണ്ടതുണ്ട്.

വേരിയബിൾ എന്ന് പറയാം വലുപ്പം 16 ന് തുല്യമാണ്, തുടർന്ന് കോഡിന്റെ രചയിതാവ് അത് ഒരു വേരിയബിളിൽ ലഭിക്കാൻ പദ്ധതിയിട്ടു നിംസ് അർത്ഥം:

1111111111111111111111111111111111111111111111111111111111100000

എന്നിരുന്നാലും, വാസ്തവത്തിൽ ഫലം ഇതായിരിക്കും:

0000000000000000000000000000000011111111111111111111111111100000

എല്ലാ കണക്കുകൂട്ടലുകളും 32-ബിറ്റ് സൈൻ ചെയ്യാത്ത തരം ഉപയോഗിച്ചാണ് സംഭവിക്കുന്നത് എന്നതാണ് വസ്തുത. അതിനുശേഷം മാത്രമേ, ഈ 32-ബിറ്റ് ഒപ്പിടാത്ത തരം പരോക്ഷമായി വിപുലീകരിക്കപ്പെടുകയുള്ളൂ uint64_t. ഈ സാഹചര്യത്തിൽ, ഏറ്റവും പ്രധാനപ്പെട്ട ബിറ്റുകൾ പൂജ്യമായിരിക്കും.

നിങ്ങൾക്ക് ഇതുപോലെ സാഹചര്യം പരിഹരിക്കാൻ കഴിയും:

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

സമാനമായ സാഹചര്യം: V629 [CWE-190] 'Immr << 6' എക്സ്പ്രഷൻ പരിശോധിക്കുന്നത് പരിഗണിക്കുക. 32-ബിറ്റ് മൂല്യത്തിന്റെ ബിറ്റ് ഷിഫ്റ്റിംഗ്, തുടർന്നുള്ള വിപുലീകരണത്തോടെ 64-ബിറ്റ് തരത്തിലേക്ക്. AArch64AddressingModes.h 269

ശകലം N19: കീവേഡ് വിട്ടുപോയിരിക്കുന്നു മറ്റാരെങ്കിലും?

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

PVS-സ്റ്റുഡിയോ മുന്നറിയിപ്പ്: 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] സ്ട്രിംഗുകൾ കൂട്ടിയിണക്കിയെങ്കിലും ഉപയോഗിക്കുന്നില്ല. 'ഫലം + Name.str()' എക്സ്പ്രഷൻ പരിശോധിക്കുന്നത് പരിഗണിക്കുക. Symbol.cpp 32
• V655 [CWE-480] സ്ട്രിംഗുകൾ കൂട്ടിയിണക്കിയെങ്കിലും ഉപയോഗിക്കുന്നില്ല. 'ഫലം + "(ObjC ക്ലാസ്)" + Name.str()' എക്സ്പ്രഷൻ പരിശോധിക്കുന്നത് പരിഗണിക്കുക. Symbol.cpp 35
• V655 [CWE-480] സ്ട്രിംഗുകൾ കൂട്ടിച്ചേർത്തതാണെങ്കിലും ഉപയോഗിക്കുന്നില്ല. 'ഫലം + "(ObjC ക്ലാസ് EH) " + Name.str()' എക്സ്പ്രഷൻ പരിശോധിക്കുന്നത് പരിഗണിക്കുക. Symbol.cpp 38
• V655 [CWE-480] സ്ട്രിംഗുകൾ കൂട്ടിയിണക്കിയെങ്കിലും ഉപയോഗിക്കുന്നില്ല. 'ഫലം + "(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-സ്റ്റുഡിയോ മുന്നറിയിപ്പ്: 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-സ്റ്റുഡിയോ മുന്നറിയിപ്പ്: 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-സ്റ്റുഡിയോ മുന്നറിയിപ്പ്: V547 [CWE-571] 'nextByte != 0x90' എന്ന പ്രയോഗം എല്ലായ്പ്പോഴും ശരിയാണ്. X86DisassemblerDecoder.cpp 379

പരിശോധിക്കുന്നതിൽ അർത്ഥമില്ല. വേരിയബിൾ അടുത്ത ബൈറ്റ് എല്ലായ്പ്പോഴും മൂല്യത്തിന് തുല്യമല്ല 0x90, ഇത് മുമ്പത്തെ പരിശോധനയിൽ നിന്ന് പിന്തുടരുന്നു. ഇത് ഒരുതരം ലോജിക്കൽ പിശകാണ്.

ശകലം N29 - N...: എല്ലായ്പ്പോഴും ശരി/തെറ്റായ അവസ്ഥകൾ

അനലൈസർ നിരവധി മുന്നറിയിപ്പുകൾ നൽകുന്നു, മുഴുവൻ അവസ്ഥയും (V547) അല്ലെങ്കിൽ അതിന്റെ ഭാഗം (V560) എല്ലായ്പ്പോഴും ശരിയോ തെറ്റോ ആണ്. പലപ്പോഴും ഇവ യഥാർത്ഥ പിശകുകളല്ല, മറിച്ച് കേവലം സ്ലോപ്പി കോഡ്, മാക്രോ വികാസത്തിന്റെ ഫലം മുതലായവ. എന്നിരുന്നാലും, ഈ മുന്നറിയിപ്പുകളെല്ലാം നോക്കുന്നത് അർത്ഥവത്താണ്, കാരണം യഥാർത്ഥ ലോജിക്കൽ പിശകുകൾ കാലാകാലങ്ങളിൽ സംഭവിക്കാറുണ്ട്. ഉദാഹരണത്തിന്, കോഡിന്റെ ഈ വിഭാഗം സംശയാസ്പദമാണ്:

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

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

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

PVS-സ്റ്റുഡിയോ മുന്നറിയിപ്പ്: V560 [CWE-570] സോപാധികമായ പദപ്രയോഗത്തിന്റെ ഒരു ഭാഗം എല്ലായ്പ്പോഴും തെറ്റാണ്: RegNo == 0xe. ARMDisassembler.cpp 939

സ്ഥിരമായ 0xE എന്നത് ദശാംശത്തിലെ മൂല്യം 14 ആണ്. പരീക്ഷ RegNo == 0xe അർത്ഥമില്ല കാരണം എങ്കിൽ RegNo > 13, തുടർന്ന് ഫംഗ്ഷൻ അതിന്റെ നിർവ്വഹണം പൂർത്തിയാക്കും.

V547, V560 എന്നീ ഐഡികൾക്കൊപ്പം മറ്റ് നിരവധി മുന്നറിയിപ്പുകളും ഉണ്ടായിരുന്നു, എന്നാൽ അതുപോലെ V595, ഈ മുന്നറിയിപ്പുകൾ പഠിക്കാൻ എനിക്ക് താൽപ്പര്യമില്ലായിരുന്നു. ഒരു ലേഖനം എഴുതാൻ എനിക്ക് മതിയായ മെറ്റീരിയൽ ഉണ്ടെന്ന് ഇതിനകം വ്യക്തമായിരുന്നു :). അതിനാൽ, PVS-Studio ഉപയോഗിച്ച് LLVM-ൽ ഇത്തരത്തിലുള്ള എത്ര പിശകുകൾ തിരിച്ചറിയാൻ കഴിയുമെന്ന് അറിയില്ല.

ഈ ട്രിഗറുകൾ പഠിക്കുന്നത് വിരസമായിരിക്കുന്നത് എന്തുകൊണ്ടെന്നതിന്റെ ഒരു ഉദാഹരണം ഞാൻ നിങ്ങൾക്ക് തരാം. ഇനിപ്പറയുന്ന കോഡിനായി ഒരു മുന്നറിയിപ്പ് നൽകുന്നതിൽ അനലൈസർ തികച്ചും ശരിയാണ്. എന്നാൽ ഇത് ഒരു തെറ്റല്ല.

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-സ്റ്റുഡിയോ മുന്നറിയിപ്പ്: V612 [CWE-670] ഒരു ലൂപ്പിനുള്ളിൽ ഉപാധികളില്ലാത്ത 'മടങ്ങൽ'. R600OptimizeVectorRegisters.cpp 63

കോഡ് വായിക്കുന്ന പ്രോഗ്രാമർമാർക്ക് എന്തെങ്കിലും വിശദീകരിക്കാൻ ഉദ്ദേശിച്ചുള്ള ഒരു പിശക് അല്ലെങ്കിൽ ഒരു പ്രത്യേക സാങ്കേതികതയാണിത്. ഈ ഡിസൈൻ എനിക്ക് ഒന്നും വിശദീകരിക്കുന്നില്ല, വളരെ സംശയാസ്പദമായി തോന്നുന്നു. അങ്ങനെ എഴുതാതിരിക്കുന്നതാണ് നല്ലത് :).

മടുത്തോ? അപ്പോൾ ചായയോ കാപ്പിയോ ഉണ്ടാക്കാൻ സമയമായി.

പുതിയ ഡയഗ്നോസ്റ്റിക്സ് വഴി തിരിച്ചറിഞ്ഞ വൈകല്യങ്ങൾ

പഴയ ഡയഗ്നോസ്റ്റിക്സിന്റെ 30 സജീവമാക്കലുകൾ മതിയെന്ന് ഞാൻ കരുതുന്നു. അതിനുശേഷം അനലൈസറിൽ പ്രത്യക്ഷപ്പെട്ട പുതിയ ഡയഗ്നോസ്റ്റിക്സ് ഉപയോഗിച്ച് രസകരമായ കാര്യങ്ങൾ എന്തെല്ലാം കണ്ടെത്താമെന്ന് നോക്കാം മുമ്പത്തെ പരിശോധിക്കുന്നു. ഈ സമയത്ത്, C++ അനലൈസറിലേക്ക് മൊത്തം 66 പൊതു-ഉദ്ദേശ്യ ഡയഗ്നോസ്റ്റിക്സ് ചേർത്തു.

ശകലം N31: എത്തിച്ചേരാനാകാത്ത കോഡ്

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

  CtorDtorsByPriority.clear();

  return Error::success();
}

PVS-സ്റ്റുഡിയോ മുന്നറിയിപ്പ്: V779 [CWE-561] ലഭ്യമല്ലാത്ത കോഡ് കണ്ടെത്തി. ഒരു പിശക് ഉണ്ടാകാൻ സാധ്യതയുണ്ട്. ExecutionUtils.cpp 146

നിങ്ങൾക്ക് കാണാനാകുന്നതുപോലെ, ഓപ്പറേറ്ററുടെ രണ്ട് ശാഖകളും if ഓപ്പറേറ്ററിലേക്കുള്ള ഒരു കോളിൽ അവസാനിക്കുന്നു മടക്കം. അതനുസരിച്ച്, കണ്ടെയ്നർ CtorDtorsBy Priority ഒരിക്കലും മായ്‌ക്കില്ല.

ശകലം 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-സ്റ്റുഡിയോ മുന്നറിയിപ്പ്: V784 ബിറ്റ് മാസ്കിന്റെ വലുപ്പം ആദ്യ ഓപ്പറണ്ടിന്റെ വലുപ്പത്തേക്കാൾ കുറവാണ്. ഇത് ഉയർന്ന ബിറ്റുകളുടെ നഷ്ടത്തിന് കാരണമാകും. RuntimeDyld.cpp 815

ഫംഗ്ഷൻ എന്നത് ശ്രദ്ധിക്കുക getStubAlinement റിട്ടേൺസ് തരം ഒപ്പിടാത്തത്. ഫംഗ്‌ഷൻ മൂല്യം 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-സ്റ്റുഡിയോ മുന്നറിയിപ്പ്: V1028 [CWE-190] സാധ്യമായ ഓവർഫ്ലോ. 'NumElts * സ്കെയിൽ' ഓപ്പറേറ്ററിന്റെ കാസ്റ്റിംഗ് ഓപ്പറണ്ടുകൾ '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-സ്റ്റുഡിയോ മുന്നറിയിപ്പ്: 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] 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. InterleavedLoadCombinePass.cpp 965

അത്തരം പിശകുകളിൽ നിന്ന് സ്വയം എങ്ങനെ സംരക്ഷിക്കാം? കോഡ്-റിവ്യൂവിൽ കൂടുതൽ ശ്രദ്ധാലുവായിരിക്കുക, നിങ്ങളുടെ കോഡ് പതിവായി പരിശോധിക്കാൻ PVS-Studio സ്റ്റാറ്റിക് അനലൈസർ ഉപയോഗിക്കുക.

ഇത്തരത്തിലുള്ള പിശകുകളുള്ള മറ്റ് കോഡ് ശകലങ്ങൾ ഉദ്ധരിക്കുന്നതിൽ അർത്ഥമില്ല. ലേഖനത്തിൽ ഞാൻ മുന്നറിയിപ്പുകളുടെ ഒരു ലിസ്റ്റ് മാത്രം ഇടും:

• V1004 [CWE-476] 'Expr' പോയിന്റർ nullptr-നെതിരെ പരിശോധിച്ചുറപ്പിച്ചതിന് ശേഷം സുരക്ഷിതമല്ലാത്ത രീതിയിൽ ഉപയോഗിച്ചു. ചെക്ക് ലൈനുകൾ: 1049, 1078. DebugInfoMetadata.cpp 1078
• V1004 [CWE-476] nullptr-നെതിരെ പരിശോധിച്ചുറപ്പിച്ചതിന് ശേഷം 'PI' പോയിന്റർ സുരക്ഷിതമല്ലാത്ത രീതിയിൽ ഉപയോഗിച്ചു. ചെക്ക് ലൈനുകൾ: 733, 753. LegacyPassManager.cpp 753
• V1004 [CWE-476] 'StatepointCall' പോയിന്റർ nullptr-നെതിരെ പരിശോധിച്ചുറപ്പിച്ചതിന് ശേഷം സുരക്ഷിതമല്ലാത്ത രീതിയിൽ ഉപയോഗിച്ചു. ലൈനുകൾ പരിശോധിക്കുക: 4371, 4379. Verifier.cpp 4379
• V1004 [CWE-476] nullptr-നെതിരെ പരിശോധിച്ചുറപ്പിച്ചതിന് ശേഷം 'RV' പോയിന്റർ സുരക്ഷിതമല്ലാത്ത രീതിയിൽ ഉപയോഗിച്ചു. ചെക്ക് ലൈനുകൾ: 2263, 2268. TGPparser.cpp 2268
• V1004 [CWE-476] nullptr-നെതിരെ പരിശോധിച്ചുറപ്പിച്ചതിന് ശേഷം 'CalleeFn' പോയിന്റർ സുരക്ഷിതമല്ലാത്ത രീതിയിൽ ഉപയോഗിച്ചു. ലൈനുകൾ പരിശോധിക്കുക: 1081, 1096. SimplifyLibCalls.cpp 1096
• V1004 [CWE-476] nullptr-നെതിരെ പരിശോധിച്ചുറപ്പിച്ചതിന് ശേഷം 'TC' പോയിന്റർ സുരക്ഷിതമല്ലാത്ത രീതിയിൽ ഉപയോഗിച്ചു. ചെക്ക് ലൈനുകൾ: 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-സ്റ്റുഡിയോ മുന്നറിയിപ്പ്: V1023 [CWE-460] 'എംപ്ലേസ്_ബാക്ക്' രീതി ഉപയോഗിച്ച് 'സ്ട്രാറ്റജീസ്' കണ്ടെയ്‌നറിലേക്ക് ഉടമയില്ലാത്ത ഒരു പോയിന്റർ ചേർക്കുന്നു. ഒരു ഒഴിവാക്കലിന്റെ കാര്യത്തിൽ ഒരു മെമ്മറി ലീക്ക് സംഭവിക്കും. llvm-isel-fuzzer.cpp 58

ഒരു കണ്ടെയ്‌നറിന്റെ അറ്റത്ത് ഒരു ഘടകം ചേർക്കുന്നതിന് പോലെ std:: വെക്റ്റർ > നിങ്ങൾക്ക് എഴുതാൻ കഴിയില്ല xxx.push_back(പുതിയ X), മുതൽ പരോക്ഷമായ പരിവർത്തനം ഇല്ല X* в std::unique_ptr.

ഒരു പൊതു പരിഹാരം എഴുതുക എന്നതാണ് xxx.emplace_back(പുതിയ X)കംപൈൽ ചെയ്യുന്നതിനാൽ: രീതി emplace_back ആർഗ്യുമെന്റുകളിൽ നിന്ന് നേരിട്ട് ഒരു ഘടകം നിർമ്മിക്കുന്നു, അതിനാൽ വ്യക്തമായ കൺസ്ട്രക്‌ടറുകൾ ഉപയോഗിക്കാനാകും.

അത് സുരക്ഷിതമല്ല. വെക്റ്റർ നിറഞ്ഞാൽ, മെമ്മറി വീണ്ടും അലോക്കേറ്റ് ചെയ്യപ്പെടും. മെമ്മറി റീലോക്കേഷൻ ഓപ്പറേഷൻ പരാജയപ്പെടാം, അതിന്റെ ഫലമായി ഒരു അപവാദം എറിയപ്പെടും std::bad_alloc. ഈ സാഹചര്യത്തിൽ, പോയിന്റർ നഷ്ടപ്പെടും, സൃഷ്ടിച്ച ഒബ്ജക്റ്റ് ഒരിക്കലും ഇല്ലാതാക്കില്ല.

ഒരു സുരക്ഷിത പരിഹാരം സൃഷ്ടിക്കുക എന്നതാണ് തനത്_ptrവെക്റ്റർ മെമ്മറി പുനഃസ്ഥാപിക്കാൻ ശ്രമിക്കുന്നതിന് മുമ്പ് ഏത് പോയിന്റർ സ്വന്തമാക്കും:

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] ഉടമയില്ലാത്ത ഒരു പോയിന്റർ 'Emplace_back' രീതി ഉപയോഗിച്ച് 'Passes' കണ്ടെയ്‌നറിലേക്ക് ചേർക്കുന്നു. ഒരു ഒഴിവാക്കലിന്റെ കാര്യത്തിൽ ഒരു മെമ്മറി ലീക്ക് സംഭവിക്കും. PassManager.h 546
• V1023 [CWE-460] ഉടമയില്ലാത്ത ഒരു പോയിന്റർ 'എഎഎസ്' കണ്ടെയ്‌നറിലേക്ക് 'എംപ്ലേസ്_ബാക്ക്' രീതി ഉപയോഗിച്ച് ചേർത്തിരിക്കുന്നു. ഒരു ഒഴിവാക്കലിന്റെ കാര്യത്തിൽ ഒരു മെമ്മറി ലീക്ക് സംഭവിക്കും. AliasAnalysis.h 324
• V1023 [CWE-460] 'എംപ്ലേസ്_ബാക്ക്' രീതി ഉപയോഗിച്ച് 'എൻട്രികൾ' കണ്ടെയ്‌നറിലേക്ക് ഉടമയില്ലാത്ത ഒരു പോയിന്റർ ചേർക്കുന്നു. ഒരു ഒഴിവാക്കലിന്റെ കാര്യത്തിൽ ഒരു മെമ്മറി ലീക്ക് സംഭവിക്കും. DWARFDebugFrame.cpp 519
• V1023 [CWE-460] ഉടമയില്ലാത്ത ഒരു പോയിന്റർ 'Emplace_back' രീതി ഉപയോഗിച്ച് 'AllEdges' കണ്ടെയ്‌നറിലേക്ക് ചേർക്കുന്നു. ഒരു ഒഴിവാക്കലിന്റെ കാര്യത്തിൽ ഒരു മെമ്മറി ലീക്ക് സംഭവിക്കും. CFGMST.h 268
• V1023 [CWE-460] ഉടമയില്ലാത്ത ഒരു പോയിന്റർ 'VMaps' കണ്ടെയ്‌നറിലേക്ക് 'emplace_back' രീതി ഉപയോഗിച്ച് ചേർത്തിരിക്കുന്നു. ഒരു ഒഴിവാക്കലിന്റെ കാര്യത്തിൽ ഒരു മെമ്മറി ലീക്ക് സംഭവിക്കും. SimpleLoopUnswitch.cpp 2012
• V1023 [CWE-460] ഉടമയില്ലാത്ത ഒരു പോയിന്റർ 'Records' കണ്ടെയ്‌നറിലേക്ക് 'emplace_back' രീതി ഉപയോഗിച്ച് ചേർത്തിരിക്കുന്നു. ഒരു ഒഴിവാക്കലിന്റെ കാര്യത്തിൽ ഒരു മെമ്മറി ലീക്ക് സംഭവിക്കും. FDRLogBuilder.h 30
• V1023 [CWE-460] ഉടമയില്ലാത്ത ഒരു പോയിന്റർ 'PendingSubmodules' കണ്ടെയ്‌നറിലേക്ക് 'emplace_back' രീതി ഉപയോഗിച്ച് ചേർത്തിരിക്കുന്നു. ഒരു ഒഴിവാക്കലിന്റെ കാര്യത്തിൽ ഒരു മെമ്മറി ലീക്ക് സംഭവിക്കും. ModuleMap.cpp 810
• V1023 [CWE-460] ഉടമയില്ലാത്ത ഒരു പോയിന്റർ 'Objects' കണ്ടെയ്‌നറിലേക്ക് 'emplace_back' രീതി ഉപയോഗിച്ച് ചേർത്തിരിക്കുന്നു. ഒരു ഒഴിവാക്കലിന്റെ കാര്യത്തിൽ ഒരു മെമ്മറി ലീക്ക് സംഭവിക്കും. DebugMap.cpp 88
• V1023 [CWE-460] ഉടമയില്ലാത്ത ഒരു പോയിന്റർ 'Emplace_back' രീതി ഉപയോഗിച്ച് 'Strategies' കണ്ടെയ്‌നറിലേക്ക് ചേർക്കുന്നു. ഒരു ഒഴിവാക്കലിന്റെ കാര്യത്തിൽ ഒരു മെമ്മറി ലീക്ക് സംഭവിക്കും. llvm-isel-fuzzer.cpp 60
• V1023 [CWE-460] 'എംപ്ലേസ്_ബാക്ക്' രീതി ഉപയോഗിച്ച് 'മോഡിഫയേഴ്‌സ്' കണ്ടെയ്‌നറിലേക്ക് ഉടമയില്ലാത്ത ഒരു പോയിന്റർ ചേർക്കുന്നു. ഒരു ഒഴിവാക്കലിന്റെ കാര്യത്തിൽ ഒരു മെമ്മറി ലീക്ക് സംഭവിക്കും. llvm-stress.cpp 685
• V1023 [CWE-460] 'എംപ്ലേസ്_ബാക്ക്' രീതി ഉപയോഗിച്ച് 'മോഡിഫയേഴ്‌സ്' കണ്ടെയ്‌നറിലേക്ക് ഉടമയില്ലാത്ത ഒരു പോയിന്റർ ചേർക്കുന്നു. ഒരു ഒഴിവാക്കലിന്റെ കാര്യത്തിൽ ഒരു മെമ്മറി ലീക്ക് സംഭവിക്കും. llvm-stress.cpp 686
• V1023 [CWE-460] 'എംപ്ലേസ്_ബാക്ക്' രീതി ഉപയോഗിച്ച് 'മോഡിഫയേഴ്‌സ്' കണ്ടെയ്‌നറിലേക്ക് ഉടമയില്ലാത്ത ഒരു പോയിന്റർ ചേർക്കുന്നു. ഒരു ഒഴിവാക്കലിന്റെ കാര്യത്തിൽ ഒരു മെമ്മറി ലീക്ക് സംഭവിക്കും. llvm-stress.cpp 688
• V1023 [CWE-460] 'എംപ്ലേസ്_ബാക്ക്' രീതി ഉപയോഗിച്ച് 'മോഡിഫയേഴ്‌സ്' കണ്ടെയ്‌നറിലേക്ക് ഉടമയില്ലാത്ത ഒരു പോയിന്റർ ചേർക്കുന്നു. ഒരു ഒഴിവാക്കലിന്റെ കാര്യത്തിൽ ഒരു മെമ്മറി ലീക്ക് സംഭവിക്കും. llvm-stress.cpp 689
• V1023 [CWE-460] 'എംപ്ലേസ്_ബാക്ക്' രീതി ഉപയോഗിച്ച് 'മോഡിഫയേഴ്‌സ്' കണ്ടെയ്‌നറിലേക്ക് ഉടമയില്ലാത്ത ഒരു പോയിന്റർ ചേർക്കുന്നു. ഒരു ഒഴിവാക്കലിന്റെ കാര്യത്തിൽ ഒരു മെമ്മറി ലീക്ക് സംഭവിക്കും. llvm-stress.cpp 690
• V1023 [CWE-460] 'എംപ്ലേസ്_ബാക്ക്' രീതി ഉപയോഗിച്ച് 'മോഡിഫയേഴ്‌സ്' കണ്ടെയ്‌നറിലേക്ക് ഉടമയില്ലാത്ത ഒരു പോയിന്റർ ചേർക്കുന്നു. ഒരു ഒഴിവാക്കലിന്റെ കാര്യത്തിൽ ഒരു മെമ്മറി ലീക്ക് സംഭവിക്കും. llvm-stress.cpp 691
• V1023 [CWE-460] 'എംപ്ലേസ്_ബാക്ക്' രീതി ഉപയോഗിച്ച് 'മോഡിഫയേഴ്‌സ്' കണ്ടെയ്‌നറിലേക്ക് ഉടമയില്ലാത്ത ഒരു പോയിന്റർ ചേർക്കുന്നു. ഒരു ഒഴിവാക്കലിന്റെ കാര്യത്തിൽ ഒരു മെമ്മറി ലീക്ക് സംഭവിക്കും. llvm-stress.cpp 692
• V1023 [CWE-460] 'എംപ്ലേസ്_ബാക്ക്' രീതി ഉപയോഗിച്ച് 'മോഡിഫയേഴ്‌സ്' കണ്ടെയ്‌നറിലേക്ക് ഉടമയില്ലാത്ത ഒരു പോയിന്റർ ചേർക്കുന്നു. ഒരു ഒഴിവാക്കലിന്റെ കാര്യത്തിൽ ഒരു മെമ്മറി ലീക്ക് സംഭവിക്കും. llvm-stress.cpp 693
• V1023 [CWE-460] 'എംപ്ലേസ്_ബാക്ക്' രീതി ഉപയോഗിച്ച് 'മോഡിഫയേഴ്‌സ്' കണ്ടെയ്‌നറിലേക്ക് ഉടമയില്ലാത്ത ഒരു പോയിന്റർ ചേർക്കുന്നു. ഒരു ഒഴിവാക്കലിന്റെ കാര്യത്തിൽ ഒരു മെമ്മറി ലീക്ക് സംഭവിക്കും. 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 മുന്നറിയിപ്പുകൾ നൽകി, തുടർന്ന് നിർത്തി. LLVM-ൽ PVS-Studio അനലൈസർ കണ്ടെത്തുന്ന മറ്റ് തകരാറുകൾ ഉണ്ടോ? അതെ, എനിക്കുണ്ട്. എന്നിരുന്നാലും, ഞാൻ ലേഖനത്തിനായി കോഡ് ശകലങ്ങൾ എഴുതുമ്പോൾ, അത് വൈകുന്നേരമോ രാത്രിയോ ആയിരുന്നു, അത് ഒരു ദിവസം എന്ന് വിളിക്കേണ്ട സമയമാണെന്ന് ഞാൻ തീരുമാനിച്ചു.

നിങ്ങൾക്ക് ഇത് രസകരമായി തോന്നിയെന്നും PVS-Studio അനലൈസർ പരീക്ഷിക്കാൻ ആഗ്രഹിക്കുമെന്നും ഞാൻ പ്രതീക്ഷിക്കുന്നു.

നിങ്ങൾക്ക് അനലൈസർ ഡൗൺലോഡ് ചെയ്യാനും മൈൻസ്വീപ്പർ കീ നേടാനും കഴിയും ഈ പേജ്.

ഏറ്റവും പ്രധാനമായി, സ്ഥിരമായ വിശകലനം പതിവായി ഉപയോഗിക്കുക. ഒറ്റത്തവണ പരിശോധനകൾ, സ്റ്റാറ്റിക് അനാലിസിസിന്റെ രീതിശാസ്ത്രം ജനകീയമാക്കാൻ ഞങ്ങൾ നടത്തിയതും പിവിഎസ്-സ്റ്റുഡിയോയും ഒരു സാധാരണ സാഹചര്യമല്ല.

നിങ്ങളുടെ കോഡിന്റെ ഗുണനിലവാരവും വിശ്വാസ്യതയും മെച്ചപ്പെടുത്തുന്നതിൽ ഭാഗ്യം!

ഇംഗ്ലീഷ് സംസാരിക്കുന്ന പ്രേക്ഷകരുമായി ഈ ലേഖനം പങ്കിടാൻ നിങ്ങൾ ആഗ്രഹിക്കുന്നുവെങ്കിൽ, വിവർത്തന ലിങ്ക് ഉപയോഗിക്കുക: Andrey Karpov. പിവിഎസ്-സ്റ്റുഡിയോ ഉപയോഗിച്ച് LLVM 8-ൽ ബഗുകൾ കണ്ടെത്തുന്നു.

അവലംബം: www.habr.com