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.

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).

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];
  }
}

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

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+Asserts/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+Asserts/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::Atom<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

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

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/functional:
In static member function ‘static bool std::tr1::_Function_base::_Base_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/functional:904:
error: cannot use typeid with -fno-rtti
/usr/lib/gcc/x86_64-redhat-linux/4.1.2/../../../../include/c++/4.1.2/tr1/functional:
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/functional:982:
error: cannot use typeid with -fno-rtti
/usr/lib/gcc/x86_64-redhat-linux/4.1.2/../../../../include/c++/4.1.2/tr1/functional_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.

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

=====================================================================
#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.

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. 

$ 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

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.

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

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.

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.

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. 

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-line-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.

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.

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.

$ 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

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;
}

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.

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?
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

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

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;
}

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))

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.

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. 

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

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.

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.

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

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

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;
}

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)

What steps will reproduce the problem?
1.Copy HelloWorld.html and two HelloWorld.class files to same folder.
2.Open HelloWorld.html in chrome web browser built with asan.
3. If applet is blocked due to lack of permission click on Run this time button.
Applet will not load and asan displays this error message.

==2022== ERROR: AddressSanitizer heap-buffer-overflow on address 0x7fe0eb6acaae at
pc 0x7fe1040ab9d9 bp 0x7fffd07c76a0 sp 0x7fffd07c7660
READ of size 1 at 0x7fe0eb6acaae thread T0
    #0 0x7fe1040ab9d9 in strlen /usr/local/google/asan/address-sanitizer/asan/asan_interceptors.cc:270
    #1 0x7fe0fae82112 in IA__g_strdup /build/buildd/glib2.0-2.24.1/glib/gstrfuncs.c:101
    #2 0x7fe0fae83cff in IA__g_strsplit /build/buildd/glib2.0-2.24.1/glib/gstrfuncs.c:2431
    #3 0x7fe0eb174eea in ?? ??:0
    #4 0x7fe0eb17524d in ?? ??:0
    #5 0x7fe1028b5c55 in _ZN6webkit5npapi14PluginInstance7NPP_NewEtsPPcS3_ /home/chamal/chrome/home/chrome-svn/tarball/chromium/src/webkit/plugins/npapi/plugin_instance.cc:222
    #6 0x7fe1028b58b4 in _ZN6webkit5npapi14PluginInstance5StartERK4GURLPPcS6_ib /home/chamal/chrome/home/chrome-svn/tarball/chromium/src/webkit/plugins/npapi/plugin_instance.cc:157
    #7 0x7fe103e02610 in _ZN6webkit5npapi21WebPluginDelegateImpl10InitializeERK4GURLRKSt6vectorISsSaISsEES9_PNS0_9WebPluginEb
/home/chamal/chrome/home/chrome-svn/tarball/chromium/src/webkit/plugins/npapi/webplugin_delegate_impl.cc:90
    #8 0x7fe1033fce36 in _ZN21WebPluginDelegateStub6OnInitERK21PluginMsg_Init_ParamsPb
/home/chamal/chrome/home/chrome-svn/tarball/chromium/src/content/plugin/webplugin_delegate_stub.cc:194
    #9 0x7fe103400360 in _ZN3IPC11ParamTraitsIbE5WriteEPNS_7MessageERKb /home/chamal/chrome/home/chrome-svn/tarball/chromium/src/./ipc/ipc_message_utils.h:187
    #10 0x7fe1033fa611 in ~Tuple1 /home/chamal/chrome/home/chrome-svn/tarball/chromium/src/./base/tuple.h:79
    #11 0x7fe0fffd3738 in _ZN13MessageRouter12RouteMessageERKN3IPC7MessageE /home/chamal/chrome/home/chrome-svn/tarball/chromium/src/content/common/message_router.cc:46
    #12 0x7fe1039b8621 in _ZN13NPChannelBase17OnMessageReceivedERKN3IPC7MessageE /home/chamal/chrome/home/chrome-svn/tarball/chromium/src/content/common/np_channel_base.cc:169
    #13 0x7fe1033f2bb5 in _ZN13PluginChannel17OnMessageReceivedERKN3IPC7MessageE /home/chamal/chrome/home/chrome-svn/tarball/chromium/src/content/plugin/plugin_channel.cc:202
    #14 0x7fe10004baa9 in _ZN3IPC12ChannelProxy7Context17OnDispatchMessageERKNS_7MessageE
/home/chamal/chrome/home/chrome-svn/tarball/chromium/src/ipc/ipc_channel_proxy.cc:263
    #15 0x7fe1000558c4 in _ZN3IPC11SyncChannel20ReceivedSyncMsgQueue16DispatchMessagesEPNS0_11SyncContextE
/home/chamal/chrome/home/chrome-svn/tarball/chromium/src/ipc/ipc_sync_channel.cc:110
    #16 0x7fe100058c76 in _ZN3IPC11SyncChannel23OnWaitableEventSignaledEPN4base13WaitableEventE
/home/chamal/chrome/home/chrome-svn/tarball/chromium/src/ipc/ipc_sync_channel.cc:516
    #17 0x7fe0fe8e86bf in _ZNK4base8CallbackIFvvEE3RunEv /home/chamal/chrome/home/chrome-svn/tarball/chromium/src/./base/callback.h:274
    #18 0x7fe0fe8e8f56 in _ZN11MessageLoop21DeferOrRunPendingTaskERKN4base11PendingTaskE
/home/chamal/chrome/home/chrome-svn/tarball/chromium/src/base/message_loop.cc:512
    #19 0x7fe0fe8ea25f in _ZN11MessageLoop6DoWorkEv /home/chamal/chrome/home/chrome-svn/tarball/chromium/src/base/message_loop.cc:702
    #20 0x7fe0fe986fff in _ZN4base15MessagePumpGlib14HandleDispatchEv /home/chamal/chrome/home/chrome-svn/tarball/chromium/src/base/message_pump_glib.cc:278
    #21 0x7fe0fae618c2 in g_main_dispatch /build/buildd/glib2.0-2.24.1/glib/gmain.c:1960
    #22 0x7fe0fae65748 in g_main_context_iterate /build/buildd/glib2.0-2.24.1/glib/gmain.c:2591
    #23 0x7fe0fae658fc in IA__g_main_context_iteration /build/buildd/glib2.0-2.24.1/glib/gmain.c:2654
    #24 0x7fe0fe98a001 in _ZN4base14MessagePumpGtk7RunOnceEP13_GMainContextb /home/chamal/chrome/home/chrome-svn/tarball/chromium/src/base/message_pump_gtk.cc:41
    #25 0x7fe0fe987ab5 in _ZN4base15MessagePumpGlib17RunWithDispatcherEPNS_11MessagePump8DelegateEPNS_21MessagePumpDispatcherE
/home/chamal/chrome/home/chrome-svn/tarball/chromium/src/base/message_pump_glib.cc:209
    #26 0x7fe0fe8e727e in _ZN11MessageLoop11RunInternalEv /home/chamal/chrome/home/chrome-svn/tarball/chromium/src/base/message_loop.cc:460
    #27 0x7fe0fe8e55cf in ~AutoRunState /home/chamal/chrome/home/chrome-svn/tarball/chromium/src/base/message_loop.cc:774
    #28 0x7fe1033ef9ac in _Z10PluginMainRKN7content18MainFunctionParamsE /home/chamal/chrome/home/chrome-svn/tarball/chromium/src/content/plugin/plugin_main.cc:164
    #29 0x7fe0fe83c91c in _ZN12_GLOBAL__N_123RunNamedProcessTypeMainERKSsRKN7content18MainFunctionParamsEPNS2_19ContentMainDelegateE
/home/chamal/chrome/home/chrome-svn/tarball/chromium/src/content/app/content_main.cc:263
    #30 0x7fe0fe83c0b2 in _ZN7content11ContentMainEiPPKcPNS_19ContentMainDelegateE
/home/chamal/chrome/home/chrome-svn/tarball/chromium/src/content/app/content_main.cc:454
    #31 0x7fe0fd054fc7 in ChromeMain /home/chamal/chrome/home/chrome-svn/tarball/chromium/src/chrome/app/chrome_main.cc:32
    #32 0x7fe0fd054eeb in main /home/chamal/chrome/home/chrome-svn/tarball/chromium/src/chrome/app/chrome_exe_main_gtk.cc:18
    #33 0x7fe0f65f7c4d in __libc_start_main /build/buildd/eglibc-2.11.1/csu/libc-start.c:258
    #34 0x7fe0fd054e09 in _start ??:0
0x7fe0eb6acaae is located 0 bytes to the right of 46-byte region [0x7fe0eb6aca80,0x7fe0eb6acaae)
allocated by thread T0 here:
    #0 0x7fe1040b0177 in malloc /usr/local/google/asan/address-sanitizer/asan/asan_malloc_linux.cc:49
    #1 0x7fe1039cf6c4 in _Z15CreateNPVariantRK15NPVariant_ParamP13NPChannelBaseP10_NPVariantlRK4GURL
/home/chamal/chrome/home/chrome-svn/tarball/chromium/src/content/common/npobject_util.cc:245
    #2 0x7fe1039c2451 in _ZN13NPObjectProxy13NPGetPropertyEP8NPObjectPvP10_NPVariant
/home/chamal/chrome/home/chrome-svn/tarball/chromium/src/content/common/npobject_proxy.cc:289
    #3 0x7fe1039cfd42 in _ZN12_GLOBAL__N_1L20NPN_GetPropertyPatchEP4_NPPP8NPObjectPvP10_NPVariant
/home/chamal/chrome/home/chrome-svn/tarball/chromium/src/content/common/npobject_util.cc:62
    #4 0x7fe0eb174ed4 in ?? ??:0
==2022== ABORTING
Shadow byte and word:
  0x1ffc1d6d5955: 6
  0x1ffc1d6d5950: 00 00 00 00 00 06 fb fb
More shadow bytes:
  0x1ffc1d6d5930: fd fd fd fd fd fd fd fd
  0x1ffc1d6d5938: fd fd fd fd fd fd fd fd
  0x1ffc1d6d5940: fa fa fa fa fa fa fa fa
  0x1ffc1d6d5948: fa fa fa fa fa fa fa fa
=>0x1ffc1d6d5950: 00 00 00 00 00 06 fb fb
  0x1ffc1d6d5958: fb fb fb fb fb fb fb fb
  0x1ffc1d6d5960: fa fa fa fa fa fa fa fa
  0x1ffc1d6d5968: fa fa fa fa fa fa fa fa
  0x1ffc1d6d5970: 06 fb fb fb fb fb fb fb


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

Applet should load without error.


What version of the product are you using? On what operating system?
Chrome:18.0.966.0 (Developer Build 113593 Linux)
Java Plugin:OpenJDK Runtime Environment (IcedTea6 1.9.10) 
OS: Ubuntu 10.04 64 bit.

Please provide any additional information below.

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. 

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

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?

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)

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.

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 )

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

$ 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

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

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.

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?
$ 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.

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.