LSan reports a trivial leak non-deterministically

[GoogleCodeExporter]

$ cat leak.cc
#include <string.h>
int main() {
  char *a = new char[20];
  strcpy(a, "Hello!");
  return 0;
}
$ clang++ -fsanitize=address leak.cc
$ ASAN_OPTIONS=detect_leaks=1 ./a.out
# nothing printed
$ ASAN_OPTIONS=detect_leaks=1 ./a.out
=================================================================
==23514==ERROR: LeakSanitizer: detected memory leaks

Direct leak of 20 byte(s) in 1 object(s) allocated from:
    #0 0x442ad5 (/usr/local/google/chrome-asan/src/a.out+0x442ad5)
    #1 0x456594 (/usr/local/google/chrome-asan/src/a.out+0x456594)
    #2 0x7f30697bb76c (/lib/x86_64-linux-gnu/libc.so.6+0x2176c)

SUMMARY: LeakSanitizer: 20 byte(s) leaked in 1 allocation(s).

$ export ASAN_OPTIONS=detect_leaks=1
$ for i in `seq 20`; do ./a.out; done 2>&1 | grep ERROR | wc
4

Original issue reported on code.google.com by ramosian.glider@gmail.com on 3 Oct 2013 at 3:46

[GoogleCodeExporter]

have this been fixed? I can't reproduce this...

Original comment by konstant...@gmail.com on 23 Dec 2013 at 2:27

[GoogleCodeExporter]

As far as I remember, this is caused by the following: the glibc function that 
runs atexit handlers creates a stack array, and the junk pointer that main() 
leaves on the stack can non-deterministically end up inside that array and be 
treated as live. I've been meaning to look into this some more, out of 
curiosity, but I don't think this is something that needs fixing on the LSan 
side.

Original comment by earth...@chromium.org on 23 Dec 2013 at 3:00

[GoogleCodeExporter]

Original comment by earth...@google.com on 12 May 2014 at 11:18

• Changed state: WontFix

[GoogleCodeExporter]

Adding Project:AddressSanitizer as part of GitHub migration.

Original comment by ramosian.glider@gmail.com on 30 Jul 2015 at 9:13

• Added labels: ProjectAddressSanitizer