PVS-Studio 분석기를 사용하여 LLVM 8에서 버그 찾기

PVS-Studio 분석기를 사용한 LLVM 프로젝트의 마지막 코드 검사 이후 8.0.0년 이상이 지났습니다. PVS-Studio 분석기가 여전히 오류와 잠재적인 취약점을 식별하는 최고의 도구인지 확인하겠습니다. 이를 위해 LLVM XNUMX 릴리스에서 새로운 오류를 확인하고 찾아보겠습니다.

작성해야 할 기사

솔직히 말해서 나는 이 글을 쓰고 싶지 않았다. 이미 여러 번 확인한 프로젝트에 대해 글을 쓰는 것은 흥미롭지 않습니다(1, 2, 3). 새로운 것에 대해 쓰는 것이 더 좋지만 선택의 여지가 없습니다.

LLVM의 새 버전이 출시되거나 업데이트될 때마다 Clang 정적 분석기, 우리는 메일로 다음과 같은 유형의 질문을 받습니다:

보세요, Clang 정적 분석기의 새 버전에서는 새로운 오류를 찾는 방법을 배웠습니다! PVS-Studio 사용의 관련성이 감소하고 있는 것 같습니다. Clang은 이전보다 더 많은 오류를 발견하고 PVS-Studio의 기능을 따라잡습니다. 이것에 대해 어떻게 생각하세요?

이에 대해 저는 항상 다음과 같이 대답하고 싶습니다.

우리도 한가로이 앉아 있지 않습니다! PVS-Studio 분석기의 기능이 크게 향상되었습니다. 그러니 걱정하지 마세요. 우리는 이전처럼 계속해서 이끌어 갈 것입니다.

불행히도 이것은 잘못된 대답입니다. 거기에는 증거가 없습니다. 그리고 그것이 바로 내가 지금 이 글을 쓰고 있는 이유이다. 그래서 LLVM 프로젝트를 다시 한번 확인해 보니 다양한 오류가 발견되었습니다. 이제 나에게 흥미로웠던 것들을 보여 드리겠습니다. Clang 정적 분석기는 이러한 오류를 찾을 수 없습니다(또는 Clang의 도움을 받아 이를 찾는 것이 매우 불편합니다). 하지만 우리는 할 수 있습니다. 게다가 나는 이 모든 오류를 어느 날 저녁에 발견하고 적었습니다.

그러나 기사를 작성하는 데 몇 주가 걸렸습니다. 나는 이 모든 것을 텍스트로 표현할 수 없었습니다 :).

그건 그렇고, 오류와 잠재적인 취약점을 식별하기 위해 PVS-Studio 분석기에서 어떤 기술이 사용되는지에 관심이 있다면 이에 대해 알아보는 것이 좋습니다. 노트.

신규 및 기존 진단

이미 언급한 바와 같이, 약 3년 전에 LLVM 프로젝트를 다시 한번 점검하여 발견된 오류를 수정했습니다. 이제 이 기사에서는 새로운 오류 배치를 제시할 것입니다. 새로운 버그가 발견된 이유는 무엇입니까? 여기에는 XNUMX가지 이유가 있습니다:

1. LLVM 프로젝트는 진화하고 있으며 기존 코드를 변경하고 새 코드를 추가하고 있습니다. 당연히 수정되고 작성된 코드에는 새로운 오류가 있습니다. 이는 정적 분석을 가끔 사용하지 않고 정기적으로 사용해야 함을 분명히 보여줍니다. 우리 기사에서는 PVS-Studio 분석기의 기능을 잘 보여 주지만 이는 코드 품질을 개선하고 오류 수정 비용을 줄이는 것과는 아무런 관련이 없습니다. 정적 코드 분석기를 정기적으로 사용하세요!
2. 기존 진단을 마무리하고 개선하고 있습니다. 따라서 분석기는 이전 스캔 중에 발견하지 못한 오류를 식별할 수 있습니다.
3. 2년 전에는 존재하지 않았던 새로운 진단 기능이 PVS-Studio에 등장했습니다. PVS-Studio의 발전을 명확하게 보여주기 위해 별도의 섹션에 강조 표시하기로 결정했습니다.

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.")'이 있습니다. 운영자. 자동 업그레이드.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

포인터의 경우 좌회전 null이면 경고가 발행되어야 합니다. 그러나 대신 이 동일한 null 포인터가 역참조됩니다. LHS->getAsString().

이는 아무도 오류를 테스트하지 않기 때문에 오류 핸들러에 오류가 숨겨져 있는 매우 일반적인 상황입니다. 정적 분석기는 사용 빈도에 관계없이 도달 가능한 모든 코드를 확인합니다. 이는 정적 분석이 다른 테스트 및 오류 방지 기술을 어떻게 보완하는지 보여주는 아주 좋은 예입니다.

유사한 포인터 처리 오류 우 바로 아래 코드에서 허용됩니다: 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'의 역참조가 발생할 수 있습니다. 잘못된 컴파일.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) {

루프가 시작되지 않는 것을 쉽게 알 수 있습니다. 이것도 버그라고 생각해서 코드를 다르게 작성해야 할 것 같습니다.

우리는 그 유명한 패리티 오브 에러(parity of error)를 만난 것 같습니다! 한 번의 실수로 다른 실수가 가려집니다 :).

조각 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] 널 포인터 'Test'의 역참조가 발생할 수 있습니다. 잘못된 컴파일.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 'Identifier->Type' 변수는 자신에게 할당됩니다. 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] 'switch' 문 검사를 고려하세요. 첫 번째 'case' 연산자가 누락되었을 수 있습니다. 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] nullptr에 대해 확인되기 전에 'ND' 포인터가 사용되었습니다. 줄 확인: 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] '~(Size - 1) << 1' 표현식 검사를 고려하세요. 32비트 유형으로의 후속 확장을 통해 64비트 값의 비트 이동. AArch64AddressingModes.h 260

버그가 아닐 수도 있으며 코드는 의도한 대로 정확하게 작동합니다. 하지만 이는 분명히 매우 의심스러운 곳이므로 확인이 필요합니다.

변수를 말해보자 크기 는 16이고 코드 작성자는 이를 변수로 가져오려고 계획했습니다. NImms 가치 :

1111111111111111111111111111111111111111111111111111111111100000

그러나 실제로 결과는 다음과 같습니다.

0000000000000000000000000000000011111111111111111111111111100000

사실 모든 계산은 32비트 부호 없는 유형을 사용하여 발생합니다. 그런 다음에만 이 32비트 부호 없는 유형은 다음과 같이 암시적으로 확장됩니다. uint64_t. 이 경우 최상위 비트는 XNUMX이 됩니다.

다음과 같이 상황을 해결할 수 있습니다.

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] 애플리케이션의 로직을 검사해 보세요. 'else' 키워드가 누락되었을 수 있습니다. AMDGPUAsmParser.cpp 5655

여기에는 실수가 없습니다. 첫 번째 블록 이후 if 로 끝나다 계속, 그렇다면 상관 없습니다. 키워드가 있습니다 그렇지 않으면 아니면. 어느 쪽이든 코드는 동일하게 작동합니다. 아직도 그리워 그렇지 않으면 코드를 더욱 불분명하고 위험하게 만듭니다. 만약 미래에 계속 사라지면 코드가 완전히 다르게 작동하기 시작합니다. 제 생각에는 추가하는 것이 더 낫다고 생각합니다 그렇지 않으면.

Fragment N20: 같은 유형의 오타 XNUMX개

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] = FeatureMap.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, 1664. MachOObjectFile.cpp XNUMX

나는 여기에 진짜 실수가 있다고 생각하지 않습니다. 불필요한 반복 할당일 뿐입니다. 그러나 여전히 실수입니다.

비슷하게 :

• V519 [CWE-563] 'B.NDesc' 변수에는 1488번 연속으로 값이 할당됩니다. 아마도 이것은 실수일 것이다. 라인 확인: 1489, 1489. llvm-nm.cpp XNUMX
• 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] 'Alignment' 변수에 값이 연속적으로 두 번 할당됩니다. 아마도 이것은 실수일 것이다. 라인 확인: 1158, 1160. LoadStoreVectorizer.cpp 1160

이것은 분명히 논리적 오류가 포함되어 있는 매우 이상한 코드입니다. 처음에는 변수 조정 조건에 따라 값이 할당됩니다. 그런 다음 할당이 다시 발생하지만 지금은 확인이 없습니다.

비슷한 상황은 여기에서 볼 수 있습니다:

• V519 [CWE-563] 'Effects' 변수에는 연속적으로 두 번 값이 할당됩니다. 아마도 이것은 실수일 것이다. 라인 확인: 152, 165. WebAssemblyRegStackify.cpp 165
• V519 [CWE-563] 'ExpectNoDerefChunk' 변수에는 4970번 연속으로 값이 할당됩니다. 아마도 이것은 실수일 것이다. 라인 확인: 4973, 4973. SemaType.cpp XNUMX

조각 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

확인하는 것은 의미가 없습니다. 변하기 쉬운 다음바이트 항상 값과 같지 않음 0 X 90, 이는 이전 확인에서 이어집니다. 이것은 일종의 논리적 오류입니다.

조각 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진수 값 XNUMX입니다. 시험 등록 번호 == 0xe 말이 안 되니까 만약에 등록번호 > 13, 그러면 함수 실행이 완료됩니다.

ID 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-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 교환원 호출로 끝남 return. 이에 따라 컨테이너 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;

그리고 실제로 이 코드는 접근할 수 없습니다. 모든 사례 스위치 교환원의 전화로 끝납니다 return. 그리고 이제 혼자서는 무의미해 하다 별로 무해해 보이지는 않네요! 아마도 가지 중 하나가 다음으로 끝나야 할 것입니다. 하다~에 없다. return?

조각 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 비트 마스크의 크기는 첫 번째 피연산자의 크기보다 작습니다. 이로 인해 더 높은 비트가 손실됩니다. 런타임Dyld.cpp 815

기능을 참고해주세요 getStubAlignment 반환 유형 부호. 함수가 값 8을 반환한다고 가정하고 표현식의 값을 계산해 보겠습니다.

~(getStubAlignment() - 1)

~(8u-1)

0xFFFFFFFF8u

이제 변수가 데이터 크기 64비트 unsigned 유형이 있습니다. DataSize 및 0xFFFFFFF8u 작업을 수행하면 0개의 상위 비트가 모두 8으로 재설정됩니다. 아마도 이것은 프로그래머가 원했던 것이 아닐 것입니다. 나는 그가 DataSize & XNUMXxFFFFFFFFFFFFFFFFXNUMXu를 계산하고 싶어했다고 생각합니다.

오류를 수정하려면 다음과 같이 작성해야 합니다.

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비트 곱셈 결과가 다음 유형으로 확장됩니다. size_t.

조각 N35: 복사-붙여넣기 실패

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

V778 [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] 'Size' 변수가 할당되었지만 기능이 끝날 때까지 사용되지 않습니다. 개체.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

그러한 오류로부터 자신을 보호하는 방법은 무엇입니까? 코드 검토에 더욱 주의를 기울이고 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' 메소드에 의해 'Strategies' 컨테이너에 추가됩니다. 예외가 발생하면 메모리 누수가 발생합니다. llvm-isel-fuzzer.cpp 58

다음과 같이 컨테이너 끝에 요소를 추가하려면 표준::벡터 > 넌 그냥 쓸 수 없어 xxx.push_back(새 X), 암시적인 변환이 없기 때문에 X* в 표준::unique_ptr.

일반적인 해결책은 다음과 같습니다. xxx.emplace_back(새 X)컴파일 이후: 메소드 emplace_back 인수에서 직접 요소를 생성하므로 명시적 생성자를 사용할 수 있습니다.

안전하지 않습니다. 벡터가 가득 차면 메모리가 다시 할당됩니다. 메모리 재할당 작업이 실패하여 예외가 발생할 수 있습니다. 표준::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] 소유자가 없는 포인터가 'emplace_back' 메소드를 통해 'AA' 컨테이너에 추가됩니다. 예외가 발생하면 메모리 누수가 발생합니다. AliasAnalytics.h 324
• V1023 [CWE-460] 소유자가 없는 포인터가 'emplace_back' 메소드에 의해 '항목' 컨테이너에 추가됩니다. 예외가 발생하면 메모리 누수가 발생합니다. DWARFDebugFrame.cpp 519
• V1023 [CWE-460] 소유자가 없는 포인터가 'emplace_back' 메소드에 의해 'AllEdges' 컨테이너에 추가됩니다. 예외가 발생하면 메모리 누수가 발생합니다. CFGMST.h 268
• V1023 [CWE-460] 소유자가 없는 포인터가 'emplace_back' 메소드에 의해 'VMaps' 컨테이너에 추가됩니다. 예외가 발생하면 메모리 누수가 발생합니다. SimpleLoopUnswitch.cpp 2012
• V1023 [CWE-460] 소유자가 없는 포인터가 'emplace_back' 메소드에 의해 'Records' 컨테이너에 추가됩니다. 예외가 발생하면 메모리 누수가 발생합니다. FDRLogBuilder.h 30
• V1023 [CWE-460] 소유자가 없는 포인터가 'emplace_back' 메소드에 의해 'PendingSubmodules' 컨테이너에 추가됩니다. 예외가 발생하면 메모리 누수가 발생합니다. ModuleMap.cpp 810
• V1023 [CWE-460] 소유자가 없는 포인터가 'emplace_back' 메소드에 의해 'Objects' 컨테이너에 추가됩니다. 예외가 발생하면 메모리 누수가 발생합니다. DebugMap.cpp 88
• V1023 [CWE-460] 소유자가 없는 포인터가 'emplace_back' 메소드에 의해 'Strategies' 컨테이너에 추가됩니다. 예외가 발생하면 메모리 누수가 발생합니다. 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] 소유자가 없는 포인터가 'emplace_back' 메소드를 통해 'Operands' 컨테이너에 추가됩니다. 예외가 발생하면 메모리 누수가 발생합니다. GlobalISelEmitter.cpp 1911
• V1023 [CWE-460] 소유자가 없는 포인터가 'emplace_back' 메소드에 의해 'Stash' 컨테이너에 추가됩니다. 예외가 발생하면 메모리 누수가 발생합니다. GlobalISelEmitter.cpp 2100
• V1023 [CWE-460] 소유자가 없는 포인터가 'emplace_back' 메소드를 통해 'Matchers' 컨테이너에 추가됩니다. 예외가 발생하면 메모리 누수가 발생합니다. GlobalISelEmitter.cpp 2702

결론

총 60번의 경고를 발령하고 중단했습니다. PVS-Studio 분석기가 LLVM에서 감지하는 다른 결함이 있습니까? 네, 있어요. 그러나 기사의 코드 조각을 작성하고 있을 때는 늦은 저녁, 아니 오히려 밤이었고, 이제는 하루라고 부를 시간이라고 결정했습니다.

이 내용이 흥미로우셨기를 바라며 PVS-Studio 분석기를 사용해 보시길 바랍니다.

분석기를 다운로드하고 지뢰찾기 키를 얻을 수 있습니다. 이 페이지.

가장 중요한 것은 정적 분석을 정기적으로 사용하는 것입니다. 일회성 확인, 정적 분석 방법론을 대중화하기 위해 우리가 수행하는 PVS-Studio는 일반적인 시나리오가 아닙니다.

코드의 품질과 안정성을 향상시키는 데 행운이 있기를 바랍니다!

이 기사를 영어권 청중과 공유하려면 번역 링크인 Andrey Karpov를 사용하십시오. PVS-Studio를 사용하여 LLVM 8에서 버그 찾기.

출처 : habr.com