Confirmed on x86_64-apple-darwin13.

Revision 204368 says

Author:	kcc
Date:	Mon Nov 4 21:33:31 2013 UTC (2 days, 14 hours ago)
Log Message:	
libsanitizer merge from upstream r191666

** This may break gcc-asan on Mac, will follow up separately. **

The failures are of the kind:

==70739==AddressSanitizer CHECK failed: ../../../../_clean/libsanitizer/sanitizer_common/sanitizer_mac.cc:146 "((env_ptr)) != (0)" (0x0, 0x0)

Note that the tests pass on x86_64-apple-darwin10 for both -m32 and -m64.

On x86_64-apple-darwin11, at r204551, I only see the single failure of…

FAIL: c-c++-common/asan/strncpy-overflow-1.c  -O0  execution test

at both -m32 and -m64. More interestingly, if I compile the -m64 test case…

 /sw/src/fink.build/gcc49-4.9.0-1000/darwin_objdir/gcc/xgcc -B/sw/src/fink.build/gcc49-4.9.0-1000/darwin_objdir/gcc/ /sw/src/fink.build/gcc49-4.9.0-1000/gcc-4.9-20131107/gcc/testsuite/c-c++-common/asan/global-overflow-1.c   -B/sw/src/fink.build/gcc49-4.9.0-1000/darwin_objdir/x86_64-apple-darwin11.4.2/./libsanitizer/asan/  -L/sw/src/fink.build/gcc49-4.9.0-1000/darwin_objdir/x86_64-apple-darwin11.4.2/./libsanitizer/asan/.libs  -fsanitize=address -g -fno-diagnostics-show-caret -fdiagnostics-color=never   -O0  -fno-builtin-memset  -lm   -m64 -o ./global-overflow-1.exe 

, place it in the same directory as the libasan.1.dylib, libgcc_s.1.dylib and libstdc++.6.dylib shared libraries and execute…

# setenv DYLD_LIBRARY_PATH .
# ./global-overflow-1.exe
=================================================================
==64301==ERROR: AddressSanitizer: global-buffer-overflow on address 0x000102eaf1ea at pc 0x102eaed1c bp 0x7fff62aad740 sp 0x7fff62aad738
READ of size 1 at 0x000102eaf1ea thread T0
    #0 0x102eaed1b (/sw/src/fink.build/gcc49-4.9.0-1000/darwin_objdir/gcc/testsuite/gcc/temp/./global-overflow-1.exe+0x100000d1b)
    #1 0x102eaec7f (/sw/src/fink.build/gcc49-4.9.0-1000/darwin_objdir/gcc/testsuite/gcc/temp/./global-overflow-1.exe+0x100000c7f)
    #2 0x0
0x000102eaf1ea is located 0 bytes to the right of global variable 'YYY' from '/sw/src/fink.build/gcc49-4.9.0-1000/gcc-4.9-20131107/gcc/testsuite/c-c++-common/asan/global-overflow-1.c' (0x102eaf1e0) of size 10
0x000102eaf1ea is located 54 bytes to the left of global variable 'ZZZ' from '/sw/src/fink.build/gcc49-4.9.0-1000/gcc-4.9-20131107/gcc/testsuite/c-c++-common/asan/global-overflow-1.c' (0x102eaf220) of size 10
Shadow bytes around the buggy address:
  0x1000205d5de0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
  0x1000205d5df0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
  0x1000205d5e00: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
  0x1000205d5e10: 04 f9 f9 f9 f9 f9 f9 f9 00 00 00 00 00 00 00 00
  0x1000205d5e20: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
=>0x1000205d5e30: 00 00 00 00 00 02 f9 f9 f9 f9 f9 f9 00[02]f9 f9
  0x1000205d5e40: f9 f9 f9 f9 00 02 f9 f9 f9 f9 f9 f9 00 00 00 00
  0x1000205d5e50: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
  0x1000205d5e60: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
  0x1000205d5e70: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
  0x1000205d5e80: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
Shadow byte legend (one shadow byte represents 8 application bytes):
  Addressable:           00
  Partially addressable: 01 02 03 04 05 06 07 
  Heap left redzone:     fa
  Heap right redzone:    fb
  Freed heap region:     fd
  Stack left redzone:    f1
  Stack mid redzone:     f2
  Stack right redzone:   f3
  Stack partial redzone: f4
  Stack after return:    f5
  Stack use after scope: f8
  Global redzone:        f9
  Global init order:     f6
  Poisoned by user:      f7
  ASan internal:         fe
==64301==ABORTING

it works as expected on darwin11. If I move this directory of files built under darwin11 to a darwin12 machine, the same binaries produce the failure…

% setenv DYLD_LIBRARY_PATH .
% ./global-overflow-1.exe
==65680==AddressSanitizer CHECK failed: ../../../../gcc-4.9-20131107/libsanitizer/sanitizer_common/sanitizer_mac.cc:146 "((env_ptr)) != (0)" (0x0, 0x0)

My initial guess would be that the stricter ASLR could be in play but compiling the test case with -Wl,-no_pie doesn't suppress the error on darwin12/13.

Current llvm trunk is broken at the moment on darwin, but using a build from Oct 29th, I have no issues with the failing test case under clang...

% /sw/opt/llvm-3.4/bin/clang -O1 -fsanitize=address -fno-builtin-memset -g -fdiagnostics-color=never -O0 -m64 global-overflow-1.c
% ./a.out
=================================================================
==81836==ERROR: AddressSanitizer: global-buffer-overflow on address 0x000103d991ea at pc 0x103d98b76 bp 0x7fff5be686d0 sp 0x7fff5be686c8
READ of size 1 at 0x000103d991ea thread T0
==81836==WARNING: Trying to symbolize code, but external symbolizer is not initialized!
    #0 0x103d98b75 (/Users/howarth/./a.out+0x100001b75)
    #1 0x7fff8a4237e0 (/usr/lib/system/libdyld.dylib+0x27e0)
    #2 0x0

0x000103d991ea is located 54 bytes to the left of global variable 'main.ZZZ' from 'global-overflow-1.c' (0x103d99220) of size 10
0x000103d991ea is located 0 bytes to the right of global variable 'main.YYY' from 'global-overflow-1.c' (0x103d991e0) of size 10
SUMMARY: AddressSanitizer: global-buffer-overflow ??:0 ??
Shadow bytes around the buggy address:
  0x1000207b31e0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
  0x1000207b31f0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
  0x1000207b3200: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
  0x1000207b3210: 00 00 00 00 04 f9 f9 f9 f9 f9 f9 f9 00 00 00 00
  0x1000207b3220: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
=>0x1000207b3230: 00 00 00 00 00 02 f9 f9 f9 f9 f9 f9 00[02]f9 f9
  0x1000207b3240: f9 f9 f9 f9 00 02 f9 f9 f9 f9 f9 f9 00 00 00 00
  0x1000207b3250: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
  0x1000207b3260: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
  0x1000207b3270: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
  0x1000207b3280: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
Shadow byte legend (one shadow byte represents 8 application bytes):
  Addressable:           00
  Partially addressable: 01 02 03 04 05 06 07 
  Heap left redzone:     fa
  Heap right redzone:    fb
  Freed heap region:     fd
  Stack left redzone:    f1
  Stack mid redzone:     f2
  Stack right redzone:   f3
  Stack partial redzone: f4
  Stack after return:    f5
  Stack use after scope: f8
  Global redzone:        f9
  Global init order:     f6
  Poisoned by user:      f7
  ASan internal:         fe
==81836==ABORTING

(In reply to Jack Howarth from comment #4)
This was a test of recent clang's -fsanitize=address on x86_64-apple-darwin12.

The problem is caused by _NSGetEnviron() being called before libSystem is initialized. This happens because some initialization code calls __cxa_atexit() before libSystem_initialize(), and __cxa_atexit() calls __asan_init() and _NSGetEnviron().

The fix is trivial (call the real __cxa_atexit() if asan_inited == 0 instead of calling __asan_init()), but before landing it I'll check why the crash doesn't happen on LLVM (I suspect different linkage order).

If I compile stack-overflow-1.c with 'clang -fsanitize=address -c', the resulting object file can be linked into an executable with either 'clang -fsanitize=address' or 'gcc -fsanitize=address' (this requires declaring "void *__asan_mapping_offset=0x100000000000;", since the GCC instrumentation pass doesn't insert the mapping offset). The executable linked with Clang works just fine, while the GCC one crashes on the same env_ptr assertion.

Clang:
$ $CLANG  stack-overflow-1.o -fsanitize=address -v && ./a.out
...
"/usr/bin/ld" -dynamic -arch x86_64 -macosx_version_min 10.8.0 -o a.out stack-overflow-1.o -lstdc++ /Users/glider/src/asan/llvm/llvm_cmake_build/bin/../lib/clang/3.4/lib/darwin/libclang_rt.asan_osx_dynamic.dylib -lSystem
=================================================================
==37032==ERROR: AddressSanitizer: stack-buffer-overflow on address 0x7fff5add8aea at pc 0x104e27c93 bp 0x7fff5add89f0 sp 0x7fff5add89e8
...

GCC:
$ $GCC  stack-overflow-1.o -fsanitize=address -v && ./a.out
...
/usr/bin/ld -dynamic -arch x86_64 -macosx_version_min 10.8.5 -weak_reference_mismatches non-weak -o a.out -L/Users/glider/src/gcc-asan/build/inst/lib/gcc/x86_64-apple-darwin12.5.0/4.9.0 -L/Users/glider/src/gcc-asan/build/inst/lib/gcc/x86_64-apple-darwin12.5.0/4.9.0/../../.. stack-overflow-1.o -lasan -no_compact_unwind -lSystem -lgcc_ext.10.5 -lgcc -lSystem -v
...
==37029==AddressSanitizer CHECK failed: ../../../../libsanitizer/sanitizer_common/sanitizer_mac.cc:146 "((env_ptr)) != (0)" (0x0, 0x0)


This seems to have nothing to do with the linkage order: I've tried to change the order of -l flags in the ld invocation from $GCC, but that didn't work.
However when I replaced '-lasan' with the full path to the ASan runtime from the Clang build, it worked fine. So there's some subtle difference between the ASan runtimes compiled when building GCC and Clang.

Clang's libclang_rt.asan_osx_dynamic.dylib depends on the Foundation framework. When I remove that dependency, ASanified programs crash on the same env_ptr assertion.

(In reply to Alexander Potapenko from comment #8)
> Clang's libclang_rt.asan_osx_dynamic.dylib depends on the Foundation
> framework. When I remove that dependency, ASanified programs crash on the
> same env_ptr assertion.

Should we just add a CoreFoundation linkage to the creation of libasan.1.dylib in FSF gcc instead?

This might help, but we don't actually need that dependency.
Instead libsanitizer should be updated to r194573.

(In reply to Alexander Potapenko from comment #10)
> This might help, but we don't actually need that dependency.
> Instead libsanitizer should be updated to r194573.

Okay, I assume the missing linkage should be a trivial change like...

Index: libsanitizer/asan/Makefile.am
===================================================================
--- libsanitizer/asan/Makefile.am	(revision 204618)
+++ libsanitizer/asan/Makefile.am	(working copy)
@@ -43,7 +43,11 @@ libasan_la_LIBADD = $(top_builddir)/sani
 endif
 libasan_la_LIBADD += $(LIBSTDCXX_RAW_CXX_LDFLAGS)
 
+if USING_MAC_INTERPOSE
+libasan_la_LDFLAGS = -framework CoreFoundation -version-info `grep -v '^\#' $(srcdir)/libtool-version` -lpthread -ldl
+else
 libasan_la_LDFLAGS = -version-info `grep -v '^\#' $(srcdir)/libtool-version` -lpthread -ldl
+endif
 
 libasan_preinit.o: asan_preinit.o
 	cp $< $@

That was Foundation, not sure if CoreFoundation also works.

(In reply to Alexander Potapenko from comment #12)
> That was Foundation, not sure if CoreFoundation also works.

Linking libasan against -Wl,-framework,CoreFoundation for gcc trunk at r204750 suppresses all of the failures in asan.exp on x86_64-apple-darwin12. Retesting with -Wl,-framework,Foundation.

I think one of the frameworks depends on another one, please make sure to
pick the latter one if that's true.
Also add a comment denoting this is a dirty workaround.
On Nov 13, 2013 9:38 PM, "howarth at nitro dot med.uc.edu" <
gcc-bugzilla@gcc.gnu.org> wrote:

> http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58994
>
> --- Comment #13 from Jack Howarth <howarth at nitro dot med.uc.edu> ---
> (In reply to Alexander Potapenko from comment #12)
> > That was Foundation, not sure if CoreFoundation also works.
>
> Linking libasan against -Wl,-framework,CoreFoundation for gcc trunk at
> r204750
> suppresses all of the failures in asan.exp on x86_64-apple-darwin12.
> Retesting
> with -Wl,-framework,Foundation.
>
> --
> You are receiving this mail because:
> You are on the CC list for the bug.
>

(In reply to Alexander Potapenko from comment #14)
> I think one of the frameworks depends on another one, please make sure to
> pick the latter one if that's true.
> Also add a comment denoting this is a dirty workaround.
> On Nov 13, 2013 9:38 PM, "howarth at nitro dot med.uc.edu" <
> gcc-bugzilla@gcc.gnu.org> wrote:
> 
> > http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58994
> >
> > --- Comment #13 from Jack Howarth <howarth at nitro dot med.uc.edu> ---
> > (In reply to Alexander Potapenko from comment #12)
> > > That was Foundation, not sure if CoreFoundation also works.
> >
> > Linking libasan against -Wl,-framework,CoreFoundation for gcc trunk at
> > r204750
> > suppresses all of the failures in asan.exp on x86_64-apple-darwin12.
> > Retesting
> > with -Wl,-framework,Foundation.
> >
> > --
> > You are receiving this mail because:
> > You are on the CC list for the bug.
> >

The Foundation framework is already linked against the CoreFoundation framework. I've confirmed that linking libasan against -Wl,-framework,Foundation alone (as is done by llvm) is sufficient to suppress the asan.exp failures. This change will duplicate the linkage used by llvm for the asan shared library. Posted proposed patch at http://gcc.gnu.org/ml/gcc-patches/2013-11/msg01499.html,

I've actually removed the Foundation linkage from LLVM today.
On Nov 13, 2013 10:45 PM, "howarth at nitro dot med.uc.edu" <
gcc-bugzilla@gcc.gnu.org> wrote:

> http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58994
>
> --- Comment #15 from Jack Howarth <howarth at nitro dot med.uc.edu> ---
> (In reply to Alexander Potapenko from comment #14)
> > I think one of the frameworks depends on another one, please make sure to
> > pick the latter one if that's true.
> > Also add a comment denoting this is a dirty workaround.
> > On Nov 13, 2013 9:38 PM, "howarth at nitro dot med.uc.edu" <
> > gcc-bugzilla@gcc.gnu.org> wrote:
> >
> > > http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58994
> > >
> > > --- Comment #13 from Jack Howarth <howarth at nitro dot med.uc.edu>
> ---
> > > (In reply to Alexander Potapenko from comment #12)
> > > > That was Foundation, not sure if CoreFoundation also works.
> > >
> > > Linking libasan against -Wl,-framework,CoreFoundation for gcc trunk at
> > > r204750
> > > suppresses all of the failures in asan.exp on x86_64-apple-darwin12.
> > > Retesting
> > > with -Wl,-framework,Foundation.
> > >
> > > --
> > > You are receiving this mail because:
> > > You are on the CC list for the bug.
> > >
>
> The Foundation framework is already linked against the CoreFoundation
> framework. I've confirmed that linking libasan against
> -Wl,-framework,Foundation alone (as is done by llvm) is sufficient to
> suppress
> the asan.exp failures. This change will duplicate the linkage used by llvm
> for
> the asan shared library. Posted proposed patch at
> http://gcc.gnu.org/ml/gcc-patches/2013-11/msg01499.html,
>
> --
> You are receiving this mail because:
> You are on the CC list for the bug.
>

(In reply to Alexander Potapenko from comment #16)
> I've actually removed the Foundation linkage from LLVM today.

Unfortunately, that is impossible to test here. A remerge of llvm libsanitizer at 194597 with gcc trunk at r204752 bootstraps on x86_64-apple-darwin12 but shows
lots of new test suite failures in asan.exp...

FAIL: c-c++-common/asan/global-overflow-1.c  -O0  output pattern test, is dyld: Symbol not found: __ZN11__sanitizer10Symbolizer21symbolizer_allocator_E
  Referenced from: /sw/src/fink.build/gcc49-4.9.0-1000/darwin_objdir/x86_64-apple-darwin12.5.0/i386/libsanitizer/asan/.libs/libasan.1.dylib
  Expected in: flat namespace
 in /sw/src/fink.build/gcc49-4.9.0-1000/darwin_objdir/x86_64-apple-darwin12.5.0/i386/libsanitizer/asan/.libs/libasan.1.dylib
, should match READ of size 1 at 0x[0-9a-f]+ thread T0.*(
|
)    #0 0x[0-9a-f]+ (in _*main ([^
]*global-overflow-1.c:20|[^
]*:0)|[(])[^
]*(
|
).*0x[0-9a-f]+ is located 0 bytes to the right of global variable.*YYY[^
]* of size 10[^
]*(
|
)

Shouldn't llvm's libsanitizer be better synced with FSF gcc's at this point?

Created attachment 31212 [details]
fix from llvm svn

(In reply to Jack Howarth from comment #18)
> Created attachment 31212 [details]
> fix from llvm svn

The fix from llvm svn applied to gcc trunk at r204752 produces...

Native configuration is x86_64-apple-darwin12.5.0

		=== g++ tests ===


Running target unix/-m32

		=== g++ Summary for unix/-m32 ===

# of expected passes		481
# of unsupported tests		132

Running target unix/-m64

		=== g++ Summary for unix/-m64 ===

# of expected passes		481
# of unsupported tests		132

		=== g++ Summary ===

# of expected passes		962
# of unsupported tests		264
/sw/src/fink.build/gcc49-4.9.0-1000/darwin_objdir/gcc/testsuite/g++/../../xg++  version 4.9.0 20131113 (experimental) (GCC) 

		=== gcc tests ===


Running target unix/-m32

		=== gcc Summary for unix/-m32 ===

# of expected passes		326
# of unsupported tests		101

Running target unix/-m64

		=== gcc Summary for unix/-m64 ===

# of expected passes		326
# of unsupported tests		101

		=== gcc Summary ===

# of expected passes		652
# of unsupported tests		202
/sw/src/fink.build/gcc49-4.9.0-1000/darwin_objdir/gcc/xgcc  version 4.9.0 20131113 (experimental) (GCC) 

Compiler version: 4.9.0 20131113 (experimental) (GCC) 
Platform: x86_64-apple-darwin12.5.0
configure flags: --prefix=/sw --prefix=/sw/lib/gcc4.9 --mandir=/sw/share/man --infodir=/sw/lib/gcc4.9/info --enable-languages=c,c++,fortran,lto,objc,obj-c++,java --with-gmp=/sw --with-libiconv-prefix=/sw --with-isl=/sw --with-cloog=/sw --with-mpc=/sw --with-system-zlib --enable-checking=yes --x-includes=/usr/X11R6/include --x-libraries=/usr/X11R6/lib --program-suffix=-fsf-4.9

for make -k check RUNTESTFLAGS="asan.exp --target_board=unix'{-m32,-m64}'"

On x86_64-apple-darwin13 the fix from llvm svn applied to gcc trunk at r204759 produces...

Native configuration is x86_64-apple-darwin13.0.0

		=== gcc tests ===

Running target unix/-m32

FAIL: c-c++-common/asan/strncpy-overflow-1.c  -O0  execution test <-- no error

		=== gcc Summary for unix/-m32 ===

# of expected passes		324
# of unexpected failures	1
# of unsupported tests		101

Running target unix/-m64
FAIL: c-c++-common/asan/strncpy-overflow-1.c  -O0  execution test <-- no error

		=== gcc Summary for unix/-m64 ===

# of expected passes		324
# of unexpected failures	1
# of unsupported tests		101

		=== gcc Summary ===

# of expected passes		648
# of unexpected failures	2
# of unsupported tests		202

		=== g++ tests ===

Running target unix/-m32

		=== g++ Summary for unix/-m32 ===

# of expected passes		481
# of unsupported tests		132

Running target unix/-m64

		=== g++ Summary for unix/-m64 ===

# of expected passes		481
# of unsupported tests		132

		=== g++ Summary ===

# of expected passes		962
# of unsupported tests		264

Author: kcc
Date: Fri Nov 15 10:31:14 2013
New Revision: 204838

URL: http://gcc.gnu.org/viewcvs?rev=204838&root=gcc&view=rev
Log:
fix PR sanitizer/58994

Modified:
    trunk/libsanitizer/ChangeLog
    trunk/libsanitizer/asan/asan_interceptors.cc

Verified as fixed at r204847 on x86_64-apple-darwin13.