Leak of size 0 reported as leak of size 1

[GoogleCodeExporter]

#include <stdlib.h>

int main() {
  void * volatile p = malloc(0);
  return 0;
}

ERROR: LeakSanitizer: detected memory leaks

Direct leak of 1 byte(s) in 1 object(s) allocated from:

This is confusing and may lead debugging down the wrong path.

Original issue reported on code.google.com by euge...@google.com on 17 Jul 2014 at 8:32

[GoogleCodeExporter]

This is because malloc(0) actually allocates 1 byte in ASan. The allocator 
doesn't support 0-byte allocations. Alas we don't have the luxury of an extra 
metadata bit to distinguish between 0 and 1 byte blocks.

Original comment by earth...@chromium.org on 17 Jul 2014 at 8:52

[GoogleCodeExporter]

It's somewhat tempting to mark this as wontfix :) Is there an example of 
real-world problem it causes? Even if it is reported as a leak, LSan should 
provide an allocation stack trace, so debugging this shouldn't be that hard.

Original comment by samso...@google.com on 17 Jul 2014 at 6:23

[GoogleCodeExporter]

Isn't it perfectly fine to allocate non-zero amount of memory for malloc(0)? 
This could indeed result in a leak in real program.

Original comment by tetra2...@gmail.com on 17 Jul 2014 at 7:48

[GoogleCodeExporter]

See discussion for commit r213120 in cfe ml.
Thinking that allocation size is 1 rather then 0 actually leads report 
investigation down the wrong path.

And yes, this could totally be a real memory leak.

Original comment by euge...@google.com on 17 Jul 2014 at 7:51

[GoogleCodeExporter]

What we could do is have the user_requested_size metadata field always contain 
the actual requested size (possibly 0), and have two accessors (one returns 
user_requested_size for use in reports, the other returns 
max(user_requested_size, 1) for internal use). We just need to go through the 
code carefully and separate the two use cases.

Original comment by earth...@chromium.org on 18 Jul 2014 at 8:35