923916 - AddressSanitizer Mac OSX builds are broken

Status: RESOLVED WORKSFORME

(Firefox Build System :: General, defect)

Description

[Christian Holler (:decoder)]

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

[Mike Hommey [:glandium]]

I think we should just not use asan on host tools.

Comment 2

[Christian Holler (:decoder)]

(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,
> http://llvm-reviews.chandlerc.com/D216 and
> http://llvm-reviews.chandlerc.com/D223, 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
> using DYLD_INSERT_LIBRARIES.
> 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 Chromium.app (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
> https://codereview.chromium.org/11642018/ for a rough example of how
> we're going to do that).:

Comment 3

[David D. Kilzer (ddk)]

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/Firefox.app/Contents/MacOS/Firefox

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

[Andrew McCreight [:mccr8]]

smichaud has some instructions on getting these working here:
http://people.mozilla.org/~stmichaud/bmo/firefox-asan-howto.txt

Comment 5

[Jesse Schwartzentruber (:truber)]

ASan builds are working now.