Bug 190327 – [Xcode] Never build yasm with ASAN

• Status: RESOLVED
• Resolution: FIXED
• Component: WebRTC

yasm is only used at build time to derive other source files, so there’s no point building it with ASAN. Worse, when targeting the iOS Simulator, yasm is built as a Simulator binary, even though it’s then run on the host. This works, but if ASAN is enabled, it tries to link against the Simulator ASAN dylib, which causes a failure at runtime.

Patch forthcoming.

Created attachment 351719 [details]
Opt yasm out of ASAN

[youenn fablet]

Comment on attachment 351719 [details]
Opt yasm out of ASAN

View in context: https://bugs.webkit.org/attachment.cgi?id=351719&action=review

> Tools/asan/asan.xcconfig:16
> +CLANG_ADDRESS_SANITIZER_NO = YES;

Is it working?
Should we set WK_ASAN_ALLOWED = NO in yasm.xcconfig and 
CLANG_ADDRESS_SANITIZER = $(CLANG_ADDRESS_SANITIZER_$(WK_ASAN_ALLOWED));
CLANG_ADDRESS_SANITIZER_NO = NO;

Comment on attachment 351719 [details]
Opt yasm out of ASAN

View in context: https://bugs.webkit.org/attachment.cgi?id=351719&action=review

>> Tools/asan/asan.xcconfig:16
>> +CLANG_ADDRESS_SANITIZER_NO = YES;
> 
> Is it working?
> Should we set WK_ASAN_ALLOWED = NO in yasm.xcconfig and 
> CLANG_ADDRESS_SANITIZER = $(CLANG_ADDRESS_SANITIZER_$(WK_ASAN_ALLOWED));
> CLANG_ADDRESS_SANITIZER_NO = NO;

By convention, if a build setting is not specified, it’s equivalent to being set to NO. So if we wanted a build setting that means “ASAN allowed” we’d have to remember to explicitly set it to YES in every project. Since this is such a rare exception, I opted for something we set in the one place where we make the exception.

[WebKit Commit Bot]

Comment on attachment 351719 [details]
Opt yasm out of ASAN

Rejecting attachment 351719 [details] from commit-queue.

Failed to run "['/Volumes/Data/EWS/WebKit/Tools/Scripts/webkit-patch', '--status-host=webkit-queues.webkit.org', '--bot-id=webkit-cq-01', 'apply-attachment', '--no-update', '--non-interactive', 351719, '--port=mac']" exit_code: 2 cwd: /Volumes/Data/EWS/WebKit

Logging in as [e-mail]...
Fetching: https://bugs.webkit.org/attachment.cgi?id=351719&action=edit
Fetching: https://bugs.webkit.org/show_bug.cgi?id=190327&ctype=xml&excludefield=attachmentdata
Processing 1 patch from 1 bug.
Processing patch 351719 from bug 190327.
Fetching: https://bugs.webkit.org/attachment.cgi?id=351719
Failed to run "[u'/Volumes/Data/EWS/WebKit/Tools/Scripts/svn-apply', '--force', '--reviewer', u'Youenn Fablet']" exit_code: 1 cwd: /Volumes/Data/EWS/WebKit

Parsed 4 diffs from patch file(s).
(Stripping trailing CRs from patch.)
patching file Source/ThirdParty/libwebrtc/ChangeLog
Hunk #1 succeeded at 1 with fuzz 3.
(Stripping trailing CRs from patch.)
patching file Source/ThirdParty/libwebrtc/Configurations/yasm.xcconfig
Hunk #1 FAILED at 19.
1 out of 1 hunk FAILED -- saving rejects to file Source/ThirdParty/libwebrtc/Configurations/yasm.xcconfig.rej
(Stripping trailing CRs from patch.)
patching file Tools/ChangeLog
(Stripping trailing CRs from patch.)
patching file Tools/asan/asan.xcconfig

Failed to run "[u'/Volumes/Data/EWS/WebKit/Tools/Scripts/svn-apply', '--force', '--reviewer', u'Youenn Fablet']" exit_code: 1 cwd: /Volumes/Data/EWS/WebKit

Full output: https://webkit-queues.webkit.org/results/9473060

Committed <https://trac.webkit.org/r236898>.

[Radar WebKit Bug Importer]

<rdar://problem/45068477>

[Alexey Proskuryakov]

There is some benefit building internal tools with ASan - we want them to behave reliably, so catching random memory corruption is useful.