AddressSanitizer Mac OSX builds are broken




Build Config
4 years ago
2 years ago


(Reporter: decoder, Unassigned)


(Blocks: 1 bug, {sec-want})

Mac OS X

Firefox Tracking Flags

(Not tracked)




4 years ago
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).
I think we should just not use asan on host tools.

Comment 2

4 years ago
(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).:
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.
smichaud has some instructions on getting these working here:
See Also: → bug 1026162


2 years ago
Blocks: 1026162
No longer blocks: 863846
You need to log in before you can comment on or make changes to this bug.