Closed GoogleCodeExporter closed 9 years ago
It seems like this it only happens when asan=1 in GYP_DEFINES, setting just
clang=1 compiles fine.
I ran with ninja -v and I get these details about the step before the errors:
[36/349] ../../third_party/llvm-build/Release+Asserts/bin/clang -MMD -MF
obj/third_party/libjpeg_turbo/libjpeg.jdinput.o.d -D_FILE_OFFSET_BITS=64
-DCHROMIUM_BUILD -DUSE_DEFAULT_RENDER_THEME=1 -DUSE_LIBJPEG_TURBO=1 -DUSE_NSS=1
-DENABLE_ONE_CLICK_SIGNIN -DGTK_DISABLE_SINGLE_INCLUDES=1 -DENABLE_REMOTING=1
-DENABLE_WEBRTC=1 -DENABLE_PEPPER_THREADING -DENABLE_CONFIGURATION_POLICY
-DENABLE_INPUT_SPEECH -DENABLE_NOTIFICATIONS -DENABLE_GPU=1 -DENABLE_EGLIMAGE=1
-DUSE_SKIA=1 -DENABLE_TASK_MANAGER=1 -DENABLE_WEB_INTENTS=1
-DENABLE_EXTENSIONS=1 -DENABLE_PLUGIN_INSTALLATION=1 -DENABLE_PLUGINS=1
-DENABLE_SESSION_SERVICE=1 -DENABLE_THEMES=1 -DENABLE_BACKGROUND=1
-DENABLE_AUTOMATION=1 -DENABLE_GOOGLE_NOW=1 -DENABLE_LANGUAGE_DETECTION=1
-DENABLE_PRINTING=1 -DENABLE_CAPTIVE_PORTAL_DETECTION=1 -DWITH_SIMD
-DMOTION_JPEG_SUPPORTED -DADDRESS_SANITIZER -DNDEBUG -DNVALGRIND
-DDYNAMIC_ANNOTATIONS_ENABLED=0 -I../../third_party/libjpeg_turbo
-fstack-protector --param=ssp-buffer-size=4 -Werror -pthread -fno-exceptions
-fno-strict-aliasing -Wno-unused-parameter -Wno-missing-field-initializers
-fvisibility=hidden -pipe -fPIC -Wheader-hygiene -Wno-unused-function
-Wno-char-subscripts -Wno-unnamed-type-template-args -Wno-c++11-extensions
-Wno-covered-switch-default -Xclang -load -Xclang
/src/webrtc/trunk/tools/clang/scripts/../../../third_party/llvm-build/Release+As
serts/lib/libFindBadConstructs.so -Xclang -add-plugin -Xclang
find-bad-constructs -Xclang -plugin-arg-find-bad-constructs -Xclang
skip-virtuals-in-implementations -fcolor-diagnostics -Wno-format
-Wno-unused-result -fsanitize=address -fno-omit-frame-pointer -w -O2
-fdata-sections -ffunction-sections -c
../../third_party/libjpeg_turbo/jdinput.c -o
obj/third_party/libjpeg_turbo/libjpeg.jdinput.o
FAILED: cd ../../third_party/libvpx; ../../out/Release/yasm -D CHROMIUM -I
source/config/linux/x64 -I source/libvpx -I
../../out/Release/gen/third_party/libvpx -DPIC -felf64 -m amd64 -o
"../../out/Release/gen/third_party/libvpx/quantize_sse4.o"
"source/libvpx/vp8/encoder/x86/quantize_sse4.asm"
Original comment by kjellan...@google.com
on 10 Jan 2013 at 7:14
For some reason there are asan conditions which only apply to the offset files:
http://src.chromium.org/svn/trunk/deps/third_party/libvpx/libvpx.gyp
'conditions': [
['asan==1', {
'cflags!': [ '-fsanitize=address' ],
'xcode_settings': { 'OTHER_CFLAGS!': [ '-fsanitize=address' ] },
'ldflags!': [ '-fsanitize=address' ],
}],
],
I'm not sure how to 'git blame' to figure out why these were added. It looks
like they're removing -fsanitize=address
Original comment by johannkoenig@google.com
on 10 Jan 2013 at 7:41
Please check with fgalligan@chromium.org
The change came in with
http://src.chromium.org/viewvc/chrome?view=rev&revision=173032
Looks like it was some kind of fix for ARM that broke the case when asan=1 in
GYP_DEFINES...
Original comment by kjellan...@google.com
on 10 Jan 2013 at 9:04
http://src.chromium.org/viewvc/chrome?view=rev&revision=147568
There have been a couple updates to the syntax but it looks like the original
intention was to disable ASAN on the offset files
Original comment by johannkoenig@google.com
on 10 Jan 2013 at 9:47
The issue looks to be with the removal of -faddress-sanitizer in
http://src.chromium.org/viewvc/chrome?view=rev&revision=169790. If you revert
the changes made in r169790 then you can build with your steps.
CC thakis@chromium.org to see if we can revert r169790.
Original comment by fgalli...@google.com
on 11 Jan 2013 at 7:14
No! -faddress-sanitizer is the old spelling. Please remove it everywhere, and
use -fsanitize=address instead. That should fix your build.
Original comment by thakis@google.com
on 11 Jan 2013 at 7:29
Maybe you just need to roll to a newer libvpx, I believe I updated that for
chromium.
Original comment by thakis@google.com
on 11 Jan 2013 at 7:30
I tried again with chromium_revision 176094 but I still get the same error.
It doesn't change anything if I modify libvpx.gyp manually to use
-fsanitize=address instead of -faddress-sanitizer, since it was already using
the right flag during compilation (see output in comment #1 above).
I guess that one comes from asan=1 being in common.gypi.
Original comment by kjellan...@google.com
on 11 Jan 2013 at 8:21
As I said, please try again with
Index: third_party/libvpx/libvpx.gyp
===================================================================
--- third_party/libvpx/libvpx.gyp (revision 3360)
+++ third_party/libvpx/libvpx.gyp (working copy)
@@ -347,11 +347,11 @@
],
'conditions': [
['asan==1', {
- 'cflags!': [ '-faddress-sanitizer', ],
+ 'cflags!': [ '-fsanitize=address', ],
'xcode_settings': {
- 'OTHER_CFLAGS!': [ '-faddress-sanitizer', ],
+ 'OTHER_CFLAGS!': [ '-fsanitize=address', ],
},
- 'ldflags!': [ '-faddress-sanitizer', ],
+ 'ldflags!': [ '-fsanitize=address', ],
}],
],
'sources': [
The issue probably isn't that -fsanitize=address is not passed correctly, it's
that it's not removed from some libvpx files. "cflags!" above tries to remove
-faddress-sanitizer (with the cflags!, ldflags! lines -- a trailing '!' means
remove), when it should be removing -fsanitize=address.
See chromium:159580 for similar issues.
Original comment by thakis@chromium.org
on 11 Jan 2013 at 3:03
So I'm trying this (except that I synced with `GYP_GENERATORS=ninja
GYP_DEFINES=asan=1 gclient sync`, and I'm building with `ninja -C
out/Release`). I'm building without a new chromium revision first, to check if
that works. I'm getting lots of
clang: warning: argument '-faddress-sanitizer' is deprecated, use '-fsanitize=address' instead
lines (which is expected). The chromium change tries to get rid of these. Don't
you see these lines?
Original comment by thakis@chromium.org
on 11 Jan 2013 at 3:11
I must have entered a typo in the libvpx.gyp I modified manually, because now
it works when I apply your patch (I thought I did the same edit).
I'll update our libvpx.gyp accordingly in our roll CL for WebRTC.
Feel free to close this issue as Fixed.
Original comment by kjellan...@google.com
on 11 Jan 2013 at 3:21
Original comment by albe...@google.com
on 17 Jan 2013 at 11:18
Original issue reported on code.google.com by
kjellander@webrtc.org
on 7 Jan 2013 at 4:48