qemu-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Qemu-devel] [PATCH] Do not abort on qemu_malloc(0) in production bu


From: Anthony Liguori
Subject: Re: [Qemu-devel] [PATCH] Do not abort on qemu_malloc(0) in production builds
Date: Wed, 09 Dec 2009 15:03:34 -0600
User-agent: Thunderbird 2.0.0.23 (X11/20090825)

Markus Armbruster wrote:
Anthony Liguori <address@hidden> 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 <address@hidden>
---
 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





reply via email to

[Prev in Thread] Current Thread [Next in Thread]