Last Comment Bug 923916 - AddressSanitizer Mac OSX builds are broken
: AddressSanitizer Mac OSX builds are broken
Status: NEW
: sec-want
Product: Core
Classification: Components
Component: Build Config (show other bugs)
: Trunk
: x86_64 Mac OS X
-- normal with 1 vote (vote)
: ---
Assigned To: Nobody; OK to take it and work on it
: Gregory Szorc [:gps] (away until 2017-03-20)
Depends on:
Blocks: asan-macbuilds
  Show dependency treegraph
Reported: 2013-10-06 05:06 PDT by Christian Holler (:decoder)
Modified: 2015-03-26 15:22 PDT (History)
13 users (show)
See Also:
Crash Signature:
QA Whiteboard:
Iteration: ---
Points: ---
Has Regression Range: ---
Has STR: ---


Description User image Christian Holler (:decoder) 2013-10-06 05:06:27 PDT
ASan try builds are failing right now, most likely due to library issues (Originally, John Daggett reported this to me):

dyld: Library not loaded: /builds/slave/moz-toolchain/build/stage2/build/Release/lib/clang/3.4/lib/darwin/libclang_rt.asan_osx_dynamic.dylib
  Referenced from: /builds/slave/try-osx64-d-000000000000000000/build/obj-firefox/config/nsinstall
  Reason: image not found

I assume the proper solution is to package the ASan runtime library with our own libraries, and also ensure that we have the ASan runtime on the libary path whenever we use tools that are part of the build process (like nsinstall).
Comment 1 User image Mike Hommey [:glandium] 2013-10-06 07:15:41 PDT
I think we should just not use asan on host tools.
Comment 2 User image Christian Holler (:decoder) 2013-10-21 05:32:20 PDT
(In reply to Mike Hommey [:glandium] from comment #1)
> I think we should just not use asan on host tools.

Yes, but that doesn't solve the problem here. The final binaries still need the runtime packaged properly.

Here's a mail I got from the ASan devs (longer ago, but I did not have time to make these changes):

> I'm going to land two patches to Clang,
> and
>, which will change the behavior
> of the compiler on OS X.
> Basically, I'm going to replace the existing static ASan runtime with
> a dynamic one, which is going to be preloaded into the application
> This should greatly simplify the code and prevent a number of issues
> we could potentially hit with newer versions of OS X and the system
> libraries.
> This will also require some action from you (as well as other ASan
> clients on Mac; we don't have many however). Because the runtime is
> now a dynamic library, you'll need to have it around each time you
> copy an instrumented binary somewhere.
> In Chromium we're going to include the dynamic runtime into the
> application bundles for (and other .app), and have a copy
> of libclang_rt.asan_osx_dynamic.dylib in the output directory for the
> unix-style binaries (like base_unittests). You will probably need to
> do the same in Firefox. Keep in mind you'll need to fix the dylib
> install name in the binary to be relative to @executable_path (see
> for a rough example of how
> we're going to do that).:
Comment 3 User image David D. Kilzer (ddk) 2014-03-22 20:01:58 PDT
You can fix the 'id' for libclang_rt.asan_osx_dynamic.dylib using:

[xcrun] install_name_tool -id /path/to/installed/libclang_rt.asan_osx_dynamic.dylib /path/to/installed/libclang_rt.asan_osx_dynamic.dylib

Or you can change the binary that loads to to find it relative to its executable path if you distribute it with an app bundle:

[xcrun] install_name_tool -change /path/to/library/currently/in/binary/libclang_rt.asan_osx_dynamic.dylib @executable_path/../relative/path/to/libclang_rt.asan_osx_dynamic.dylib /path/to/

Use "xcrun" on modern-ish Xcode to make sure the correct version of install_name_tool is used.

This is all untested, BTW, but I hope it helps.
Comment 4 User image Andrew McCreight [:mccr8] 2014-06-11 09:08:17 PDT
smichaud has some instructions on getting these working here:

Note You need to log in before you can comment on or make changes to this bug.