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
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.
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 commit-queue@webkit.org... 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>.
<rdar://problem/45068477>
There is some benefit building internal tools with ASan - we want them to behave reliably, so catching random memory corruption is useful.