Open GoogleCodeExporter opened 9 years ago
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
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
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
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
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
Original comment by ramosian.glider@gmail.com
on 30 Jul 2015 at 9:05
Adding Project:AddressSanitizer as part of GitHub migration.
Original comment by ramosian.glider@gmail.com
on 30 Jul 2015 at 9:06
Original issue reported on code.google.com by
euge...@google.com
on 17 Jul 2014 at 8:32