New issue
Advanced search Search tips
Note: Color blocks (like or ) mean that a user may not be available. Tooltip shows the reason.

Issue 834463 link

Starred by 1 user

Issue metadata

Status: Duplicate
Merged: issue 834689
Owner: ----
Closed: Apr 2018
Cc:
EstimatedDays: ----
NextAction: ----
OS: ----
Pri: 3
Type: Bug



Sign in to add a comment

ToTLinuxASanLibfuzzer failing to link buffered_frame_deserializer_fuzzer, can't find standard C++ symbols

Project Member Reported by r...@chromium.org, Apr 18 2018

Issue description

First failing build: https://ci.chromium.org/buildbot/chromium.clang/ToTLinuxASanLibfuzzer/767

A few link errors:

[14485/47637] LINK ./buffered_frame_deserializer_fuzzer
FAILED: buffered_frame_deserializer_fuzzer
python "../../build/toolchain/gcc_link_wrapper.py" --output="./buffered_frame_deserializer_fuzzer" -- ../../third_party/llvm-build/Release+Asserts/bin/clang++ -Wl,--fatal-warnings -fPIC -Wl,-z,noexecstack -Wl,-z,now -Wl,-z,relro -fuse-ld=lld -m64 -Werror -Wl,-O2 -Wl,--gc-sections -nostdlib++ --sysroot=../../build/linux/debian_sid_amd64-sysroot -L../../build/linux/debian_sid_amd64-sysroot/usr/local/lib/x86_64-linux-gnu -Wl,-rpath-link=../../build/linux/debian_sid_amd64-sysroot/usr/local/lib/x86_64-linux-gnu -L../../build/linux/debian_sid_amd64-sysroot/lib/x86_64-linux-gnu -Wl,-rpath-link=../../build/linux/debian_sid_amd64-sysroot/lib/x86_64-linux-gnu -L../../build/linux/debian_sid_amd64-sysroot/usr/lib/x86_64-linux-gnu -Wl,-rpath-link=../../build/linux/debian_sid_amd64-sysroot/usr/lib/x86_64-linux-gnu -fsanitize=address -fsanitize-address-use-after-scope -fsanitize=leak -fsanitize-coverage=trace-pc-guard -Wl,-rpath-link=. -Wl,--disable-new-dtags -Wl,-rpath=\$ORIGIN/. -Wl,-rpath-link=. -fsanitize=fuzzer -Wl,-u_sanitizer_options_link_helper -fsanitize=address -fsanitize-address-use-after-scope -fsanitize=leak -fsanitize-coverage=trace-pc-guard -o "./buffered_frame_deserializer_fuzzer" -Wl,--start-group @"./buffered_frame_deserializer_fuzzer.rsp" ./libc++.so -Wl,--end-group   -ldl -lpthread -lrt
/b/c/b/ToTLinuxASanLibfuzzer/src/out/Release/../../third_party/llvm-build/Release+Asserts/bin/ld.lld: error: undefined symbol: std::__throw_system_error(int)
>>> referenced by mutex:138 (/b/c/b/ToTLinuxASanLibfuzzer/src/third_party/llvm-build-tools/gcc485precise/include/c++/4.8.5/mutex:138)
>>>               FuzzerDriver.cpp.o:(fuzzer::PulseThread()) in archive /b/c/b/ToTLinuxASanLibfuzzer/src/third_party/llvm-build/Release+Asserts/lib/clang/7.0.0/lib/linux/libclang_rt.fuzzer-x86_64.a
/b/c/b/ToTLinuxASanLibfuzzer/src/out/Release/../../third_party/llvm-build/Release+Asserts/bin/ld.lld: error: undefined symbol: std::string::find(char const*, unsigned long, unsigned long) const
>>> referenced by basic_string.h:1864 (/b/c/b/ToTLinuxASanLibfuzzer/src/third_party/llvm-build-tools/gcc485precise/include/c++/4.8.5/bits/basic_string.h:1864)
>>>               FuzzerDriver.cpp.o:(fuzzer::GetDedupTokenFromFile(std::string const&)) in archive /b/c/b/ToTLinuxASanLibfuzzer/src/third_party/llvm-build/Release+Asserts/lib/clang/7.0.0/lib/linux/libclang_rt.fuzzer-x86_64.a
/b/c/b/ToTLinuxASanLibfuzzer/src/out/Release/../../third_party/llvm-build/Release+Asserts/bin/ld.lld: error: undefined symbol: std::string::find(char, unsigned long) const
>>> referenced by FuzzerDriver.cpp:298 (/b/c/b/ToTLinuxASanLibfuzzer/src/third_party/llvm/compiler-rt/lib/fuzzer/FuzzerDriver.cpp:298)
>>>               FuzzerDriver.cpp.o:(fuzzer::GetDedupTokenFromFile(std::string const&)) in archive /b/c/b/ToTLinuxASanLibfuzzer/src/third_party/llvm-build/Release+Asserts/lib/clang/7.0.0/lib/linux/libclang_rt.fuzzer-x86_64.a
...

I don't see any obvious chrome-side culprits in the blamelist, so this is probably an LLVM regression.

The LLVM revision range is:
good: 330190
bad:  330237

There are no libfuzzer changes in this range, but there are some LLD changes:
330234 - [ELF] Add profile guided section layout
330164 - Revert r329960 "Do not keep shared symbols created from garbage-collected eliminated DSOs."

I tried to reproduce this locally, but the binary linked successfully. =/ I think maybe that's because I didn't build clang and libfuzzer with the gcc485precise sysroot that we use on the Chromium buildbots.

Any libfuzzer build system experts on hand?
 

Comment 1 by p...@chromium.org, Apr 18 2018

Cc: thomasanderson@chromium.org
Could this be due to a sysroot change?
Is this only failing with the ToT clang?

Comment 3 by r...@chromium.org, Apr 19 2018

Mergedinto: 834689
Status: Duplicate (was: Untriaged)
Looks like Hans figured it out:  https://crbug.com/834689 .

Sign in to add a comment