Markus Armbruster wrote:
Anthony Liguori <aligu...@us.ibm.com> writes:
qemu_malloc() does not allow size=0 to be passed in and aborts on this behavior.
Unfortunately, there is good reason to believe that within qemu, there are a
number of, so far, undetected places that assume size=0 can be safely passed.
Since we do not want to abort unnecessarily in production builds, return
qemu_malloc(1) whenever the version file indicates that this is a production
build.
Also introduce --enable-zero-malloc/--disable-zero-malloc to make this behavior
overridable.
Signed-off-by: Anthony Liguori <aligu...@us.ibm.com>
---
configure | 24 +++++++++++++++++++++++-
qemu-malloc.c | 17 +++++++++++++----
2 files changed, 36 insertions(+), 5 deletions(-)
[...]
diff --git a/qemu-malloc.c b/qemu-malloc.c
index 295d185..e82af26 100644
--- a/qemu-malloc.c
+++ b/qemu-malloc.c
@@ -42,21 +42,30 @@ void qemu_free(void *ptr)
free(ptr);
}
+static int allow_zero_malloc(void)
+{
+#if defined(CONFIG_ZERO_MALLOC)
+ return 1;
+#else
+ return 0;
+#endif
+}
+
void *qemu_malloc(size_t size)
{
- if (!size) {
+ if (!size && !allow_zero_malloc()) {
abort();
}
- return oom_check(malloc(size));
+ return oom_check(malloc(size ? size : 1));
}
void *qemu_realloc(void *ptr, size_t size)
{
if (size) {
return oom_check(realloc(ptr, size));
- } else {
+ } else if (allow_zero_malloc()) {
if (ptr) {
- return realloc(ptr, size);
+ return realloc(ptr, size ? size : 1);
}
}
abort();
This still aborts on qemu_realloc(NULL, 0), even with
CONFIG_ZERO_MALLOC. Intentional?
I guess not. Should it? Seems like a very strange case..
Regards,
Anthony Liguori
--
Regards,
Anthony Liguori
