twitter.com/ottom6k/status
This is also the case on GrapheneOS with hardened_malloc, and with the previous port of OpenBSD malloc. The behavior of freeing on realloc of size 0 comes from glibc and was copied by jemalloc for compatibility. Android got it when adopting jemalloc.
Conversation
Replying to
Relevant code in jemalloc:
github.com/jemalloc/jemal
Android has a Compatibility Test Suite (CTS) test checking for the non-compliant glibc/jemalloc behavior. Can see that I marked it as an intentional failure in this 10 month old CTS results comparison:
1
1
The other real failures identified there (as opposed to flaky tests) ended up being upstream memory corruption bugs, most of which are now addressed. CTS is a massive test suite incorporating a bunch of internal/external test suites & often I consider the bug to be in the test...
1
1
I would much rather have memory leaks than double frees and software relying on realloc of size 0 to free memory is expecting dangerous non-standards-compliant behavior. It's a backwards compatibility hack with serious consequences as can be seen from this WhatsApp vulnerability.
1
4
I felt a bit uneasy about breaking compatibility like this, but this is a nice confirmation that I'm doing the right thing in this case. I try to avoid causing CTS failures, but sometimes the CTS is wrong and I'm perfectly happy to have a couple dozen well understood failures.
1
3