jeff-lewis / address-sanitizer Goto Github PK

ASLR is bound to MH_PIE bit in the Mach-O header.
If a binary is built with --no_pie, ASLR is off and there's nothing to worry 
about.

For a program with MH_PIE bit set ASLR can be disabled at runtime:
 -- on Snow Leopard -- by setting DYLD_NO_PIE=1
 -- on Lion -- by passing the _POSIX_SPAWN_DISABLE_ASLR flag to posix_spawnattr_setflags (see http://reverse.put.as/2011/08/11/how-gdb-disables-aslr-in-mac-os-x-lion/)

So there are several ways of dealing with ASLR:
 1. Always build with --no_pie if -faddress-sanitizer is on.
 2. At runtime check that the code segments do not interleave with the shadow and:
   2.1 Print an error message that tells to set DYLD_NO_PIE=1 on 10.6 or build with --no_pie on 10.7
   2.2 Do fork+exec to start a new process with ASLR disabled

Currently, asan does not instrument thread-local globals, but it should. 

Two problems here: 

1. The address of main thread's thread-local is not available at the link time 
where we currently form the array which will be passed to 
__asan_register_globals

2. Need to poison the non-main-thread's copies somehow. 

Currently, we can no mix PIC and non-PIC objects if globals are instrumented


% head a.cc b.cc
==> a.cc <==
#include <stdio.h>
int* CCC = new int;

int *zoo() {
  printf("z1 %p\n", &CCC);
  return CCC;
}

==> b.cc <==
#include <stdio.h>

extern int *CCC;
extern int *zoo();

int main(int argc, char** argv) {
  printf("z2 %p\n", &CCC);
  zoo();
}


./my_clang++ -O2 a.cc -fasan -c -fPIC && gcc -shared a.o -o a.so && 
./my_clang++ -fasan -O2  b.cc a.so -Wl,-rpath=. && ./a.out 
z2 0x60e180
z1 0x7fc063fa2060

# both numbers should be the equal

Currently ASan unpoisons the shadow for stack variables at function exit.
If a process creates subprocess with shared memory, and the subprocess
finishes with _exit(), we never unpoison shadow stack of this
process. Later this stack can be reused, that would lead to false
positives. Ugly reproducer for this:

$ cat clone.cc
#include <malloc.h>
#include <sched.h>
#include <stdio.h>
#include <sys/syscall.h>
#include <sys/types.h>
#include <sys/wait.h>
#include <unistd.h>

const int kStackSize = 1 << 20;
char *child_stack;

//__attribute__((no_address_safety_analysis))
int t1(void *arg) {
  volatile char x[32] = {0};
  fprintf(stderr, "array starts at %p\n", x);
  volatile char *ch = x + 32;
  _exit(1);
}

//__attribute__((no_address_safety_analysis))
int t2(void *arg) {
  volatile char x[96] = {0};
  fprintf(stderr, "array starts at %p\n", x);
  volatile char *ch = x + 32;
  fprintf(stderr, "char at %p = %d\n", ch, (int)*ch);
  _exit(1);
}

void run_process(int (*fn)(void*)) {
  pid_t clone_pid = clone(fn, child_stack, CLONE_FILES | CLONE_VM, NULL, 0, 0, 0);
  sleep(2);
  waitpid(clone_pid, NULL, 0);
  fprintf(stderr, "Worker %d exited!\n", clone_pid);
}

int main() {
  // stack grows down
  child_stack = (char*)malloc(kStackSize) + kStackSize;
  fprintf(stderr, "Workers' stack starts at %p\n", child_stack);
  run_process(t1);
  run_process(t2);
  return 0;
}

$ clang++ -faddress-sanitizer clone.cc
$ ./a.out
Workers' stack starts at 0x7fcb069d1080
array starts at 0x7fcb069d0fc0
Worker 7227 exited!
array starts at 0x7fcb069d0f80
=================================================================
==7228== ERROR: AddressSanitizer stack-buffer-overflow on address 
0x7fcb069d0fa0 at pc 0x404fec bp 0x7fcb069d0dd0 sp 0x7fcb069d0dc8
READ of size 1 at 0x7fcb069d0fa0 thread T0
    #0 0x404fec (/home/samsonov/llvm-project/llvm/projects/compiler-rt/lib/asan/tmp/clone/a.out+0x404fec)
0x7fcb069d0fa0 is located 1048352 bytes inside of 1048576-byte region 
[0x7fcb068d1080,0x7fcb069d1080)
allocated by thread T0 here:
    #0 0x406592 (/home/samsonov/llvm-project/llvm/projects/compiler-rt/lib/asan/tmp/clone/a.out+0x406592)
    #1 0x40537e (/home/samsonov/llvm-project/llvm/projects/compiler-rt/lib/asan/tmp/clone/a.out+0x40537e)
    #2 0x7fcb06af0c4d (/home/samsonov/llvm-project/llvm/projects/compiler-rt/lib/asan/tmp/clone/a.out+0x7fcb06af0c4d)
==7228== ABORTING
Stats: 1M malloced (1M for red zones) by 1 calls
Stats: 0M realloced by 0 calls
Stats: 0M freed by 0 calls
Stats: 0M really freed by 0 calls
Stats: 4M (1025 full pages) mmaped in 1 calls
  mmaps   by size class: 21:2; 
  mallocs by size class: 21:1; 
  frees   by size class: 
  rfrees  by size class: 
Stats: malloc large: 1 small slow: 0
Shadow byte and word:
  0x1ff960d3a1f4: f2
  0x1ff960d3a1f0: 00 f4 f4 f4 f2 f2 f2 f2
More shadow bytes:
  0x1ff960d3a1d0: 00 00 00 00 00 00 00 00
  0x1ff960d3a1d8: 00 00 00 00 f1 f1 f1 f1
  0x1ff960d3a1e0: 04 f4 f4 f4 f2 f2 f2 f2
  0x1ff960d3a1e8: 00 f4 f4 f4 f2 f2 f2 f2
=>0x1ff960d3a1f0: 00 f4 f4 f4 f2 f2 f2 f2
  0x1ff960d3a1f8: 00 00 00 00 f2 f2 f2 f2
  0x1ff960d3a200: 00 f4 f4 f4 f3 f3 f3 f3
  0x1ff960d3a208: 00 00 00 00 00 00 00 00
  0x1ff960d3a210: fa fa fa fa fa fa fa fa
Worker 7228 exited!

If we exit normally (not via _exit()) or add
__attribute__((no_address_safety_analysis)) to the
subprocess callbacks, error reports go away.
However, this may not be feasible if subprocess calls
many functions from different sources. This can also
be solved by:

1) intercepting clone (but there can be syscalls).
2) manually unpoisoning stack of subprocess in a parent process, when
the former exits (using asan interface).

We basically need to implement AsanProcMaps::GetObjectNameAndOffset on Mac and 
then get rid of the sysinfo.cc completely. 

$ cat t.c
int volatile a[5];
int main() {
  a[5] = 1;
  return 0;
}

$ ../../../../build/Release+Asserts/bin/clang -faddress-sanitizer t.c -o t && 
./t
<nothing here>

$ ../../../../build/Release+Asserts/bin/clang++ -faddress-sanitizer t.c -o t pp 
&& ./tpp

=================================================================
==44106== ERROR: AddressSanitizer global-buffer-overflow on address 
0x000100015834 at pc 0x100007230 bp 0x7fff5fbff990 sp 0x7fff5fbff988
WRITE of size 4 at 0x000100015834 thread T0
    #0 0x100007230 (/Users/glider/src/asan/asan-llvm-trunk/llvm/projects/compiler-rt/lib/asan/./t+0x7230)
    #1 0x100007084 (/Users/glider/src/asan/asan-llvm-trunk/llvm/projects/compiler-rt/lib/asan/./t+0x7084)
    #2 0x1 (/Users/glider/src/asan/asan-llvm-trunk/llvm/projects/compiler-rt/lib/asan/./t+0x1)
0x000100015834 is located 0 bytes to the right of global variable 'a (t.c)' 
(0x100015820) of size 20
  'a (t.c)' is ascii string ''
==44106== ABORTING
Stats: 0M malloced (0M for red zones) by 0 calls
Stats: 0M realloced by 0 calls
Stats: 0M freed by 0 calls
Stats: 0M really freed by 0 calls
Stats: 0M (0 full pages) mmaped in 0 calls
  mmaps   by size class: 
  mallocs by size class: 
  frees   by size class: 
  rfrees  by size class: 
Stats: malloc large: 0 small slow: 0
Shadow byte and word:
  0x100020002b06: 4
  0x100020002b00: 00 00 00 00 00 00 04 f9
More shadow bytes:
  0x100020002ae0: 00 00 00 00 00 00 00 00
  0x100020002ae8: 00 00 00 00 00 00 00 00
  0x100020002af0: 00 00 00 00 00 00 00 00
  0x100020002af8: 00 00 00 00 00 00 00 00
=>0x100020002b00: 00 00 00 00 00 00 04 f9
  0x100020002b08: f9 f9 f9 f9 00 00 00 00
  0x100020002b10: 00 00 00 00 00 00 00 00
  0x100020002b18: 00 00 00 00 00 00 00 00
  0x100020002b20: 00 00 00 00 00 00 00 00

Since the compiler option has been renamed to -faddress-sanitizer, the tool's 
connection to pheasants has become unclear.

We need to export symbols that can serve as breakpoints at the places where 
ASan is likely to crash or exit.
It also can be useful to ask the tool to sleep for a while before exiting

Sometimes hard-to-debug errors arise if the runtime library maps the shadow 
memory regions over the existing mappings (those are usually code segments; 
this may occur if ASLR is on (see issue 29) or any of the libraries is forced 
to have a fixed load address (see issue 38)).

We need to detect such situations and report them, because otherwise mmap() 
call may silently pass.

This can be easily done by querying the list of existing mappings, but this is 
generally thread-unsafe, so we may need to add locking to prevent libraries 
from being loaded or unloaded at this time (see man 3 dyld, 
_dyld_register_func_for_add_image() and _dyld_register_func_for_remove_image())

I am assuming this is a Mac-only problem for now, although some variations may 
occur on other systems.

Please add the -C option to addr2line otherwise we get mangled names.  See 
http://sourceware.org/binutils/docs/binutils/addr2line.html.

Programs that link SenTestingKit (aka OCUnit) crash when compiled with 
-faddress-sanitizer.  

On Mac OS X 10.7 with a standard installation of Apple's developer tools into 
/Developer, compile and run this program:

#include <objc/objc-runtime.h>
int main() {
  objc_getClass("NSBundle");
  return 0;
}

like so:
clang -faddress-sanitizer -Xlinker -no_pie -arch i386 
-F/Developer/Library/Frameworks -Xlinker -rpath -Xlinker 
/Developer/Library/Frameworks -framework Foundation -framework SenTestingKit 
foo.c

(See also attachment.)

If you remove "-framework SenTestingKit", the resulting a.out will run and 
complete fine.  With linking SenTestingKit, running a.out crashes with the 
following backtrace:

#0  0x00009176 in wrap_strcmp (s1=0x13a60 "NSBundle", s2=0x0) at 
/Volumes/Data/Users/ken/Projects/Foreign/llvm/llvm/projects/compiler-rt/lib/asan
/asan_interceptors.cc:421
#1  0x9551eea4 in classIsEqual ()
#2  0x9550d188 in NXHashGet ()
#3  0x9550ea51 in look_up_class ()
#4  0x9550f57c in objc_getClass ()
#5  0x000028ea in main ()

and message:

==2701== ERROR: AddressSanitizer crashed on unknown address 0x00000000 (pc 
0x00009176 sp 0xbffff8d0 bp 0xbffff908 T0)
AddressSanitizer can not provide additional info. ABORTING
    #0 0x9176 (/private/tmp/./a.out+0x8176)
    #1 0x9551eea4 (/usr/lib/libobjc.A.dylib+0x16ea4)
    #2 0x9550d188 (/usr/lib/libobjc.A.dylib+0x5188)
    #3 0x9550ea51 (/usr/lib/libobjc.A.dylib+0x6a51)
    #4 0x9550f57c (/usr/lib/libobjc.A.dylib+0x757c)
    #5 0x28ea (/private/tmp/./a.out+0x18ea)
    #6 0x2835 (/private/tmp/./a.out+0x1835)
    #7 0x1 (/private/tmp/./a.out+0x1)
Stats: 0M malloced (0M for red zones) by 0 calls
Stats: 0M realloced by 0 calls
Stats: 0M freed by 0 calls
Stats: 0M really freed by 0 calls
Stats: 0M (0 full pages) mmaped in 0 calls
  mmaps   by size class: 
  mallocs by size class: 
  frees   by size class: 
  rfrees  by size class: 
Stats: malloc large: 0 small slow: 0

Version info:

clang version 3.1 (trunk 150294)
Target: x86_64-apple-darwin11.2.0
Thread model: posix

When the process call fork(), its address space is copied, including the 
instances of AsanThread.

This is generally not a good idea, because any existing pthreads die at fork, 
and accessing their memory becomes incorrect.

I think we should intercept fork(), destroy the non-existing AsanThread 
instances and do something with their shadow.

This LLVM revision 
<http://llvm.org/viewvc/llvm-project?view=rev&revision=131330> has a bug fix 
for LLVM generating invalid AVX instructions.

When I was trying to use AddressSanitizer on Firefox, I was bitten by this bug. 
 The fix is simple, we should just upgrade the LLVM used by AddressSanitizer to 
r131330.

The attached patch does that.

To reproduce, build asan_tests32, run
$ gobjdump -D bin_darwin/asan_test32
...

0013b460 <+[LoadSomething load]>:
 13b460:       55                      push   %ebp
 13b461:       89 e5                   mov    %esp,%ebp
 13b463:       53                      push   %ebx
 13b464:       57                      push   %edi
 13b465:       56                      push   %esi
 13b466:       83 ec 0c                sub    $0xc,%esp
 13b469:       e8 00 00 00 00          call   13b46e <+[LoadSomething
load]+0xe>
 13b46e:       5b                      pop    %ebx
 13b46f:       8d b3 72 75 1b 00       lea    0x1b7572(%ebx),%esi
 13b475:       89 34 24                mov    %esi,(%esp)
 13b478:       e8 4f 77 17 00          call   2b2bcc <_strlen$stub>
 13b47d:       85 c0                   test   %eax,%eax
 13b47f:       74 22                   je     13b4a3 <+[LoadSomething
load]+0x43>
 13b481:       31 ff                   xor    %edi,%edi
 13b483:       8d 9b 72 75 1b 00       lea    0x1b7572(%ebx),%ebx
 13b489:       0f 1f 80 00 00 00 00    nopl   0x0(%eax)
 13b490:       8a 06                   mov    (%esi),%al
 13b492:       88 45 f3                mov    %al,-0xd(%ebp)
 13b495:       89 1c 24                mov    %ebx,(%esp)
 13b498:       46                      inc    %esi
 13b499:       47                      inc    %edi
 13b49a:       e8 2d 77 17 00          call   2b2bcc <_strlen$stub>
 13b49f:       39 c7                   cmp    %eax,%edi
 13b4a1:       72 ed                   jb     13b490 <+[LoadSomething
load]+0x30>
 13b4a3:       83 c4 0c                add    $0xc,%esp
 13b4a6:       5e                      pop    %esi
 13b4a7:       5f                      pop    %edi
 13b4a8:       5b                      pop    %ebx
 13b4a9:       5d                      pop    %ebp
 13b4aa:       c3                      ret
 13b4ab:       0f 1f 44 00 00          nopl   0x0(%eax,%eax,1)
...

, and note the missing __asan_init calls.

This regression was probably introduced by r148842, which introduced 
__attribute__((no_address_safety_analysis)) 

char * s = (char*)malloc(4096);
memset(s+4095, 0, 2);

Here Clang changes "memset 2 bytes" to a single "store i16" instruction, and we 
don't instrument (and fail on) access to the memory outside allocated array.

We've heard about this from external users.
Now I have a repro, thanks to csmith (http://embed.cs.utah.edu/csmith/)

1. Build asan-ified clang
2. run 
  for((i=0; i<16; i++)); do clang -g -O2 small.c -w -o $i.o & done ; wait

clang will eventually crash with 
==25320== ERROR: AddressSanitizer crashed on unknown address 0x7fffc0f10006 (pc 
0x000004bc8c10 sp 0x7fffc0f06580 bp 0x7fffc0f067d0 T0)

where the PC is inside AsanStackTrace::FastUnwindStack 

What steps will reproduce the problem?
1. link the main program against libgflags.so
2. the program runs normally.
3. link the main program against libgflags.a
4. the program crashes and cores dump before main.

What is the expected output? What do you see instead?


What version of the product are you using? On what operating system?
latest llvm 3.1

Please provide any additional information below.
Is there any trick in gflags that makes it incompatible to asan when static 
linked?

The blacklist in the AddressSanitizer pass constructs one big regular 
expression from the blacklist entries. If one of these list entries contains 
something illegal, then the whole regex silently fails and nothing is 
blacklisted. Also no error is emitted for this.

To test this, create a blacklist using:

fun:main
fun:foo??bar
fun:bar

The second line here is invalid (at least it seems to be in the C++ regular 
expression library that is used, as it stopped my blacklist from working. Using 
this blacklist won't have any effect, e.g. main will be instrumented.

Tested using LLVM/Clang/ASan SVN trunk revision 146212 on Linux.

See upstream bug http://llvm.org/bugs/show_bug.cgi?id=12283

clang -mllvm -asan-blacklist=asan_blacklist.ignore
currently fails on a missing asan_blacklist.ignore file.

I improved the error message.

And I prefer a warning over the fatal exit as I have multiple blacklist 
files in relative paths, but only for certain subprojects.
Missing a blacklist file should just produce a warning IMHO.

patch attached.

What steps will reproduce the problem?
$ cat asan-exceptions-test.cc
#include <stdio.h>
#include <string>

class Action {
 public:
  Action() {}
  void PrintString(const std::string& msg) const {
    fprintf(stderr, "%s\n", msg.c_str());
  }
  void Throw(const char& arg) const {
    PrintString("PrintString called!"); // this line is important
    throw arg;
  }
};

int main() {
  const Action a;
  fprintf(stderr, "&a before = %p\n", &a);
  try {
    a.Throw('c');
  } catch (const char&) {
    fprintf(stderr, "&a in catch = %p\n", &a);
  }
  fprintf(stderr, "&a final = %p\n", &a);
  return 0;
}
$ ../my_clang++ -faddress-sanitizer -O2 asan-exceptions-test.cc 
$ ./a.out
&a before = 0x7fff1300e2c0
PrintString called!
&a in catch = 0x101010101010101
&a final = 0x101010101010101

Please use labels and text to provide additional information.

Generated binary incorrectly handles exceptions: the address of local "const 
Action a" is stored in a register (r14 or r15) which is assumed to be 
callee-safe, but which is overwritten when the exception is caught.

As of LLVM@r150812 / asan-tests@r1200,

$ cl /MT /Zi /Fehello.exe <path_to_asan_rtl>/asan_*.cc 
<path_to_tests>/hello_pass.c && hello.exe
...
==4832== ERROR: AddressSanitizer attempting free on address which was not 
malloc()-ed: 0x019f2368
  #0 0x408635  free <path_to_asan_rtl>\asan_malloc_win.cc:38
  #1 0x40e062  __endstdio f:\dd\vctools\crt_bld\self_x86\crt\src\_file.c:198
  #2 0x40e417  doexit f:\dd\vctools\crt_bld\self_x86\crt\src\crt0dat.c:606
  #3 0x40e479  exit f:\dd\vctools\crt_bld\self_x86\crt\src\crt0dat.c:412
  #4 0x40e7e7  __tmainCRTStartup f:\dd\vctools\crt_bld\self_x86\crt\src\crt0.c:272
NOTE: this happens even without intrumentation.

A similar command line with /MTd works fine.

ASan does not catch global buffer overflow in the following example:

#include <stdio.h>

__attribute__((weak)) char zz[10] = "012345678";

int main(void) {
        for (int i = 0; i < 11; ++i) {
                zz[i] = '5';
        }
        printf("%s\n", zz);
        return 0;
}

[deleted issue]

1. application dlopens foo.so
2. asan registers all globals from foo.so
3. application closes foo.so
4. application mmaps some memory to the location where foo.so was before
5. application starts using this mmaped memory, but asan still thinks there are 
globals. 
6. BOOM

I'll create a unit test and then a fix. 

When instrumenting global arrays, we add fixed-size redzones (32 bytes) to them.
If the array has two or more dimensions, we're likely to miss the redzone even 
if the array index is off by one:

char arr[40][40];
char arr2[40];

arr[40][0] = 'a';  // this will hit arr2


We may want to vary the size for two-dimensional arrays depending on their 
sizes.

What steps will reproduce the problem?
1. Compile with -faddress-sanitizer
2. Launch program

What is the expected output? What do you see instead?

Program launching and displaying some information instead I get the check fails.


What version of the product are you using? On what operating system?

/tmp/toto❯  uname -a
Linux host 2.6.32-5-amd64 #1 SMP Wed Jan 12 03:40:32 UTC 2011 x86_64 GNU/Linux
/tmp/toto❯  clangg --version
clang version 3.1 (trunk 148107)
Target: x86_64-unknown-linux-gnu
Thread model: posix

Please provide any additional information below.

/tmp/toto❯ /projects/bin/tool
==30618== CHECK failed: (uintptr_t)&rl >= start && (uintptr_t)&rl < end at 
asan_linux.cc:248
    #0 0x84007b3 (tool+0x84007b3)
Stats: 0M malloced (0M for red zones) by 0 calls
Stats: 0M realloced by 0 calls
Stats: 0M freed by 0 calls
Stats: 0M really freed by 0 calls
Stats: 0M (0 full pages) mmaped in 0 calls
  mmaps   by size class: 
  mallocs by size class: 
  frees   by size class:



A simple test works :

/tmp/toto❯ clangg -g -c simple_main.c; clangg -g -o simple_main simple_main.o
clang: warning: argument unused during compilation: '-mllvm -asan-stack=1'
/tmp/toto❯ ./simple_main 
Do nothing except alloc & dealloc
Display test TEST
/tmp/toto❯ cat simple_main.c 
#include "stdio.h"
#include "stdlib.h"
#include "string.h"

int main(int argc, char const *argv[])
{
    printf("Do nothing except alloc & dealloc\n");
    char *test = calloc(30, sizeof (char));
    strncpy(test, "TEST", 30);
    printf("Display test %s\n", test);

    free(test);
    return 0;
}

This is a meta bug to track all our problems with debug info in asan.
These problems together form one of our major issues. 

- Stability: wrong debug info hurts code with exceptions. 
http://llvm.org/bugs/show_bug.cgi?id=11468

- Debug info quality (can't use gdb properly): 
http://llvm.org/bugs/show_bug.cgi?id=11818
likely caused by stack realignment and related to the one above. 

- Huge size of debug info.  http://llvm.org/bugs/show_bug.cgi?id=7554
I am not sure if the problem is well understood. 
LLVM's debug info on linux is much bigger than with gcc. asan makes it worse. 

- gmlt (minimal line tables). Consider adding a flag similar to gcc's -gmlt 
(http://old.nabble.com/-patch--Add-new--gmlt-option-for-min.-debug-info-with-lin
e-tables-(issue4440072)-td31482851.html).
This will allow to have fully symbolized stacks traces with smaller debug info. 
One option it to implement this as an LLVM pass which will strip all irrelevant 
metadata. 

What steps will reproduce the problem?

$ cat try.c
#include <stdio.h>
int main() { printf("Ok\n"); return(0); }

$ clang -o try -g3 -D__APPLE__ -faddress-sanitizer try.c
$ ./try
Ok==33560== 
CHECK failed: summary at asan_thread_registry.cc:99, pthread_self=0x7fff70989cc0
Segmentation fault

$ gdb ./try
(gdb) r
(gdb) bt
#0  0x0000000000000000 in ?? ()
#1  0x000000010000b3af in __asan::AsanThread::ClearShadowForThreadStack 
(this=0x10242a9a0) at asan_thread.cc:51
#2  0x000000010000b6b1 in __asan::AsanThread::~AsanThread (this=0x10242a9a0) at 
asan_thread.cc:45
#3  0x000000010000c3d0 in __asan::AsanThreadRegistry::~AsanThreadRegistry 
(this=0x10042a9a0) at asan_thread_registry.h:29
#4  0x000000010000fe15 in __tcf_0 () at asan_thread_registry.cc:24
#5  0x00007fff8640a374 in __cxa_finalize ()
#6  0x00007fff8640a28c in exit ()
#7  0x0000000100000f53 in start () at asan_thread_registry.h:28

(gdb) up
(gdb) p *this
$1 = {
  static kInvalidTid = -1, 
  summary_ = 0x0, 
  start_routine_ = 0, 
  arg_ = 0x0, 
  stack_top_ = 0, 
  stack_bottom_ = 0, 
  fake_stack_ = {
    static kMinStackFrameSizeLog = 9, 
    static kMaxStackFrameSizeLog = 16, 
    static kMaxStackMallocSize = 65536, 
    static kNumberOfSizeClasses = 8, 
    stack_size_ = 0, 
    alive_ = false, 
    allocated_size_classes_ = {0, 0, 0, 0, 0, 0, 0, 0}, 
...

$ clang --version
clang version 3.1 (trunk 144800)
Target: x86_64-apple-darwin10.8.0
Thread model: posix

The attached patch fixed it for me

$ cat t.c
#include <stdio.h>
extern void *memmove(void *dest, void *src, size_t n);
int main() {
  char a[] = "Hello World!\n";
  memmove(a+3, a, 5);
  printf("%s\n", a);
  return 0;
}
=============================
$ gcc t.c -o t && ./t
HelHellorld!
=============================
$ clang t.c -o t -fno-builtin -O0  -faddress-sanitizer && ./t 2>&1 | 
scripts/asan_symbolize.py 
==51112== ERROR: AddressSanitizer memcpy-param-overlap: memory ranges 
[0x7fff6904eb43,0x7fff6904eb48) and [0x7fff6904eb40, 0x7fff6904eb45) overlap
    #0 0x1094543b0 in wrap_memcpy (in t) + 128
    #1 0x109450127 in main (in t) + 471
    #2 0x10944ff44 in start (in t) + 52
    #3 0x1
Stats: 0M malloced (0M for red zones) by 0 calls
Stats: 0M realloced by 0 calls
Stats: 0M freed by 0 calls
Stats: 0M really freed by 0 calls
Stats: 0M (0 full pages) mmaped in 0 calls
  mmaps   by size class:
  mallocs by size class:
  frees   by size class:
  rfrees  by size class:
Stats: malloc large: 0 small slow: 0

What steps will reproduce the problem?
1. Get the sources
2. Run the specified command (using Makefile.old)

What is the expected output? What do you see instead?

A series of tests and a successful build.

instead I get : 

----
/private/tmp/wwwi/llvm/projects/compiler-rt/lib/asan/../../../../build/Release+A
sserts/bin/clang++  -faddress-sanitizer -mllvm 
-asan-blacklist=/private/tmp/wwwi/llvm/projects/compiler-rt/lib/asan/tests/asan_
test.ignore -mllvm -asan-stack=1 -mllvm -asan-globals=1 -mllvm 
-asan-mapping-scale=0   -mllvm -asan-mapping-offset-log=-1   -mllvm 
-asan-use-after-return=0 -DASAN_UAR=0 -DASAN_HAS_EXCEPTIONS=1 
-DASAN_NEEDS_SEGV=1 -DASAN_HAS_BLACKLIST=1 -I.. -I../include -Wall 
-fvisibility=hidden -m64 -g -w sample1.o sample1_unittest.o gtest_main.a -o 
sample1_unittest
clang: warning: argument unused during compilation: '-mllvm 
-asan-blacklist=/private/tmp/wwwi/llvm/projects/compiler-rt/lib/asan/tests/asan_
test.ignore'
clang: warning: argument unused during compilation: '-mllvm -asan-stack=1'
clang: warning: argument unused during compilation: '-mllvm -asan-globals=1'
clang: warning: argument unused during compilation: '-mllvm 
-asan-mapping-scale=0'
clang: warning: argument unused during compilation: '-mllvm 
-asan-mapping-offset-log=-1'
clang: warning: argument unused during compilation: '-mllvm 
-asan-use-after-return=0'
/private/tmp/wwwi/llvm/projects/compiler-rt/lib/asan/../../../../build/Release+A
sserts/bin/clang++  -faddress-sanitizer  -Wall -fvisibility=hidden -m64 -g -O3 
bin_darwin/asan_test64.o bin_darwin/asan_globals_test64.o 
bin_darwin/asan_break_optimization64.o bin_darwin/asan_noinst_test64.o 
bin_darwin/asan_interface_test64.o bin_darwin/asan_mac_test64.o \
        -framework Foundation -o bin_darwin/asan_test64  third_party/googletest/make-darwin64/gtest-all.o 
Assertion failed: (0), function targetContent, file 
/SourceCache/ld64/ld64-127.2/src/ld/parsers/macho_relocatable_file.cpp, line 
4898.
0  0x10920c041  __assert_rtn + 81
1  0x10924565e  
mach_o::relocatable::CFStringSection<x86_64>::targetContent(mach_o::relocatable:
:Atom<x86_64> const*, ld::IndirectBindingTable const&, 
mach_o::relocatable::CFStringSection<x86_64>::ContentType*, unsigned int*) + 398
2  0x10924529e  
mach_o::relocatable::CFStringSection<x86_64>::contentHash(mach_o::relocatable::A
tom<x86_64> const*, ld::IndirectBindingTable const&) const + 30
3  0x10924304a  
mach_o::relocatable::Atom<x86_64>::contentHash(ld::IndirectBindingTable const&) 
const + 42
4  0x109273d97  ld::tool::SymbolTable::findSlotForReferences(ld::Atom const*, 
ld::Atom const**) + 439
5  0x109273b3f  ld::tool::SymbolTable::addByReferences(ld::Atom const&) + 31
6  0x109273f3a  ld::tool::SymbolTable::add(ld::Atom const&, bool) + 58
7  0x10927771a  ld::tool::Resolver::doAtom(ld::Atom const&) + 698
8  0x10924714c  
mach_o::relocatable::File<x86_64>::forEachAtom(ld::File::AtomHandler&) const + 
60
9  0x10927022c  
ld::tool::InputFiles::forEachInitialAtom(ld::File::AtomHandler&) const + 44
10  0x109279eda  ld::tool::Resolver::resolve() + 202
11  0x10920c345  main + 549
12  0x1091fb9a4  start + 52
clang: error: linker command failed with exit code 1 (use -v to see invocation)
make[1]: *** [bin_darwin/asan_test64] Error 1
make: *** [b64] Error 2
-----

What version of the product are you using? On what operating system?

$ xcodebuild -version
4.2.1
Build version 4D502

$ sw_vers
ProductName:    Mac OS X
ProductVersion: 10.7.2
BuildVersion:   11C74

Please provide any additional information below.

Svn revision : 149195

I recently tried a Firefox+ASan build with optimization turned on. During 
startup I saw an ASan abort due to a stack buffer overflow in libpng code 
(which only happens in the optimized version). I inspected the code and it's 
impossible that an overflow is happening at the given location.

However, I managed to extract a testcase and minimized it by automatic means 
with respect to code and involved compiler flags. It turned out that the 
combination of -faddress-sanitizer and -Os is the problem, -O2 produces the 
same. Using -O1 or -O0 though works. The test is attached: To reproduce, unpack 
the archive, run "make" and then execute ./main.

Tested this on 64 bit with LLVM/Clang/compiler-rt revision 146212.


Main output is:

==25258== ERROR: AddressSanitizer stack-buffer-overflow on address 
0x7fff94e82cb0 at pc 0x4019ff bp 0x7fff94e82c50 sp 0x7fff94e82c48
READ of size 8 at 0x7fff94e82cb0 thread T0
    #0 0x4019ff (testAsanOptimizeSize/main+0x4019ff)
    #1 0x401929 (testAsanOptimizeSize/main+0x401929)
    #2 0x7f76bd049eff (/lib/x86_64-linux-gnu/libc-2.13.so+0x1eeff)
Address 0x7fff94e82cb0 is located at offset 48 in frame <test> of T0's stack:
  This frame has 1 object(s):
    [32, 54) 'data'


The function init just initializes the buffer while finish just prints the 
values. I moved these to a separate compilation unit so the access isn't 
entirely optimized away.

I have a local test with intentional global OOB.

A few weeks ago the bug was not detectable by ASan, but now it is (not clear 
how - no action was taken).
I'll commit the test as soon as code.google.com stops failing on commit.

Also, I was not able to find the global OOB on SPEC CPU2006 464.h264ref
(see http://code.google.com/p/address-sanitizer/wiki/FoundBugs#Spec_CPU_2006 )

We (asan runtime) often print size_t, uintptr_t and friends as %lx, %lu, and 
sometimes even %ld.

ERROR: AddressSanitizer failed to allocate 0xa4001000 (-1543499776) bytes of 
MmapNewPagesAndPoisonShadow

AFAIK, this will break horribly on Windows.
We should switch to PRI* macros or invent a set of our own.

What steps will reproduce the problem?
1. Build latest Asan (r150801)
2. Try to build a i386 binary (my host is x86_64) that needs to call 
__asan_handle_no_return

What is the expected output? What do you see instead?

No output, I expect a working binary

› clang -g -faddress-sanitizer -fno-omit-frame-pointer -m32 -march=pentiumpro 
-pipe -Dlinux -Di386 -ffunction-sections -fdata-sections -Wno-return-type 
no_return.c
/tmp/no_return-bDQzje.o: In function `functionA':
/tmp/no_return.c:7: undefined reference to `__asan_handle_no_return'
clang: error: linker command failed with exit code 1 (use -v to see invocation)

If I remove the i386 flags it works.

What version of the product are you using? On what operating system?

Linux asa 2.6.32-5-amd64 #1 SMP Wed Jan 12 03:40:32 UTC 2011 x86_64 GNU/Linux

Distributor ID: Debian
Description:    Debian GNU/Linux 6.0 (squeeze)
Release:        6.0
Codename:       squeeze


Please provide any additional information below.

› nm lib/clang/3.1/lib/linux/libclang_rt.asan-x86_64.a  | grep 
__asan_handle_no_return
                 U __asan_handle_no_return
00000000000009a0 T __asan_handle_no_return

› nm lib/clang/3.1/lib/linux/libclang_rt.asan-i386.a  | grep 
__asan_handle_no_return

There are two errors that are reported using Printf instead of Report, in 
asan_allocator.cc:

  691   AsanChunk *m = PtrToChunk((uintptr_t)ptr);
  692   if (m->chunk_state == CHUNK_QUARANTINE) {
  693     Printf("attempting double-free on %p:\n", ptr);
  694     stack->PrintStack();
  695     m->DescribeAddress((uintptr_t)ptr, 1);
  696     ShowStatsAndAbort();
  697   } else if (m->chunk_state != CHUNK_ALLOCATED) {
  698     Printf("attempting free on address which was not malloc()-ed: %p\n", ptr);
  699     stack->PrintStack();
  700     ShowStatsAndAbort();
  701   }


These two errors do not match the error reporting behavior of all other errors 
reported and are not easily recognizable by external tools. I suggest to use 
the attached patch which changes "Printf" to "Report" and adds "ERROR: 
AddressSanitizer" to the output as it is done for all other errors.


Using this small example for double-free (which is not in tests btw):

#include <stdlib.h>
int main() {
  char *x = (char*)malloc(10 * sizeof(char));
  free(x);
  free(x);
  return 0;
}

I get the following error using the unpatched version:

attempting double-free on 0x7f784a9cb180:
    #0 0x7f784bb3d944 (/home/ownhero/homes/mozilla/repos/llvm/projects/compiler-rt/lib/asan/bin_linux/libasan64.so+0x7944)
    #1 0x4008ae (/home/ownhero/homes/mozilla/repos/llvm/projects/compiler-rt/lib/asan/tests/double-free+0x4008ae)
    #2 0x7f784b2a3c9d (/lib64/libc-2.12.so+0x1ec9d)

and with the patch:

==32367== ERROR: AddressSanitizer - attempting double-free on 0x7f784a9cb180:
    #0 0x7f784bb3d944 (/home/ownhero/homes/mozilla/repos/llvm/projects/compiler-rt/lib/asan/bin_linux/libasan64.so+0x7944)
    #1 0x4008ae (/home/ownhero/homes/mozilla/repos/llvm/projects/compiler-rt/lib/asan/tests/double-free+0x4008ae)
    #2 0x7f784b2a3c9d (/lib64/libc-2.12.so+0x1ec9d)


The other branch could be tested using this small program (called it wild-free):

#include <stdlib.h>
int main() {
  char *x = (char*)malloc(10 * sizeof(char));
  x += 10;
  free(x);
  return 0;
}

Chrome uses mach_override framework, and its version differs slightly from that 
we are using. At the moment linking ASan with Chrome tests causes them to fail, 
because we're trying to call instrumented versions of mach_override_ptr(), 
allocateBranchIsland() etc. from the ASan runtime. Even if we don't instrument 
those functions, we still get the wrong implementation of mach_override_ptr, 
which may not cope with some of the functions we need to override.

mach_override is written in C, thus we can't use namespaces.

As described in 
http://code.google.com/p/address-sanitizer/wiki/AddressSanitizer#Getting ,
I checked out the sources and they compile my simple helloworld-style app fine 
with -O1/-O2:

$ ~/asan/asan_clang_Linux/bin/clang -O2 -fasan -g -m32 simple_oob.cpp -o 
simple_oob_asan
$ ~/asan/asan_clang_Linux/bin/clang -O1 -fasan -g -m32 simple_oob.cpp -o 
simple_oob_asan
$ ~/asan/asan_clang_Linux/bin/clang -O0 -fasan -g -m32 simple_oob.cpp -o 
simple_oob_asan
~/asan_clang_Linux/bin/../lib/libasan32.a(asan_rtl32.o): In function 
`Global::DescribeAddrIfMyRedZone(unsigned int)':
~/asan/asan_rtl.cc:305: undefined reference to `__asan_mapping_scale'
~/asan_clang_Linux/bin/../lib/libasan32.a(asan_rtl32.o): In function 
`AddrIsInLowMem':
~/asan/asan_mapping.h:60: undefined reference to `__asan_mapping_offset'
~/asan_clang_Linux/bin/../lib/libasan32.a(asan_rtl32.o): In function 
`AddrIsInHighMem':
~/asan/asan_mapping.h:68: undefined reference to `__asan_mapping_scale'
[many more...]
clang: error: linker command failed with exit code 1 (use -v to see invocation)

Hello,

I realize that it's only been tested on Ubuntu, but I was trying to run it on 
centos (5.6 x86_64).

I assume Ubuntu comes with a newer version of libc, since it's failing to link.

Is there a way to build clang on Centos?

Mike



[root@prague mike]# ./asan/asan_clang_Linux/bin/clang

./asan/asan_clang_Linux/bin/clang: /lib64/libc.so.6: version `GLIBC_2.11'
not found (required by ./asan/asan_clang_Linux/bin/clang)

./asan/asan_clang_Linux/bin/clang: /usr/lib64/libstdc++.so.6: version 
`GLIBCXX_3.4.9' not found (required by ./asan/asan_clang_Linux/bin/clang)

[root@prague mike]# ls -la /lib64/libc.so.6
lrwxrwxrwx 1 root root 11 Apr 14 19:58 /lib64/libc.so.6 -> libc-2.5.so

[root@prague mike]# ls -la /usr/lib64/libstdc++.so.6
lrwxrwxrwx 1 root root 18 Apr 14 19:59 /usr/lib64/libstdc++.so.6 ->
libstdc++.so.6.0.8

[root@prague mike]# more /etc/redhat-release 
CentOS release 5.6 (Final)

llvm r152415, linux x86_64 
% clang -c -w -faddress-sanitizer  -O2 hang.c
<runs forever>

The test was generated by csmith and reduced by creduce. 
Will investigate later. 

typedef short uint16_t;
struct U2 {
  int:0
}
a = { };
b;
fn1 () {
  struct U2 *c[] = { 0, 0, 0, &a, 0 };
  b = 0;
  for (; b != 52; b = (uint16_t) b + 1) {
    struct U2 **d = &c[8];
    *d = c[1];
  }
}

$ runspec --size=test --iterations=1 --loose --tune=base --config=asan-O2-win 
464.h264ref

=================================================================
==9264== ERROR: AddressSanitizer heap-buffer-overflow on address 0x02e64de4 at 
pc 0x544743 bp 0xdeadbeef sp 0x20af3a8
READ of size 4 at 0x02e64de4 thread T0
  #0 0x544743  RDCost_for_macroblocks+0x0x000022d3
  #1 0x570763  encode_one_macroblock+0x0x0001ad33
  #2 0x5868e8  encode_one_slice+0x0x00002d38
  #3 0x4562eb  code_a_picture+0x0x0000029b
  #4 0x4608d1  frame_picture+0x0x00000cf1
  #5 0x45d974  encode_one_frame+0x0x00007214
  #6 0x46f1fe  main+0x0x0000169e
  #7 0x5c509d  __tmainCRTStartup f:\dd\vctools\crt_bld\self_x86\crt\src\crt0.c:266
  #8 0x76943677  BaseThreadInitThunk+0x0x00000012
  #9 0x77009f42  RtlInitializeExceptionChain+0x0x00000063
  #10 0x77009f15  RtlInitializeExceptionChain+0x0x00000036
0x02e64de4 is located 260 bytes to the right of 3168-byte region 
[0x02e64080,0x02e64ce0)
allocated by thread T0 here:
  #0 0x5b6e85  calloc c:\src\llvm\projects\compiler-rt\lib\asan\asan_malloc_win.cc:52
  #1 0x4d662c  get_mem2Dshort+0x0x0000008c
  #2 0x4d6827  get_mem3Dshort+0x0x000000a7
  #3 0x4c81b4  alloc_colocated+0x0x000000a4
  #4 0x50f304  GenerateSequenceParameterSet+0x0x00000914
  #5 0x50df93  GenerateParameterSets+0x0x00000023
  #6 0x46de87  main+0x0x00000327
  #7 0x5c509d  __tmainCRTStartup f:\dd\vctools\crt_bld\self_x86\crt\src\crt0.c:266
  #8 0x76943677  BaseThreadInitThunk+0x0x00000012
  #9 0x77009f42  RtlInitializeExceptionChain+0x0x00000063
  #10 0x77009f15  RtlInitializeExceptionChain+0x0x00000036
==9264== ABORTING
Stats: 12M malloced (11M for red zones) by 10362 calls
Stats: 0M realloced by 0 calls
Stats: 0M freed by 12 calls
Stats: 0M really freed by 0 calls
Stats: 60M (15371 full pages) mmaped in 15 calls
  mmaps   by size class: 8:16383; 9:8191; 10:4095; 11:2047; 12:1024; 13:2560; 14:256; 15:128; 16:64; 17:32; 19:8;
  mallocs by size class: 8:7201; 9:623; 10:10; 11:4; 12:10; 13:2474; 14:19; 15:1; 16:6; 17:13; 19:1;
  frees   by size class: 8:6; 12:1; 13:1; 14:1; 15:1; 16:2;
  rfrees  by size class:
Stats: malloc large: 14 small slow: 183
Shadow byte and word:
  0x205cc9bc: fa
  0x205cc9bc: fa fa fa fa
More shadow bytes:
  0x205cc9ac: fa fa fa fa
  0x205cc9b0: fa fa fa fa
  0x205cc9b4: fa fa fa fa
  0x205cc9b8: fa fa fa fa
=>0x205cc9bc: fa fa fa fa
  0x205cc9c0: fa fa fa fa
  0x205cc9c4: fa fa fa fa
  0x205cc9c8: fa fa fa fa
  0x205cc9cc: fa fa fa fa

This is a piece of Chromium code on Mac:


(gdb) disas $eip $eip+0x20
Dump of assembler code from 0x5e62b97 to 0x5e62bb7:
0x05e62b97 <_ZN27ChromeBrowserMainPartsPosix24PostMainMessageLoopStartEv+439>:  
mov    0x1c(%esp),%eax
0x05e62b9b <_ZN27ChromeBrowserMainPartsPosix24PostMainMessageLoopStartEv+443>:  
lea    0x7006f69(%eax),%eax
0x05e62ba1 <_ZN27ChromeBrowserMainPartsPosix24PostMainMessageLoopStartEv+449>:  
mov    %eax,%ecx
0x05e62ba3 <_ZN27ChromeBrowserMainPartsPosix24PostMainMessageLoopStartEv+451>:  
shr    $0x3,%ecx
0x05e62ba6 <_ZN27ChromeBrowserMainPartsPosix24PostMainMessageLoopStartEv+454>:  
mov    0x20000000(%ecx),%cl
0x05e62bac <_ZN27ChromeBrowserMainPartsPosix24PostMainMessageLoopStartEv+460>:  
mov    0x1c0(%esp),%edx
0x05e62bb3 <_ZN27ChromeBrowserMainPartsPosix24PostMainMessageLoopStartEv+467>:  
test   %cl,%cl
0x05e62bb5 <_ZN27ChromeBrowserMainPartsPosix24PostMainMessageLoopStartEv+469>:  
je     0x5e62bc0 
<_ZN27ChromeBrowserMainPartsPosix24PostMainMessageLoopStartEv+480>
End of assembler dump.

Note that the access to the original memory location (0x1c0(%esp)) occurs 
before the shadow value is actually tested.
Such bugs may potentially cause the program to crash before the error is 
reported (if we're accessing an unmapped region)

Dima suspects this is because we're passing the result of ptrtoint() to the 
reporting function, thus the compiler does not notice that the pointer escapes.

We need to symbolize error messages in process. 
Looks like we can share some code with lldb. 
See http://comments.gmane.org/gmane.comp.debugging.lldb.devel/650

Such code will be useful for other dynamic tools as well. 

I have 64 bit RHEL 5.6, when i try to compile clang build failed. When I go to 
lib/Transforms/Instrumentation/ and run make, here is the output:
[root@nntcl28-2qcht clang_build_Linux]# cd lib/Transforms/Instrumentation/
[root@nntcl28-2qcht Instrumentation]# make
llvm[0]: Compiling AddressSanitizer.cpp for Release+Asserts build
/usr/lib/gcc/x86_64-redhat-linux/4.1.2/../../../../include/c++/4.1.2/tr1/functio
nal: In static member function ‘static bool 
std::tr1::_Function_base::_Base_manager<_Functor>::_M_manager(std::tr1::_Any_dat
a&, const std::tr1::_Any_data&, std::tr1::_Manager_operation)’:
/usr/lib/gcc/x86_64-redhat-linux/4.1.2/../../../../include/c++/4.1.2/tr1/functio
nal:904: error: cannot use typeid with -fno-rtti
/usr/lib/gcc/x86_64-redhat-linux/4.1.2/../../../../include/c++/4.1.2/tr1/functio
nal: In static member function ‘static bool 
std::tr1::_Function_base::_Ref_manager<_Functor>::_M_manager(std::tr1::_Any_data
&, const std::tr1::_Any_data&, std::tr1::_Manager_operation)’:
/usr/lib/gcc/x86_64-redhat-linux/4.1.2/../../../../include/c++/4.1.2/tr1/functio
nal:982: error: cannot use typeid with -fno-rtti
/usr/lib/gcc/x86_64-redhat-linux/4.1.2/../../../../include/c++/4.1.2/tr1/functio
nal_iterate.h: In static member function ‘static bool 
std::tr1::_Function_handler<void ()(), _Member 
_Class::*>::_M_manager(std::tr1::_Any_data&, const std::tr1::_Any_data&, 
std::tr1::_Manager_operation)’:

tr1 headers can't be compiled without rtti but it seems option -fno-rtti 
presented in makefiles. I hope this is root case that my build failed.

This is best reproducible with pdfsqueeze from the Chromium tree (see 
http://dev.chromium.org/developers/testing/addresssanitizer for the build 
instructions; the target name is pdfsqueeze)

# input.pdf must be a valid pdf, probably one of those in the Chromium tree.
$ out/Release/pdfsqueeze input.pdf output.pdf
terminate called after throwing an instance of 'CMMException'
Abort trap

$ gdb out/Release/pdfsqueeze
...
(gdb) break wrap___cxa_throw 
Breakpoint 1 at 0xcb9d
(gdb) r input.pdf output.pdf

Breakpoint 1, 0x0000cb9d in wrap___cxa_throw ()
(gdb) bt
#0  0x0000cb9d in wrap___cxa_throw ()
#1  0x90d0d292 in CMMThrowExceptionOnError ()
#2  0x90d131b7 in CMMCurveTag::CMMCurveTag ()
#3  0x90d15651 in CMMParaCurveTag::CMMParaCurveTag ()
#4  0x90d259f8 in CMMProfile::MakeTag ()
#5  0x90d25dbd in CMMProfile::GetTag ()
#6  0x90d28049 in CMMProfile::GetCurveTag ()
#7  0x90d2808e in CMMProfile::InnerGetMatrixTags ()
#8  0x90d28170 in CMMMatrixDisplayProfile::GetMatrixTags ()
#9  0x90d2d4a7 in ConversionManager::MakeConversionSequence ()
#10 0x90d2eecb in DoInitializeTransform ()
#11 0x90d2f5ec in AppleCMMInitializeTransform ()
#12 0x90d5ec24 in ColorSyncCMMInitializeTransform ()
#13 0x90cffec6 in ColorSyncTransformCreate ()
#14 0x94a5795b in create ()
#15 0x94a51019 in aquireColorWorldByAttributes ()
#16 0x94a50e46 in acquireColorWorld ()
#17 0x94a50d05 in CMSTransformConvertComponents ()
#18 0x99637c9d in CGCMSInterfaceTransformConvertColorComponents ()
#19 0x99636e31 in CGColorTransformConvertColorFloatComponents ()
#20 0x99636cde in CGColorTransformConvertColorComponents ()
#21 0x01728e5a in FilterGStateColor ()
#22 0x01729211 in FilterGState ()
#23 0x0172a155 in ctxftr_DrawPath ()
#24 0x996cd68f in CGContextDrawPath ()
#25 0x996e5c9b in CGPDFDrawingContextDrawPath ()
#26 0x996e7b47 in op_f ()
#27 0x996e4dcc in pdf_scanner_handle_xname ()
#28 0x996e3ed4 in CGPDFScannerScan ()
#29 0x996e1ff0 in CGPDFDrawingContextDrawPage ()
#30 0x996e1c8a in CGContextDrawPDFPageWithProgressCallback ()
#31 0x996e1c24 in CGContextDrawPDFPage ()
#32 0x94c25bf9 in -[PDFPage(PDFPagePrivate) drawWithBox:inContext:] ()
#33 0x94c1e82b in -[PDFPage drawWithBox:] ()
#34 0x94c1c931 in -[PDFDocument(PDFDocumentInternal) 
writeToConsumer:withOptions:] ()
#35 0x94c1be42 in -[PDFDocument writeToURL:withOptions:] ()
#36 0x0000a060 in main (argc=3, argv=<value temporarily unavailable, due to 
optimizations>) at third_party/pdfsqueeze/pdfsqueeze.m:64


(gdb) disas
Dump of assembler code for function wrap___cxa_throw:
0x0000cb90 <wrap___cxa_throw+0>:    push   %ebp
0x0000cb91 <wrap___cxa_throw+1>:    push   %ebx
0x0000cb92 <wrap___cxa_throw+2>:    push   %edi
0x0000cb93 <wrap___cxa_throw+3>:    push   %esi
0x0000cb94 <wrap___cxa_throw+4>:    sub    $0x1c,%esp
0x0000cb97 <wrap___cxa_throw+7>:    call   0xcb9c <wrap___cxa_throw+12>
0x0000cb9c <wrap___cxa_throw+12>:   pop    %esi
0x0000cb9d <wrap___cxa_throw+13>:   call   0x8ae0 
<_ZN6__asan18asanThreadRegistryEv>
0x0000cba2 <wrap___cxa_throw+18>:   mov    %eax,(%esp)
0x0000cba5 <wrap___cxa_throw+21>:   call   0x8c70 
<_ZN6__asan18AsanThreadRegistry10GetCurrentEv>
0x0000cbaa <wrap___cxa_throw+26>:   test   %eax,%eax
0x0000cbac <wrap___cxa_throw+28>:   je     0xcbf9 <wrap___cxa_throw+105>
0x0000cbae <wrap___cxa_throw+30>:   mov    0x38(%esp),%edi
0x0000cbb2 <wrap___cxa_throw+34>:   mov    0x34(%esp),%ebx
0x0000cbb6 <wrap___cxa_throw+38>:   mov    0x30(%esp),%ebp
0x0000cbba <wrap___cxa_throw+42>:   lea    -0xfe8(%esp),%ecx
0x0000cbc1 <wrap___cxa_throw+49>:   and    $0xfffff000,%ecx
0x0000cbc7 <wrap___cxa_throw+55>:   mov    0xc(%eax),%eax
0x0000cbca <wrap___cxa_throw+58>:   sub    %ecx,%eax
0x0000cbcc <wrap___cxa_throw+60>:   mov    %eax,0x4(%esp)
0x0000cbd0 <wrap___cxa_throw+64>:   mov    %ecx,(%esp)
0x0000cbd3 <wrap___cxa_throw+67>:   movl   $0x0,0x8(%esp)
0x0000cbdb <wrap___cxa_throw+75>:   call   0x54f0 <_ZN6__asan12PoisonShadowEmmh>
0x0000cbe0 <wrap___cxa_throw+80>:   mov    %edi,0x8(%esp)
0x0000cbe4 <wrap___cxa_throw+84>:   mov    %ebx,0x4(%esp)
0x0000cbe8 <wrap___cxa_throw+88>:   mov    %ebp,(%esp)
0x0000cbeb <wrap___cxa_throw+91>:   call   *0x64e8(%esi)
0x0000cbf1 <wrap___cxa_throw+97>:   add    $0x1c,%esp
0x0000cbf4 <wrap___cxa_throw+100>:  pop    %esi
0x0000cbf5 <wrap___cxa_throw+101>:  pop    %edi
0x0000cbf6 <wrap___cxa_throw+102>:  pop    %ebx
0x0000cbf7 <wrap___cxa_throw+103>:  pop    %ebp
0x0000cbf8 <wrap___cxa_throw+104>:  ret    
0x0000cbf9 <wrap___cxa_throw+105>:  lea    0x2340(%esi),%eax
0x0000cbff <wrap___cxa_throw+111>:  mov    %eax,0x4(%esp)
0x0000cc03 <wrap___cxa_throw+115>:  lea    0x32d3(%esi),%eax
0x0000cc09 <wrap___cxa_throw+121>:  mov    %eax,(%esp)
0x0000cc0c <wrap___cxa_throw+124>:  movl   $0x1e6,0x8(%esp)
0x0000cc14 <wrap___cxa_throw+132>:  call   0x5f00 
<_ZN6__asan11CheckFailedEPKcS1_i>
0x0000cc19 <wrap___cxa_throw+137>:  nopl   0x0(%eax)
End of assembler dump.

Let's stop before real___cxa_throw:
0x0000cbeb <wrap___cxa_throw+91>:   call   *0x64e8(%esi)

(gdb) break *0x0000cbeb
Breakpoint 4 at 0xcbeb
(gdb) c

(gdb) bt
#0  0x0000cbeb in wrap___cxa_throw ()
#1  0x90d0d292 in CMMThrowExceptionOnError ()
#2  0x90d131b7 in CMMCurveTag::CMMCurveTag ()
#3  0x90d15651 in CMMParaCurveTag::CMMParaCurveTag ()
#4  0x90d259f8 in CMMProfile::MakeTag ()
#5  0x90d25dbd in CMMProfile::GetTag ()
#6  0x90d28049 in CMMProfile::GetCurveTag ()
#7  0x90d2808e in CMMProfile::InnerGetMatrixTags ()
#8  0x90d28170 in CMMMatrixDisplayProfile::GetMatrixTags ()
#9  0x90d2d4a7 in ConversionManager::MakeConversionSequence ()
#10 0x90d2eecb in DoInitializeTransform ()
#11 0x90d2f5ec in AppleCMMInitializeTransform ()
#12 0x90d5ec24 in ColorSyncCMMInitializeTransform ()
#13 0x90cffec6 in ColorSyncTransformCreate ()
#14 0x94a5795b in create ()
#15 0x94a51019 in aquireColorWorldByAttributes ()
#16 0x94a50e46 in acquireColorWorld ()
#17 0x94a50d05 in CMSTransformConvertComponents ()
#18 0x99637c9d in CGCMSInterfaceTransformConvertColorComponents ()
#19 0x99636e31 in CGColorTransformConvertColorFloatComponents ()
#20 0x99636cde in CGColorTransformConvertColorComponents ()
#21 0x01728e5a in FilterGStateColor ()
#22 0x01729211 in FilterGState ()
#23 0x0172a155 in ctxftr_DrawPath ()
#24 0x996cd68f in CGContextDrawPath ()
#25 0x996e5c9b in CGPDFDrawingContextDrawPath ()
#26 0x996e7b47 in op_f ()
#27 0x996e4dcc in pdf_scanner_handle_xname ()
#28 0x996e3ed4 in CGPDFScannerScan ()
#29 0x996e1ff0 in CGPDFDrawingContextDrawPage ()
#30 0x996e1c8a in CGContextDrawPDFPageWithProgressCallback ()
#31 0x996e1c24 in CGContextDrawPDFPage ()
#32 0x94c25bf9 in -[PDFPage(PDFPagePrivate) drawWithBox:inContext:] ()
#33 0x94c1e82b in -[PDFPage drawWithBox:] ()
#34 0x94c1c931 in -[PDFDocument(PDFDocumentInternal) 
writeToConsumer:withOptions:] ()
#35 0x94c1be42 in -[PDFDocument writeToURL:withOptions:] ()
#36 0x0000a060 in main (argc=3, argv=<value temporarily unavailable, due to 
optimizations>) at third_party/pdfsqueeze/pdfsqueeze.m:64

(gdb) stepi
0xffc23000 in ?? ()
(gdb) bt
#0  0xffc23000 in ?? ()
#1  0x0000cbf1 in wrap___cxa_throw ()

Note we already can't unwind at the first instruction of the branch island 
allocated by mach_override_ptr.

(gdb) disas 0xffc23000 0xffc23020
Dump of assembler code from 0xffc23000 to 0xffc23020:
0xffc23000: push   %ebp
0xffc23001: mov    %esp,%ebp
0xffc23003: push   %esi
0xffc23004: push   %ebx
0xffc23005: nop    
0xffc23006: nop    
0xffc23007: nop    
0xffc23008: nop    
0xffc23009: nop    
0xffc2300a: nop    
0xffc2300b: nop    
0xffc2300c: nop    
0xffc2300d: nop    
0xffc2300e: nop    
0xffc2300f: nop    
0xffc23010: jmp    0x91448250 <__cxa_throw+5>
0xffc23015: add    %al,(%eax)
0xffc23017: add    %al,(%ecx)
0xffc23019: add    %al,(%eax)
0xffc2301b: add    %al,(%eax)
0xffc2301d: add    %al,(%eax)
0xffc2301f: add    %al,(%eax)

(gdb) c
Continuing.
terminate called after throwing an instance of 'CMMException'

Program received signal SIGABRT, Aborted.
0x94abac5a in __kill ()

(gdb) bt
#0  0x94abac5a in __kill ()
#1  0x94abac4c in kill$UNIX2003 ()
#2  0x94b4d5a5 in raise ()
#3  0x94b636e4 in abort ()
#4  0x91449fda in __gnu_cxx::__verbose_terminate_handler ()
#5  0x9144817a in __cxxabiv1::__terminate ()
#6  0x914481ba in std::terminate ()
#7  0x914482b8 in __cxa_throw ()
#8  0x0000cbf1 in wrap___cxa_throw ()


I believe the problem with stack unwinding leads to incorrect exception 
handling. If so, other wrapped functions that may throw exceptions (fortunately 
we don't have any yet) may be affected.
If we don't wrap __cxa_throw(), the problem goes away.

asanbot has started reporting failures in GCD tests on Mac OS 10.6 today:
[  FAILED  ] AddressSanitizerMac.GCDDispatchAsync
[  FAILED  ] AddressSanitizerMac.GCDDispatchSync
[  FAILED  ] AddressSanitizerMac.GCDReuseWqthreadsAsync
[  FAILED  ] AddressSanitizerMac.GCDReuseWqthreadsSync
[  FAILED  ] AddressSanitizerMac.GCDDispatchAfter
[  FAILED  ] AddressSanitizerMac.GCDSourceEvent
[  FAILED  ] AddressSanitizerMac.GCDSourceCancel
[  FAILED  ] AddressSanitizerMac.GCDGroupAsync

This may be caused by issue 33 or by something else.

What steps will reproduce the problem?
1. rm -rf third_party/googletest
2. svn co http://googletest.googlecode.com/svn/trunk -r608 
third_party/googletest
3. <rebuild ASan>
4. make -f Makefile.old t32

What is the expected output? What do you see instead?
Linker produces error:
/home/samsonov/llvm-project/llvm-gitbranch/projects/compiler-rt/lib/asan/../../.
./../build/Release+Asserts/bin/clang++  -faddress-sanitizer 
-DADDRESS_SANITIZER=1 -mllvm 
-asan-blacklist=/home/samsonov/llvm-project/llvm-gitbranch/projects/compiler-rt/
lib/asan/tests/asan_test.ignore -mllvm -asan-stack=1 -mllvm -asan-globals=1 
-mllvm -asan-use-call=1 -mllvm -asan-mapping-scale=0   -mllvm 
-asan-mapping-offset-log=-1   -mllvm -asan-use-after-return=0 -DASAN_UAR=0 
-DASAN_HAS_EXCEPTIONS=1 -DASAN_NEEDS_SEGV=1 -DASAN_HAS_BLACKLIST=1 -I../include 
-Wall -fvisibility=hidden -m32 -g -w -lpthread sample1.o sample1_unittest.o 
gtest_main.a -o sample1_unittest

<some clang warnings>

/usr/bin/ld: gtest_main.a(gtest-all.o)(.text+0x7cb7c): unresolvable R_386_PC32 
relocation against symbol `sigaction@@GLIBC_2.0'
/usr/bin/ld: final link failed: Nonrepresentable section on output

=====================================================================
#import <Foundation/Foundation.h>
#import <WebKit/WebKit.h>

@interface WebKitDelegate : NSObject
@end

@implementation WebKitDelegate

- (void)webView:(WebView *)sender didFinishLoadForFrame:(WebFrame *)frame
{
    NSLog(@"didFinishLoadForFrame");
    [sender displayIfNeeded];
    if (frame == [sender mainFrame])
        exit(0);
}

- (NSURLRequest *)webView:(WebView *)sender resource:(id)identifier 
willSendRequest:(NSURLRequest *)request redirectResponse:(NSURLResponse 
*)redirectResponse fromDataSource:(WebDataSource *)dataSource;
{
    NSLog(@"Will send request %@ (redirect %@)",request,redirectResponse);
    return request;
}

- (void)webView:(WebView *)sender resource:(id)identifier 
didReceiveResponse:(NSURLResponse *)response fromDataSource:(WebDataSource 
*)dataSource
{
    NSLog(@"Got response %@",response);
}
@end

int main(int argc, char * const argv[])
{
    //// CFAllocatorSetDefault(kCFAllocatorMallocZone);
    NSAutoreleasePool* pool = [[NSAutoreleasePool alloc] init];
    WebView *webView = [[WebView alloc] initWithFrame:NSMakeRect(0, 0, 800, 600) frameName:nil groupName:@"org.webkit.parseWebKit"];
    WebKitDelegate* delegate = [[WebKitDelegate alloc] init];
    [webView setFrameLoadDelegate:delegate];
    [webView setResourceLoadDelegate:delegate];
    [[webView mainFrame] loadHTMLString:@"<html><body>test</body></html>" baseURL:nil];
    [[NSRunLoop currentRunLoop] run];
    [pool drain];
    return 0;
}
=====================================================================

The program above hangs under ASan. If the "CFAllocatorSetDefault" line is 
uncommented, the program hangs without ASan.

On Mac 64-bit asan start-up is insanely slow. 
I suspect this is caused by mach_override, please investigate.

clang -faddress-sanitizer    output_tests/memcmp_test.cc && ./a.out  2>&1 | 
./scripts/asan_symbolize.py /

READ of size 1 at 0x7fffb2721024 thread T0
    #0 0x407fcd in memcmp _asan_rtl_
    #1 0x402140 in _start ??:0

The second frame should be main(). 

I guess this is because asan-rt is built w/o frame pointers.
I wonder if we can fix it w/o using frame pointers.