/usr/bin/ld.gold: fatal error: LLVM gold plugin: <unknown>:0: Undefined temporary symbol .Ltmp265928 #48
Comments
|
I was compiling OSS-Fuzz myself, but I see that something was merged upstream. Does it need a bump in this repo, like #25 ? |
|
atm there are two different patches going on: the local ones from here and the ones already pushed to OSS-Fuzz. Ideally the patch we have here should be removed in favour of using the patches in upsteam OSS-Fuzz. I haven't looked at doing this yet, but am not sure if the upstream OSS-Fuzz patches are fully working with a local set up -- @Navidem there were some issues with running the fuzz-introspector set up in OSS-Fuzz locally, is this fixed? For that reason I think it shouldn't be bumped atm because it will mix the two patches together, which will inevitably fail. There were two major things changed recently in the compiler plugin: (1) we updated to latest LLVM version and new plugin manager, and (2) we add a global variable as a tag in the binary (this is a "major" change since it means now we add content to the module whereas previously we just observed). This issue could be related to that, potentially. |
For local set-up we have to use build_patched_oss_fuzz.sh. I just tried |
|
I was trying latest |
|
Thanks! Let me know how it works -- I will also see if I can identify if the patching it now does can be the cause of this issue |
|
Along with my previous comment, I also gave a try bitcoin-core on the latest commit today: 34de464 (by applying the patches locally), and it went on successfully as well. I can see the fuzzers running... |
|
Sorry for being unclear, let me provide exact steps to reproduce. My understanding is that the rust image is not yet built for introspector, thus an additional OSS-Fuzz patch is needed to change the image: diff --git a/projects/bitcoin-core/Dockerfile b/projects/bitcoin-core/Dockerfile
index 61972719..6a2040a3 100644
--- a/projects/bitcoin-core/Dockerfile
+++ b/projects/bitcoin-core/Dockerfile
@@ -14,7 +14,7 @@
#
################################################################################
-FROM gcr.io/oss-fuzz-base/base-builder-rust
+FROM gcr.io/oss-fuzz-base/base-builder
# Packages taken from:
# * https://github.com/bitcoin/bitcoin/blob/master/doc/build-unix.md#dependency-build-instructions
diff --git a/projects/bitcoin-core/build.sh b/projects/bitcoin-core/build.sh
index 5c6ac475..3d644e83 100755
--- a/projects/bitcoin-core/build.sh
+++ b/projects/bitcoin-core/build.sh
@@ -15,7 +15,6 @@
#
################################################################################
-$SRC/build_cryptofuzz.sh
cd $SRC/bitcoin-core/
@@ -29,7 +28,8 @@ fi
(
cd depends
sed -i --regexp-extended '/.*rm -rf .*extract_dir.*/d' ./funcs.mk # Keep extracted source
- make HOST=$BUILD_TRIPLET DEBUG=1 NO_QT=1 NO_WALLET=1 NO_ZMQ=1 NO_UPNP=1 NO_NATPMP=1 boost_cxxflags="-std=c++17 -fvisibility=hidden -fPIC ${CXXFLAGS}" libevent_cflags="${CFLAGS}" -j$(nproc)
+ make HOST=$BUILD_TRIPLET NO_QT=1 NO_BDB=1 NO_ZMQ=1 NO_UPNP=1 NO_NATPMP=1 libevent_cflags="${CFLAGS}" sqlite_cflags="${CFLAGS}" -j$(nproc)
+ # DEBUG=1 is temporarily disabled due to libc++ bugs
)
# Build the fuzz targets
@@ -39,6 +39,9 @@ sed -i "s|PROVIDE_FUZZ_MAIN_FUNCTION|NEVER_PROVIDE_MAIN_FOR_OSS_FUZZ|g" "./confi
# Temporarily compile with O2 to work around clang-13 (and later) UBSan
# -fsanitize=vptr,object-size false positive that only happens with -O1
+# Fixed in https://github.com/llvm/llvm-project/commit/bbeaf2aac678
+# However, OSS-Fuzz is stuck on a buggy clang, so the workaround is still
+# needed. See https://github.com/google/oss-fuzz/pull/7140
if [ "$SANITIZER" = "undefined" ]; then
export CFLAGS="$CFLAGS -O2"
export CXXFLAGS="$CXXFLAGS -O2"
@@ -79,14 +82,14 @@ fi
# An alternative to mocking the string in the finished binary would be to
# replace the string in the source code and re-invoke 'make'. This is slower,
# so use the hack.
-export MAGIC_STR="b5813eee2abc9d3358151f298b75a72264ffa119d2f71ae7fefa15c4b70b4bc5b38e87e3107a730f25891ea428b2b4fabe7a84f5bfa73c79e0479e085e4ff157"
-sed -i "s|.*std::getenv(\"FUZZ\").*|std::string fuzz_target{\"$MAGIC_STR\"};|g" "./src/test/fuzz/fuzz.cpp"
-sed -i "s|.find(fuzz_target)|.find(fuzz_target.c_str())|g" "./src/test/fuzz/fuzz.cpp"
-make -j$(nproc)
-
# Replace the magic string with the actual name of each fuzz target
for fuzz_target in ${FUZZ_TARGETS[@]}; do
- python3 -c "c_str_target=b\"${fuzz_target}\x00\";c_str_magic=b\"$MAGIC_STR\";c=open('./src/test/fuzz/fuzz','rb').read();c=c.replace(c_str_magic, c_str_target+c_str_magic[len(c_str_target):]);open(\"$OUT/$fuzz_target\",'wb').write(c)"
+ git checkout -- "./src/test/fuzz/fuzz.cpp"
+ sed -i "s|.*std::getenv(\"FUZZ\").*|std::string fuzz_target{\"$fuzz_target\"};|g" "./src/test/fuzz/fuzz.cpp"
+ sed -i "s|.find(fuzz_target)|.find(fuzz_target.c_str())|g" "./src/test/fuzz/fuzz.cpp"
+ make -j$(nproc)
+ mv './src/test/fuzz/fuzz' "$OUT/$fuzz_target"
+
chmod +x "$OUT/$fuzz_target"
(
cd assets/fuzz_seed_corpusYou can then run a slightly faster build by selecting the "CI build": This will give the above failure. |
|
I am seeing this same issue in |
|
In the |
|
The error message seems to come from here: The global variable we add for tagging purposes is here: fuzz-introspector/llvm/lib/Transforms/FuzzIntrospector/FuzzIntrospector.cpp Lines 275 to 281 in 2ced5a3 I think the issue happens because the linkage One possible solution may be to change the linkage, to either some form or This does not seem to be the issue: if I comment out the code that adds the global variable I still run into the issue in |
|
Update on |
|
@MarcoFalke did you see any differences following the linker merge? I think this error is not due to fuzz-introspector following the comments above. It seemed to be related to something in latest LLVM itself. Specifically, the issue occurred even without introspector for another project, and the error message seem to come from a place in the LLVM code that is distant to fuzz-introspector code https://github.com/llvm/llvm-project/blob/26bbde2612b2042c3a8a31aed7f45e065c3dd413/llvm/lib/MC/ELFObjectWriter.cpp#L638-L641 |
|
Sure, happy to take another look. I see there were some changes in the oss-fuzz repo and here, so I am wondering what is the best way to build fuzz-introspector right now? Start from the oss-fuzz repo or start from this repo? |
|
One option that let's you avoid building the images yourself is to pull the latest oss-fuzz fuzz-introspector base-clang image. I am still in the process of updating the docs, but following this thread you can see details: #67 (comment) Note that updating the docs is on my to-do list so it should hopefully be done in the near future. |
|
Ok, I tried to run: It fails with: |
This is to make sure fuzz-introspector can run in local builds. Ref: ossf/fuzz-introspector#48 (comment) Ref: ossf/fuzz-introspector#67 (comment)
|
Thanks @MarcoFalke -- I'm on it, will let you know here once it's resolved. |
* infra: fuzz-introspector: ensure COVERAGE_URL exists This is to make sure fuzz-introspector can run in local builds. Ref: ossf/fuzz-introspector#48 (comment) Ref: ossf/fuzz-introspector#67 (comment) * refactor fuzz-introspector command generation This is to shorten the long line that runs fuzz-introspector and also in anticipation that down the line we will have more oss-fuzz specific commands in fuzz-introspector
|
Happy to try again, just let me know :) |
|
Argh I forgot to ping here -- apologies @MarcoFalke The COVERAGE_URL issue is fixed. This should be ready to test if building OSS-Fuzz images yourself from the fuzz-introspector repository. If you would like to use the OSS-Fuzz images, then I would wait until this is merged google/oss-fuzz#7774 as it has a few bug fixes |
* infra: fuzz-introspector: ensure COVERAGE_URL exists This is to make sure fuzz-introspector can run in local builds. Ref: ossf/fuzz-introspector#48 (comment) Ref: ossf/fuzz-introspector#67 (comment) * refactor fuzz-introspector command generation This is to shorten the long line that runs fuzz-introspector and also in anticipation that down the line we will have more oss-fuzz specific commands in fuzz-introspector
|
Just tried again after the oss-fuzz bump to clang-15. Still reproducible with: This seems to be the same error that is listen on the instrospector tab on https://oss-fuzz-build-logs.storage.googleapis.com/index.html (also seen for a few other projects). |
|
Thanks @MarcoFalke My current understanding of this is it's not due to Fuzz Introspector but rather LTO (#48 (comment)). When I debugged it ( #48 (comment)) I could not locate the error in Fuzz Introspector but just in some llvm code, and the issue occurred with and without fuzz introspector. |
|
Ok, I've moved the issue to bitcoin/bitcoin#25961 as it seems unrelated to this codebase. |
|
Given bitcoin/bitcoin#25961 (comment) we may need to force use of clang 16 -- this issue does affect a lot of projects. |
|
Does introspector already use a different clang version than oss-fuzz? If yes, that should simplify things and I am happy to test that. Otherwise, it seems hard to bump the oss-fuzz clang version, so I might just wait until it happens "by itself". Edit: Alternative (:sweat_smile:): Switch to aarch64, which doesn't seem to have the bug |
|
By default it uses the same. However, in the past we've used a different version and it probably wouldn't be too much of a hassle to get that in again. I'll try and see if it's possible to get fuzz introspector running with clang-16 and then check if this issue is resolved in some projects! If successful, I can then push some images up somewhere that uses clang-16 and then we can use the solution of #452 to run introspector with the latest clang on the latest oss-fuzz corpus. Interesting it works on aarch64 -- it's an annoying compiler bug and it does seem to affect a significant amount of projects. |
Was running
../run_both.sh bitcoin-core 3, but it failed.The text was updated successfully, but these errors were encountered: