Skip to content

Conversation

@cabbaken
Copy link
Contributor

@cabbaken cabbaken commented Feb 10, 2025

Add Section Header check for getBuildID, fix crash with invalid Program Header.

Fixes: #126418

@llvmbot
Copy link
Member

llvmbot commented Feb 10, 2025

@llvm/pr-subscribers-debuginfo

@llvm/pr-subscribers-llvm-binary-utilities

Author: Ruoyu Qiu (cabbaken)

Changes

Add Section Header check for getBuildID, fix crash with invalid Program Header.


Full diff: https://github.com/llvm/llvm-project/pull/126537.diff

1 Files Affected:

  • (modified) llvm/lib/Object/BuildID.cpp (+16)
diff --git a/llvm/lib/Object/BuildID.cpp b/llvm/lib/Object/BuildID.cpp
index 89d6bc3ab550db8..8bb15c89e02e884 100644
--- a/llvm/lib/Object/BuildID.cpp
+++ b/llvm/lib/Object/BuildID.cpp
@@ -24,6 +24,22 @@ using namespace llvm::object;
 namespace {
 
 template <typename ELFT> BuildIDRef getBuildID(const ELFFile<ELFT> &Obj) {
+  auto ShdrsOrErr = Obj.sections();
+  if (!ShdrsOrErr) {
+    consumeError(ShdrsOrErr.takeError());
+    return {};
+  }
+  for (const auto &S : *ShdrsOrErr) {
+    if (S.sh_type != ELF::SHT_NOTE)
+      continue;
+    Error Err = Error::success();
+    for (auto N : Obj.notes(S, Err))
+      if (N.getType() == ELF::NT_GNU_BUILD_ID &&
+          N.getName() == ELF::ELF_NOTE_GNU)
+        return N.getDesc(S.sh_addralign);
+    consumeError(std::move(Err));
+  }
+
   auto PhdrsOrErr = Obj.program_headers();
   if (!PhdrsOrErr) {
     consumeError(PhdrsOrErr.takeError());

@cabbaken
Copy link
Contributor Author

I referred related logic of llvm-readelf which can correctly read the malformed program header, so I think the Section Header check is necessary.
Please let me know if there are additional considerations to be aware of.

@cabbaken cabbaken changed the title [llvm-objdump][ELF]Add Shdr buildID check(#126418) [llvm-objdump][ELF]Add Shdr check for buildID(#126418) Feb 10, 2025
@cabbaken cabbaken changed the title [llvm-objdump][ELF]Add Shdr check for buildID(#126418) [llvm-objdump][ELF]Add Shdr check for getBuildID(#126418) Feb 10, 2025
Add Section Header check for getBuildID, fix crash
with invalid Program Header.

Signed-off-by: Ruoyu Qiu <[email protected]>
@cabbaken cabbaken changed the title [llvm-objdump][ELF]Add Shdr check for getBuildID(#126418) [llvm]Add Shdr check for getBuildID(#126418) Feb 10, 2025
@cabbaken cabbaken changed the title [llvm]Add Shdr check for getBuildID(#126418) [llvm][ELF]Add Shdr check for getBuildID(#126418) Feb 11, 2025
@cabbaken cabbaken marked this pull request as draft February 11, 2025 06:24
@cabbaken
Copy link
Contributor Author

cabbaken commented Feb 11, 2025

This patch modifies a shared cpp file that makes llvm-symbolizer crash, I will fix it soon.

Add Aligh check to avoid crashing if Aligh is 0.

Signed-off-by: Ruoyu Qiu <[email protected]>
@cabbaken cabbaken marked this pull request as ready for review February 11, 2025 08:34
Copy link
Collaborator

@jh7370 jh7370 left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Don't include the issue reference in the PR/commit title: there's no need, because you mentioned it in the body.

This PR appears to be missing tests?

@cabbaken
Copy link
Contributor Author

Don't include the issue reference in the PR/commit title: there's no need, because you mentioned it in the body.

ok, I will modify it.

This PR appears to be missing tests?

Yes, I am trying to construct a test, but I need to learn some basic syntax of the test-suite. I will add the test later.

@cabbaken cabbaken changed the title [llvm][ELF]Add Shdr check for getBuildID(#126418) [llvm][ELF]Add Shdr check for getBuildID Feb 12, 2025
@github-actions
Copy link

github-actions bot commented Feb 12, 2025

✅ With the latest revision this PR passed the C/C++ code formatter.

avoid crashing of getDesc().

Signed-off-by: Ruoyu Qiu <[email protected]>
Signed-off-by: Ruoyu Qiu <[email protected]>
Copy link
Collaborator

@jh7370 jh7370 left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

The code change now looks good to me, but I think you need a test case for the new behaviour. This test should fail without your code change and pass with it.

Also, does this fix the crash from the original input in the bug?

@cabbaken
Copy link
Contributor Author

The code change now looks good to me, but I think you need a test case for the new behaviour. This test should fail without your code change and pass with it.

I will add the test file in the next commit, I'm working on it now.

Also, does this fix the crash from the original input in the bug?

Yes, I tested that and it works properly!

@cabbaken
Copy link
Contributor Author

cabbaken commented Mar 6, 2025

Could you do a merge commit from main into your branch, to see if it fixes the issues that the pre-merge tests were highlighting before, please? (Once you've fixed the yaml2obj issue anyway)

That’s exactly what I planned to do.

You're touching on a whole can of worms there, as there are many different testing philosophies that suggest you should or shouldn't have cases that test lower-level function behaviours. For example, if you were to write your tests without knowing what code it uses under the hood, you would write a whole suite of tests that cover various edge cases that might actually end up testing the same cases as are tested elsewhere.

In this case though, I agree it probably makes sense to avoid additional tests for that specific case IF there are already existing tests that cover that behaviour.

Got it!
So my only task now is to fix yaml2obj and verify that this PR passes the checks, right?

@jh7370
Copy link
Collaborator

jh7370 commented Mar 6, 2025

So my only task now is to fix yaml2obj and verify that this PR passes the checks, right?

That and check that there is boundary condition testing already.

jh7370 pushed a commit that referenced this pull request Sep 18, 2025
yaml2obj should determine the program header offset (and other
properties) based on the intended values rather than the final
`sh_offset` of the section header.

`setProgramHeaderLayout` uses section offsets for determining
`p_offset`. Move section header overriding after
`setProgramHeaderLayout` to prevent `ShOffset` from affecting program
header `p_offset`.

This change adjusts the timing of when the section header is overridden
to ensure that the program headers are set correctly.

More details
[here](#126537 (comment)).

---------

Signed-off-by: Ruoyu Qiu <[email protected]>
Signed-off-by: Ruoyu Qiu <[email protected]>
Co-authored-by: Ruoyu Qiu <[email protected]>
@cabbaken
Copy link
Contributor Author

Theoretically, this should pass the check after the merge of 130942.
How to restart a check? Should I just click the "Update branch" button?

llvm-sync bot pushed a commit to arm/arm-toolchain that referenced this pull request Sep 18, 2025
…#130942)

yaml2obj should determine the program header offset (and other
properties) based on the intended values rather than the final
`sh_offset` of the section header.

`setProgramHeaderLayout` uses section offsets for determining
`p_offset`. Move section header overriding after
`setProgramHeaderLayout` to prevent `ShOffset` from affecting program
header `p_offset`.

This change adjusts the timing of when the section header is overridden
to ensure that the program headers are set correctly.

More details
[here](llvm/llvm-project#126537 (comment)).

---------

Signed-off-by: Ruoyu Qiu <[email protected]>
Signed-off-by: Ruoyu Qiu <[email protected]>
Co-authored-by: Ruoyu Qiu <[email protected]>
@jh7370
Copy link
Collaborator

jh7370 commented Sep 18, 2025

Theoretically, this should pass the check after the merge of 130942. How to restart a check? Should I just click the "Update branch" button?

Yes, I'd do that. I believe the "Update branch" button just does a merge from main.

@cabbaken
Copy link
Contributor Author

That and check that there is boundary condition testing already.

It's passed the check now~

@jh7370
Copy link
Collaborator

jh7370 commented Sep 19, 2025

That and check that there is boundary condition testing already.

It's passed the check now~

Did you check to see if there was any boundary condition testing for this case?

@cabbaken
Copy link
Contributor Author

Did you check to see if there was any boundary condition testing for this case?

I've added a unit test to ensure the function checks both the program header and the section header to retrieve the build ID.

To clarify, are you suggesting that I should also add an additional build ID check to the test file at llvm/test/DebugInfo/symbolize-build-id.test?

@jh7370
Copy link
Collaborator

jh7370 commented Sep 19, 2025

A boundary condition is checking that comparison is checking the right value and prevents off-by-one style errors (e.g. it shows that > is used instead of >= or similar, by failing when the value is exactly one bigger/smaller than it needs to be for the check to pass). I explained this in #126537 (comment).

We don't need to add a lit test, as previously discussed in the review.

@cabbaken
Copy link
Contributor Author

Thanks for the reminder about why an invalid program header causes llvm-objdump to crash.

What would be the best approach for the test? Should I add a new test case to llvm/test/tools/llvm-objdump/ELF/program-headers.test, or is it better to modify an existing one?

@jh7370
Copy link
Collaborator

jh7370 commented Sep 19, 2025

What would be the best approach for the test? Should I add a new test case to llvm/test/tools/llvm-objdump/ELF/program-headers.test, or is it better to modify an existing one?

I literally just said don't add a new lit test. You have an existing set of unit tests that you're adding in this patch. You could either add duplicates of them, or probably better, change them to test the edge values, instead of FileSize: 0xffffffffffffffff and ShOffset: 0x8000 (I don't not know what exactly those values should be, but they should be the value at which point it goes from a "valid" value to an "invalid" value).

@cabbaken
Copy link
Contributor Author

cabbaken commented Sep 22, 2025

After reading the unit test I wrote, I noticed something curious. In ELF.h:

 Elf_Note_Iterator notes_begin(const Elf_Phdr &Phdr, Error &Err) const {
   assert(Phdr.p_type == ELF::PT_NOTE && "Phdr is not of type PT_NOTE");
   ErrorAsOutParameter ErrAsOutParam(Err);
   if (Phdr.p_offset + Phdr.p_filesz > getBufSize()) {
     Err =
         createError("invalid offset (0x" + Twine::utohexstr(Phdr.p_offset) +
                     ") or size (0x" + Twine::utohexstr(Phdr.p_filesz) + ")");
     return Elf_Note_Iterator(Err);
   }

The p_filesz in the unit test is set to 0x0xffffffffffffffff. This cause Phdr.p_offset + Phdr.p_filesz to overflow, so return Elf_Note_Iterator(Err); is skipped. The unit test then "succeed" based on the overflow, but it may cause an invalid memory access if the elf has no buildID. For example:

--- !ELF
FileHeader:
  Class:          ELFCLASS64
  Data:           ELFDATA2LSB
  Type:           ET_EXEC
  Machine:        EM_X86_64
ProgramHeaders:
  - Type:         PT_NOTE
    FileSize:     0xffffffffffffffff
    FirstSec:     .note.gnu.build-id
    LastSec:      .note.gnu.build-id
Sections:
  - Name:         .note.gnu.build-id
    Type:         SHT_NOBITS
    AddressAlign: 0x04

Given this, I think we should avoid iterating over notes if the ELF has an invalid p_filesz. The large p_filesz value in the test is only meant to demonstrate that we detect the section header before the program header.

I'm sorry I was misunderstanding about this:

That the BuildID can be looked up from a section header, if there is no program header.
That the code handles a malformed program header that points at data outside the file.
That the code handles a malformed section header that points at data outside the file.

Modify boundary issue in test.

Signed-off-by: Ruoyu Qiu <[email protected]>
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Since these are independent of your wider change, they should be their own PR, with appropriate unit testing, I think.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This serves as an overflow check, and the unit test would fail without it. Do you think I should create a separate PR to merge this check first?

Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Yes, and I see you've put a PR up for it.

Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Same as above.

Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I'm not sure I follow why this is 0xffffffffffffff88 and not 0xffffffffffffffff like it was before (or indeed some other value that better tests the boundary limits).

Copy link
Contributor Author

@cabbaken cabbaken Sep 22, 2025

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

In ELF.h, we calculate Phdr.p_offset + Phdr.p_filesz. With p_offset = 0x78, adding it to 0xffffffffffffff88 causes an overflow (wrapping around to 0).
In this case, it effectively works as a boundary value.

Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Not what I had in mind, since I was referring to the original non-overflow checks (i.e. Phdr.p_offset + Phdr.p_filesz > getBufSize() and its section header equivalent). In other words, show that if Phdr.p_offset + Phdr.p_filesz == getBufSize() + 1, we get the error case (arguably there should be a separate test case where Phdr.p_offset + Phdr.p_filesz == getBufSize()). The same applies for the section header case.

Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Oh, I should add that the current case is a good way of testing the overflow boundary case in the other PR.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Oh, I should add that the current case is a good way of testing the overflow boundary case in the other PR.

Yes, the boundary value is intended for the overflow check.
In this PR, I’ll remove the unrelated parts so it focuses on its main subject.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Now that I add the boundary check in another PR, should I remove the boundary value here?

Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Please refer back to this comment above. I think that should mostly answer your question. It's enough to only check one of the paths there in this PR, because what you're after is test the behaviour when an error is encountered in the underlying code.

Copy link
Collaborator

@jh7370 jh7370 left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Looks good to me, once the other PR has been merged. Please update this PR once it has, and I'll give it one final look over.

Copy link
Collaborator

@jh7370 jh7370 left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

LGTM, thanks! Let me know once you want me to merge this for you.

@cabbaken
Copy link
Contributor Author

cabbaken commented Oct 3, 2025

Yes, please merge it. Thanks!

@jh7370 jh7370 merged commit 5cd3db3 into llvm:main Oct 3, 2025
9 checks passed
@llvm-ci
Copy link
Collaborator

llvm-ci commented Oct 3, 2025

LLVM Buildbot has detected a new failure on builder clang-m68k-linux-cross running on suse-gary-m68k-cross while building llvm at step 5 "ninja check 1".

Full details are available at: https://lab.llvm.org/buildbot/#/builders/27/builds/16977

Here is the relevant piece of the build log for the reference
Step 5 (ninja check 1) failure: stage 1 checked (failure)
...
[326/1195] Building CXX object tools/clang/unittests/CMakeFiles/AllClangUnitTests.dir/Tooling/RecursiveASTVisitorTests/LambdaTemplateParams.cpp.o
[327/1195] Building CXX object tools/clang/unittests/CMakeFiles/AllClangUnitTests.dir/Tooling/RecursiveASTVisitorTests/TemplateArgumentLocTraverser.cpp.o
[328/1195] Building CXX object tools/clang/unittests/CMakeFiles/AllClangUnitTests.dir/Tooling/RecursiveASTVisitorTests/TraversalScope.cpp.o
[329/1195] Building CXX object tools/clang/unittests/CMakeFiles/AllClangUnitTests.dir/Tooling/ReplacementsYamlTest.cpp.o
[330/1195] Building CXX object tools/clang/unittests/CMakeFiles/AllClangUnitTests.dir/Tooling/RecursiveASTVisitorTestTypeLocVisitor.cpp.o
[331/1195] Building CXX object tools/clang/unittests/CMakeFiles/AllClangUnitTests.dir/Tooling/RecursiveASTVisitorTestDeclVisitor.cpp.o
[332/1195] Building CXX object tools/clang/unittests/CMakeFiles/AllClangUnitTests.dir/Frontend/FixedPointString.cpp.o
[333/1195] Building CXX object tools/clang/unittests/CMakeFiles/AllClangUnitTests.dir/Tooling/RefactoringActionRulesTest.cpp.o
[334/1195] Building CXX object tools/clang/unittests/CMakeFiles/AllClangUnitTests.dir/Frontend/ParsedSourceLocationTest.cpp.o
[335/1195] Building CXX object tools/clang/unittests/CMakeFiles/AllClangUnitTests.dir/AST/ASTImporterTest.cpp.o
FAILED: tools/clang/unittests/CMakeFiles/AllClangUnitTests.dir/AST/ASTImporterTest.cpp.o 
/usr/bin/c++ -DGTEST_HAS_RTTI=0 -DLLVM_BUILD_STATIC -D_DEBUG -D_GLIBCXX_ASSERTIONS -D_GLIBCXX_USE_CXX11_ABI=1 -D_GNU_SOURCE -D__STDC_CONSTANT_MACROS -D__STDC_FORMAT_MACROS -D__STDC_LIMIT_MACROS -I/var/lib/buildbot/workers/suse-gary-m68k-cross/clang-m68k-linux-cross/stage1/tools/clang/unittests -I/var/lib/buildbot/workers/suse-gary-m68k-cross/clang-m68k-linux-cross/llvm/clang/unittests -I/var/lib/buildbot/workers/suse-gary-m68k-cross/clang-m68k-linux-cross/llvm/clang/include -I/var/lib/buildbot/workers/suse-gary-m68k-cross/clang-m68k-linux-cross/stage1/tools/clang/include -I/var/lib/buildbot/workers/suse-gary-m68k-cross/clang-m68k-linux-cross/stage1/include -I/var/lib/buildbot/workers/suse-gary-m68k-cross/clang-m68k-linux-cross/llvm/llvm/include -I/var/lib/buildbot/workers/suse-gary-m68k-cross/clang-m68k-linux-cross/llvm/clang/unittests/Tooling -I/var/lib/buildbot/workers/suse-gary-m68k-cross/clang-m68k-linux-cross/llvm/third-party/unittest/googletest/include -I/var/lib/buildbot/workers/suse-gary-m68k-cross/clang-m68k-linux-cross/llvm/third-party/unittest/googlemock/include -fPIC -fno-semantic-interposition -fvisibility-inlines-hidden -Werror=date-time -Wall -Wextra -Wno-unused-parameter -Wwrite-strings -Wcast-qual -Wno-missing-field-initializers -pedantic -Wno-long-long -Wimplicit-fallthrough -Wno-uninitialized -Wno-nonnull -Wno-class-memaccess -Wno-dangling-reference -Wno-redundant-move -Wno-pessimizing-move -Wno-array-bounds -Wno-stringop-overread -Wno-noexcept-type -Wdelete-non-virtual-dtor -Wsuggest-override -Wno-comment -Wno-misleading-indentation -Wctad-maybe-unsupported -fdiagnostics-color -ffunction-sections -fdata-sections -fno-common -Woverloaded-virtual -O3 -DNDEBUG -std=c++17  -Wno-variadic-macros -fno-exceptions -funwind-tables -fno-rtti -UNDEBUG -Wno-suggest-override -MD -MT tools/clang/unittests/CMakeFiles/AllClangUnitTests.dir/AST/ASTImporterTest.cpp.o -MF tools/clang/unittests/CMakeFiles/AllClangUnitTests.dir/AST/ASTImporterTest.cpp.o.d -o tools/clang/unittests/CMakeFiles/AllClangUnitTests.dir/AST/ASTImporterTest.cpp.o -c /var/lib/buildbot/workers/suse-gary-m68k-cross/clang-m68k-linux-cross/llvm/clang/unittests/AST/ASTImporterTest.cpp
c++: fatal error: Killed signal terminated program cc1plus
compilation terminated.
[336/1195] Building CXX object tools/clang/unittests/CMakeFiles/AllClangUnitTests.dir/Frontend/CodeGenActionTest.cpp.o
[337/1195] Building CXX object tools/clang/unittests/CMakeFiles/AllClangUnitTests.dir/Tooling/RefactoringCallbacksTest.cpp.o
[338/1195] Building CXX object tools/clang/unittests/CMakeFiles/AllClangUnitTests.dir/Tooling/Syntax/TreeTestBase.cpp.o
[339/1195] Building CXX object tools/clang/unittests/CMakeFiles/AllClangUnitTests.dir/Tooling/Syntax/MutationsTest.cpp.o
[340/1195] Building CXX object tools/clang/unittests/CMakeFiles/AllClangUnitTests.dir/Frontend/FrontendActionTest.cpp.o
[341/1195] Building CXX object tools/clang/unittests/CMakeFiles/AllClangUnitTests.dir/Tooling/RecursiveASTVisitorTests/CallbacksLeaf.cpp.o
[342/1195] Building CXX object tools/clang/unittests/CMakeFiles/AllClangUnitTests.dir/Tooling/RecursiveASTVisitorTests/InitListExprPostOrder.cpp.o
[343/1195] Building CXX object tools/clang/unittests/CMakeFiles/AllClangUnitTests.dir/Tooling/RecursiveASTVisitorTests/InitListExprPostOrderNoQueue.cpp.o
[344/1195] Building CXX object tools/clang/unittests/CMakeFiles/AllClangUnitTests.dir/Frontend/ASTUnitTest.cpp.o
[345/1195] Building CXX object tools/clang/unittests/CMakeFiles/AllClangUnitTests.dir/Frontend/ReparseWorkingDirTest.cpp.o
[346/1195] Building CXX object tools/clang/unittests/CMakeFiles/AllClangUnitTests.dir/Tooling/Syntax/SynthesisTest.cpp.o
[347/1195] Building CXX object tools/clang/unittests/CMakeFiles/AllClangUnitTests.dir/Tooling/Syntax/TreeTest.cpp.o
[348/1195] Building CXX object tools/clang/unittests/CMakeFiles/AllClangUnitTests.dir/Frontend/PCHPreambleTest.cpp.o
[349/1195] Building CXX object tools/clang/unittests/CMakeFiles/AllClangUnitTests.dir/Tooling/RecursiveASTVisitorTests/CallbacksCompoundAssignOperator.cpp.o
[350/1195] Building CXX object tools/clang/unittests/CMakeFiles/AllClangUnitTests.dir/Frontend/OutputStreamTest.cpp.o
[351/1195] Building CXX object tools/clang/unittests/CMakeFiles/AllClangUnitTests.dir/Tooling/SourceCodeBuildersTest.cpp.o
[352/1195] Building CXX object tools/clang/unittests/CMakeFiles/AllClangUnitTests.dir/Frontend/CompilerInstanceTest.cpp.o
[353/1195] Building CXX object tools/clang/unittests/CMakeFiles/AllClangUnitTests.dir/Tooling/RefactoringTest.cpp.o
[354/1195] Building CXX object tools/clang/unittests/CMakeFiles/AllClangUnitTests.dir/Tooling/RecursiveASTVisitorTests/CallbacksUnaryOperator.cpp.o
[355/1195] Building CXX object tools/clang/unittests/CMakeFiles/AllClangUnitTests.dir/Tooling/RecursiveASTVisitorTestPostOrderVisitor.cpp.o
[356/1195] Building CXX object tools/clang/unittests/CMakeFiles/AllClangUnitTests.dir/Frontend/SearchPathTest.cpp.o
[357/1195] Building CXX object tools/clang/unittests/CMakeFiles/AllClangUnitTests.dir/Tooling/RecursiveASTVisitorTests/CallbacksCallExpr.cpp.o
[358/1195] Building CXX object tools/clang/unittests/CMakeFiles/AllClangUnitTests.dir/Frontend/CompilerInvocationTest.cpp.o
[359/1195] Building CXX object tools/clang/unittests/CMakeFiles/AllClangUnitTests.dir/Tooling/RecursiveASTVisitorTests/CallbacksBinaryOperator.cpp.o
[360/1195] Building CXX object tools/clang/unittests/CMakeFiles/AllClangUnitTests.dir/ASTMatchers/ASTMatchersNarrowingTest.cpp.o
[361/1195] Building CXX object tools/clang/unittests/CMakeFiles/AllClangUnitTests.dir/Tooling/Syntax/BuildTreeTest.cpp.o
[362/1195] Building CXX object tools/clang/unittests/CMakeFiles/AllClangUnitTests.dir/Tooling/SourceCodeTest.cpp.o
[363/1195] Building CXX object tools/clang/unittests/CMakeFiles/AllClangUnitTests.dir/Tooling/ToolingTest.cpp.o
[364/1195] Building CXX object tools/clang/unittests/CMakeFiles/AllClangUnitTests.dir/Tooling/StencilTest.cpp.o
[365/1195] Building CXX object tools/clang/unittests/CMakeFiles/AllClangUnitTests.dir/Frontend/NoAlterCodeGenActionTest.cpp.o
[366/1195] Building CXX object tools/clang/unittests/CMakeFiles/AllClangUnitTests.dir/Tooling/Syntax/TokensTest.cpp.o
[367/1195] Building CXX object tools/clang/unittests/CMakeFiles/AllClangUnitTests.dir/ASTMatchers/ASTMatchersTraversalTest.cpp.o
[368/1195] Building CXX object tools/clang/unittests/CMakeFiles/AllClangUnitTests.dir/Tooling/TransformerTest.cpp.o
ninja: build stopped: subcommand failed.

@llvm-ci
Copy link
Collaborator

llvm-ci commented Oct 3, 2025

LLVM Buildbot has detected a new failure on builder sanitizer-x86_64-linux-android running on sanitizer-buildbot-android while building llvm at step 2 "annotate".

Full details are available at: https://lab.llvm.org/buildbot/#/builders/186/builds/12892

Here is the relevant piece of the build log for the reference
Step 2 (annotate) failure: 'python ../sanitizer_buildbot/sanitizers/zorg/buildbot/builders/sanitizers/buildbot_selector.py' (failure)
...
[       OK ] AddressSanitizer.AtoiAndFriendsOOBTest (2247 ms)
[ RUN      ] AddressSanitizer.HasFeatureAddressSanitizerTest
[       OK ] AddressSanitizer.HasFeatureAddressSanitizerTest (0 ms)
[ RUN      ] AddressSanitizer.CallocReturnsZeroMem
[       OK ] AddressSanitizer.CallocReturnsZeroMem (30 ms)
[ DISABLED ] AddressSanitizer.DISABLED_TSDTest
[ RUN      ] AddressSanitizer.IgnoreTest
[       OK ] AddressSanitizer.IgnoreTest (0 ms)
[ RUN      ] AddressSanitizer.SignalTest
[       OK ] AddressSanitizer.SignalTest (196 ms)
[ RUN      ] AddressSanitizer.ReallocTest
[       OK ] AddressSanitizer.ReallocTest (27 ms)
[ RUN      ] AddressSanitizer.WrongFreeTest
[       OK ] AddressSanitizer.WrongFreeTest (132 ms)
[ RUN      ] AddressSanitizer.LongJmpTest
[       OK ] AddressSanitizer.LongJmpTest (0 ms)
[ RUN      ] AddressSanitizer.ThreadStackReuseTest
[       OK ] AddressSanitizer.ThreadStackReuseTest (9 ms)
[ DISABLED ] AddressSanitizer.DISABLED_MemIntrinsicUnalignedAccessTest
[ DISABLED ] AddressSanitizer.DISABLED_LargeFunctionSymbolizeTest
[ DISABLED ] AddressSanitizer.DISABLED_MallocFreeUnwindAndSymbolizeTest
[ RUN      ] AddressSanitizer.UseThenFreeThenUseTest
[       OK ] AddressSanitizer.UseThenFreeThenUseTest (118 ms)
[ RUN      ] AddressSanitizer.FileNameInGlobalReportTest
[       OK ] AddressSanitizer.FileNameInGlobalReportTest (116 ms)
[ DISABLED ] AddressSanitizer.DISABLED_StressStackReuseAndExceptionsTest
[ RUN      ] AddressSanitizer.MlockTest
[       OK ] AddressSanitizer.MlockTest (0 ms)
[ DISABLED ] AddressSanitizer.DISABLED_DemoThreadedTest
[ DISABLED ] AddressSanitizer.DISABLED_DemoStackTest
[ DISABLED ] AddressSanitizer.DISABLED_DemoThreadStackTest
[ DISABLED ] AddressSanitizer.DISABLED_DemoUAFLowIn
[ DISABLED ] AddressSanitizer.DISABLED_DemoUAFLowLeft
[ DISABLED ] AddressSanitizer.DISABLED_DemoUAFLowRight
[ DISABLED ] AddressSanitizer.DISABLED_DemoUAFHigh
[ DISABLED ] AddressSanitizer.DISABLED_DemoOOM
[ DISABLED ] AddressSanitizer.DISABLED_DemoDoubleFreeTest
[ DISABLED ] AddressSanitizer.DISABLED_DemoNullDerefTest
[ DISABLED ] AddressSanitizer.DISABLED_DemoFunctionStaticTest
[ DISABLED ] AddressSanitizer.DISABLED_DemoTooMuchMemoryTest
[ RUN      ] AddressSanitizer.LongDoubleNegativeTest
[       OK ] AddressSanitizer.LongDoubleNegativeTest (0 ms)
[----------] 19 tests from AddressSanitizer (27894 ms total)

[----------] Global test environment tear-down
[==========] 22 tests from 2 test suites ran. (27913 ms total)
[  PASSED  ] 22 tests.

  YOU HAVE 1 DISABLED TEST

Step 34 (run instrumented asan tests [aarch64/bluejay-userdebug/TQ3A.230805.001]) failure: run instrumented asan tests [aarch64/bluejay-userdebug/TQ3A.230805.001] (failure)
...
[ RUN      ] AddressSanitizer.HasFeatureAddressSanitizerTest
[       OK ] AddressSanitizer.HasFeatureAddressSanitizerTest (0 ms)
[ RUN      ] AddressSanitizer.CallocReturnsZeroMem
[       OK ] AddressSanitizer.CallocReturnsZeroMem (30 ms)
[ DISABLED ] AddressSanitizer.DISABLED_TSDTest
[ RUN      ] AddressSanitizer.IgnoreTest
[       OK ] AddressSanitizer.IgnoreTest (0 ms)
[ RUN      ] AddressSanitizer.SignalTest
[       OK ] AddressSanitizer.SignalTest (196 ms)
[ RUN      ] AddressSanitizer.ReallocTest
[       OK ] AddressSanitizer.ReallocTest (27 ms)
[ RUN      ] AddressSanitizer.WrongFreeTest
[       OK ] AddressSanitizer.WrongFreeTest (132 ms)
[ RUN      ] AddressSanitizer.LongJmpTest
[       OK ] AddressSanitizer.LongJmpTest (0 ms)
[ RUN      ] AddressSanitizer.ThreadStackReuseTest
[       OK ] AddressSanitizer.ThreadStackReuseTest (9 ms)
[ DISABLED ] AddressSanitizer.DISABLED_MemIntrinsicUnalignedAccessTest
[ DISABLED ] AddressSanitizer.DISABLED_LargeFunctionSymbolizeTest
[ DISABLED ] AddressSanitizer.DISABLED_MallocFreeUnwindAndSymbolizeTest
[ RUN      ] AddressSanitizer.UseThenFreeThenUseTest
[       OK ] AddressSanitizer.UseThenFreeThenUseTest (118 ms)
[ RUN      ] AddressSanitizer.FileNameInGlobalReportTest
[       OK ] AddressSanitizer.FileNameInGlobalReportTest (116 ms)
[ DISABLED ] AddressSanitizer.DISABLED_StressStackReuseAndExceptionsTest
[ RUN      ] AddressSanitizer.MlockTest
[       OK ] AddressSanitizer.MlockTest (0 ms)
[ DISABLED ] AddressSanitizer.DISABLED_DemoThreadedTest
[ DISABLED ] AddressSanitizer.DISABLED_DemoStackTest
[ DISABLED ] AddressSanitizer.DISABLED_DemoThreadStackTest
[ DISABLED ] AddressSanitizer.DISABLED_DemoUAFLowIn
[ DISABLED ] AddressSanitizer.DISABLED_DemoUAFLowLeft
[ DISABLED ] AddressSanitizer.DISABLED_DemoUAFLowRight
[ DISABLED ] AddressSanitizer.DISABLED_DemoUAFHigh
[ DISABLED ] AddressSanitizer.DISABLED_DemoOOM
[ DISABLED ] AddressSanitizer.DISABLED_DemoDoubleFreeTest
[ DISABLED ] AddressSanitizer.DISABLED_DemoNullDerefTest
[ DISABLED ] AddressSanitizer.DISABLED_DemoFunctionStaticTest
[ DISABLED ] AddressSanitizer.DISABLED_DemoTooMuchMemoryTest
[ RUN      ] AddressSanitizer.LongDoubleNegativeTest
[       OK ] AddressSanitizer.LongDoubleNegativeTest (0 ms)
[----------] 19 tests from AddressSanitizer (27894 ms total)

[----------] Global test environment tear-down
[==========] 22 tests from 2 test suites ran. (27913 ms total)
[  PASSED  ] 22 tests.

  YOU HAVE 1 DISABLED TEST
program finished with exit code 0
elapsedTime=2306.511453

MixedMatched pushed a commit to MixedMatched/llvm-project that referenced this pull request Oct 3, 2025
Add Section Header check for getBuildID, fix crash with invalid Program
Header.

Fixes: llvm#126418

---------

Signed-off-by: Ruoyu Qiu <[email protected]>
Signed-off-by: Ruoyu Qiu <[email protected]>
Co-authored-by: Ruoyu Qiu <[email protected]>
Co-authored-by: James Henderson <[email protected]>
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Projects

None yet

Development

Successfully merging this pull request may close these issues.

llvm-objdump crashed

5 participants