|
|
Created:
7 years, 9 months ago by Alexander Potapenko Modified:
7 years, 9 months ago Reviewers:
Nico CC:
chromium-reviews, eugenis+clang_chromium.org, dmikurube+clang_chromium.org, glider+clang_chromium.org, glotov+watch_chromium.org, ukai+watch_chromium.org, hans Base URL:
svn://svn.chromium.org/chrome/trunk/src/ Visibility:
Public. |
DescriptionAdd vm672-m1 (the new Mac ASan builder) to the list of machines using pinned Clang version.
BUG=170629
TBR=thakis
Committed: https://src.chromium.org/viewvc/chrome?view=rev&revision=188080
Patch Set 1 #
Messages
Total messages: 9 (0 generated)
Message was sent while issue was closed.
Committed patchset #1 manually as r188080 (presubmit successful).
Message was sent while issue was closed.
TBR
Message was sent while issue was closed.
How far along are we in getting the asan bots back on head clang?
Message was sent while issue was closed.
On 2013/03/14 15:43:42, Nico wrote: > How far along are we in getting the asan bots back on head clang? I've sent https://codereview.chromium.org/12457022/ to trybots, but got the following error on mac_asan: FAILED: (export BUILT_PRODUCTS_DIR=/Volumes/data/b/build/slave/mac_asan/build/src/out/Release; export CHROMIUM_STRIP_SAVE_FILE=../build/asan.saves; export CONFIGURATION=Release; export CONTENTS_FOLDER_PATH=crash_report_sender.app/Contents; export EXECUTABLE_NAME=crash_report_sender; export EXECUTABLE_PATH=crash_report_sender.app/Contents/MacOS/crash_report_sender; export FULL_PRODUCT_NAME=crash_report_sender.app; export INFOPLIST_PATH=crash_report_sender.app/Contents/Info.plist; export MACH_O_TYPE=mh_execute; export PRODUCT_NAME=crash_report_sender; export PRODUCT_TYPE=com.apple.product-type.application; export SDKROOT=/Developer/SDKs/MacOSX10.6.sdk; export SRCROOT=/Volumes/data/b/build/slave/mac_asan/build/src/out/Release/../../breakpad; export SOURCE_ROOT="${SRCROOT}"; export TARGET_BUILD_DIR=/Volumes/data/b/build/slave/mac_asan/build/src/out/Release; export TEMP_DIR="${TMPDIR}"; export UNLOCALIZED_RESOURCES_FOLDER_PATH=crash_report_sender.app/Contents/Resources; export WRAPPER_NAME=crash_report_sender.app; (cd ../../breakpad && ../build/mac/copy_asan_runtime_dylib.sh && ../build/mac/change_mach_o_flags_from_xcode.sh); G=$?; ((exit $G) || rm -rf ./crash_report_sender.app) && exit $G) && touch crash_report_sender.app install_name_tool: for architecture i386 object: /Volumes/data/b/build/slave/mac_asan/build/src/out/Release/crash_report_sender.app/Contents/Libraries/libclang_rt.asan_osx_dynamic.dylib malformed object (unknown load command 13) I suspect this is due to old Xcode being used by the 10.6 bots, so switching to 10.8 should fix the problem.
Message was sent while issue was closed.
That said, I want to stop using the pinned Clang ASAP and this CL is a step in that direction.
On Thu, Mar 14, 2013 at 8:51 AM, <glider@chromium.org> wrote: > On 2013/03/14 15:43:42, Nico wrote: > >> How far along are we in getting the asan bots back on head clang? >> > > I've sent https://codereview.chromium.**org/12457022/<https://codereview.chromium.org/1... trybots, but got the > following error on mac_asan: > FAILED: (export > BUILT_PRODUCTS_DIR=/Volumes/**data/b/build/slave/mac_asan/** > build/src/out/Release; > export CHROMIUM_STRIP_SAVE_FILE=../**build/asan.saves; export > CONFIGURATION=Release; export > CONTENTS_FOLDER_PATH=crash_**report_sender.app/Contents; export > EXECUTABLE_NAME=crash_report_**sender; export > EXECUTABLE_PATH=crash_report_**sender.app/Contents/MacOS/** > crash_report_sender; > export FULL_PRODUCT_NAME=crash_**report_sender.app; export > INFOPLIST_PATH=crash_report_**sender.app/Contents/Info.**plist; export > MACH_O_TYPE=mh_execute; export PRODUCT_NAME=crash_report_**sender; export > PRODUCT_TYPE=com.apple.**product-type.application; export > SDKROOT=/Developer/SDKs/**MacOSX10.6.sdk; export > SRCROOT=/Volumes/data/b/build/**slave/mac_asan/build/src/out/** > Release/../../breakpad; > export SOURCE_ROOT="${SRCROOT}"; export > TARGET_BUILD_DIR=/Volumes/**data/b/build/slave/mac_asan/** > build/src/out/Release; > export TEMP_DIR="${TMPDIR}"; export > UNLOCALIZED_RESOURCES_FOLDER_**PATH=crash_report_sender.app/** > Contents/Resources; > export WRAPPER_NAME=crash_report_**sender.app; (cd ../../breakpad && > ../build/mac/copy_asan_**runtime_dylib.sh && > ../build/mac/change_mach_o_**flags_from_xcode.sh); G=$?; ((exit $G) || rm > -rf > ./crash_report_sender.app) && exit $G) && touch crash_report_sender.app > install_name_tool: for architecture i386 object: > /Volumes/data/b/build/slave/**mac_asan/build/src/out/** > Release/crash_report_sender.**app/Contents/Libraries/** > libclang_rt.asan_osx_dynamic.**dylib > malformed object (unknown load command 13) > > I suspect this is due to old Xcode being used by the 10.6 bots, so > switching to > 10.8 should fix the problem. > The 10.6 bots should all be using some Xcode 4 variant, at least we upgraded all bots not too long ago. Maybe the deployment target env var isn't set correctly when the dylib is being built (see update.sh, we set it when calling make, but maybe it gets lost somewhere in clang's built system)? For the bots, upgrading the bot to 10.8 is enough, but if you want to eventually distribute chrome/asan builds to users, you need to understand what's going wrong here.
Message was sent while issue was closed.
> The 10.6 bots should all be using some Xcode 4 variant, at least we > upgraded all bots not too long ago. > > Maybe the deployment target env var isn't set correctly when the dylib is > being built (see update.sh, we set it when calling make, but maybe it gets > lost somewhere in clang's built system)? > > For the bots, upgrading the bot to 10.8 is enough, but if you want to > eventually distribute chrome/asan builds to users, you need to understand > what's going wrong here. Thanks for the explanation. I'll try to fix that before upgrading the trybots to 10.8 then.
Message was sent while issue was closed.
BTW otool -l prints the following for ASan dylib: ============================================= Load command 7 cmd LC_VERSION_MIN_MACOSX cmdsize 16 version 10.5 sdk 10.8 ... Load command 13 cmd LC_DATA_IN_CODE cmdsize 16 dataoff 145920 datasize 0 ============================================= LC_DATA_IN_CODE is really missing on 10.6. But looks like this is only a problem at build time, not sure if it's going to affect the end users.
Message was sent while issue was closed.
I've checked that a binary built on 10.8 with version=10.6 and sdk=10.8 can be executed on 10.6, yet the linker, otool and install_name_tool can't process it. |