Bug 124532 – [ASAN] Building with trunk clang corrupts sandbox profile with comment from Compiler.h

• Status: RESOLVED
• Resolution: FIXED
• Component: Web Template Framework

[David Farler]

In https://bugs.webkit.org/show_bug.cgi?id=119165,

A preprocessor check of __clang_major__ and __clang_minor__ was added to Source/WTF/wtf/Compiler.h because of a bug with the "final" keyword.

 59 /* Disable final on versions of Apple clang earlier than 4.2 to avoid bugs like http://webkit.org/b/119165 */
 60 #if defined(__APPLE__) && (__clang_major__ < 4 || (__clang_major__ == 4 && __clang_minor__ < 2))
 61 #define WTF_COMPILER_QUIRK_FINAL_IS_BUGGY 1
 62 // #error "Please use a newer version of Xcode, this version has code generation bugs when using 'final' in C++ code"
 63 #endif

This inserts a comment into code that includes Compiler.h. However, this comment also makes its way into the WebKit2 separate process targets' sandbox profiles, for which // is syntactically invalid and causes the binaries to get killed on launch with something like this:

Nov 18 11:53:20 dmf1 com.apple.launchd[1] (com.apple.WebKit.Networking.Development.41C1A105-0D6B-49FE-8642-88B8537ECD26[93304]): Exited with code: 77
Nov 18 11:53:20 dmf1 com.apple.launchd[1] (com.apple.WebKit.WebContent.Development.F1A8659F-2388-4B1A-ADAF-26C815F35877[93305]): Exited with code: 77
Nov 18 11:57:06 dmf1.apple.com com.apple.WebKit.WebContent.Development[93637]: com.apple.WebKit.WebContent.Development: Couldn't initialize sandbox profile [/Volumes/Data/Users/davidfarler/Downloads/WebKit 2.app/Contents/Frameworks/10.9/WebKit2.framework/Resources/com.apple.WebProcess.sb], error 'line 1: unbound variable: // '

Trunk clang still identifies itself as clang 3.4:

$ xcrun clang --version
clang version 3.4 (trunk 194422)
Target: x86_64-apple-darwin13.0.0
Thread model: posix

So we need to find a proper way to identify trunk clang as well as Apple-built clang.

[Alexey Proskuryakov]

Compiler.h should obviously use c-style comments.

I'm a bit confused though. Is it even intentional that the #error is commented out? It got commented out without any explanation in <http://trac.webkit.org/changeset/157044>.

[David Farler]

(In reply to comment #1)
> Compiler.h should obviously use c-style comments.

This isn't obvious to me – what would that do in this case? ";;" are used to denote comments in sandbox profiles; would using C-style comments prevent this from getting printed to the profile or something?

[Alexey Proskuryakov]

.sb.in files are processed with a C preprocessor, which removes /**/ comments. There are lots more in Compiler.h, so this C++ one is a mistake.

[Anders Carlsson]

(In reply to comment #1)
> Compiler.h should obviously use c-style comments.
> 
> I'm a bit confused though. Is it even intentional that the #error is commented out? It got commented out without any explanation in <http://trac.webkit.org/changeset/157044>.

It was unintentional. I was using a trunk build of clang and probably ran into the same error as David’s seeing now.

Since we only build on Xcode 5 now we can probably remove the quirk altogether.

[David Farler]

Created attachment 220539 [details]
Patch

[David Kilzer (:ddkilzer)]

Comment on attachment 220539 [details]
Patch

r=me

[WebKit Commit Bot]

Comment on attachment 220539 [details]
Patch

Clearing flags on attachment: 220539

Committed r161451: <http://trac.webkit.org/changeset/161451>

[WebKit Commit Bot]

All reviewed patches have been landed.  Closing bug.