pointer not owned error when calling malloc_usable_size() on array of structs with destructors

[GoogleCodeExporter]

adar@adar-ThinkPad-T540p:/tmp$ cat test.cc
#include <malloc.h>

struct Blah {
  ~Blah() {}
  long long a;
};

int main(int argc, char* argv[]) {
  Blah* foo = new Blah[1];
  malloc_usable_size(foo);
  delete [] foo;
  return 0;
}

adar@adar-ThinkPad-T540p:/tmp$ ~/Source/llvm-build/bin/clang++ 
-fsanitize=address -o test test.cc
adar@adar-ThinkPad-T540p:/tmp$ ./test
=================================================================
==16156==ERROR: AddressSanitizer: attempting to call malloc_usable_size() for 
pointer which is not owned: 0x60200000eff8
    #0 0x4b4ed0  (/tmp/test+0x4b4ed0)
    #1 0x4e36e5  (/tmp/test+0x4e36e5)
    #2 0x7f4bcff8ba3f  (/lib/x86_64-linux-gnu/libc.so.6+0x20a3f)
    #3 0x418fd8  (/tmp/test+0x418fd8)

0x60200000eff8 is located 8 bytes inside of 16-byte region 
[0x60200000eff0,0x60200000f000)
allocated by thread T0 here:
    #0 0x4e0ab0  (/tmp/test+0x4e0ab0)
    #1 0x4e36b7  (/tmp/test+0x4e36b7)
    #2 0x7f4bcff8ba3f  (/lib/x86_64-linux-gnu/libc.so.6+0x20a3f)

SUMMARY: AddressSanitizer: bad-malloc_usable_size (/tmp/test+0x4b4ed0) 
==16156==ABORTING

This is using clang from the top of trunk, though I've reproduced it with clang 
3.6 as well.

Original issue reported on code.google.com by ade...@gmail.com on 24 Jun 2015 at 8:59

[GoogleCodeExporter]

I don't think we can do anything here.

new[] for non-trivially-destructible types doesn't return you the pointer to 
the allocated block of memory. It returns you a pointer *inside* the block of 
allocated memory (which is what ASan report tells you), as the beginning of 
allocated block contains an array cookie. I'm pretty sure malloc_usable_size() 
is not guaranteed to
work in this case. It actually doesn't work without ASan. If I add
  printf("%zu\n", malloc_usable_size(foo));
to your example I observe:

$ ./bin/clang++ tmp/test.cc ; ./a.out
18446744073709551608

Original comment by samso...@google.com on 24 Jun 2015 at 9:13

• Changed state: Invalid

[GoogleCodeExporter]

Makes sense, thanks for the detailed explanation.

Original comment by ade...@gmail.com on 24 Jun 2015 at 9:40

[GoogleCodeExporter]

We could scan shadow for heap left redzone. But reporting this issue with new 
is probably a good thing.

Original comment by tetra20...@gmail.com on 25 Jun 2015 at 8:00

[GoogleCodeExporter]

Adding Project:AddressSanitizer as part of GitHub migration.

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

• Added labels: ProjectAddressSanitizer