[Qemu-devel] [PATCH RFC] coverity: Improve model for GLib memory allocation

[Qemu-devel] [PATCH RFC] coverity: Improve model for GLib memory allocation

[Markus Armbruster]

In current versions of GLib, g_new() may expand into g_malloc_n(),
which we don't model.  When it does, Coverity can't see the memory
allocation.  Similarly for g_new0(), g_renew(), g_try_new(),
g_try_new0(), g_try_renew().

Model g_try_malloc_n(), g_malloc_n(), g_try_malloc0_n(),
g_malloc0_n(), g_try_realloc_n().  To avoid undue duplication, rewrite
the existing memory allocation models on top of them.

In my local testing, this gets rid of false positives.  But it also
adds a few, and has a few other effects I can't explain.  Posting as
RFC, will follow up with details.

Signed-off-by: Markus Armbruster <armbru@redhat.com>
---
 scripts/coverity-model.c | 80 ++++++++++++++++++++++++++++++------------------
 1 file changed, 50 insertions(+), 30 deletions(-)

diff --git a/scripts/coverity-model.c b/scripts/coverity-model.c
index 4c99a85..4e5508a 100644
--- a/scripts/coverity-model.c
+++ b/scripts/coverity-model.c
@@ -112,55 +112,75 @@ void *calloc(size_t, size_t);
 void *realloc(void *, size_t);
 void free(void *);
 
-void *
-g_malloc(size_t n_bytes)
+void *g_try_malloc_n(size_t nmemb, size_t size)
 {
-    void *mem;
-    __coverity_negative_sink__(n_bytes);
-    mem = malloc(n_bytes == 0 ? 1 : n_bytes);
-    if (!mem) __coverity_panic__();
-    return mem;
+    size_t sz;
+
+    __coverity_negative_sink__(nmemb);
+    __coverity_negative_sink__(size);
+    sz = nmemb * size;
+    return malloc(sz == 0 ? 1 : sz);
 }
 
-void *
-g_malloc0(size_t n_bytes)
+void *g_malloc_n(size_t nmemb, size_t size)
 {
-    void *mem;
-    __coverity_negative_sink__(n_bytes);
-    mem = calloc(1, n_bytes == 0 ? 1 : n_bytes);
-    if (!mem) __coverity_panic__();
-    return mem;
+    void *ptr = g_try_malloc_n(nmemb, size);
+
+    if (!ptr) __coverity_panic__();
+    return ptr;
 }
 
-void g_free(void *mem)
+void *g_try_malloc0_n(size_t nmemb, size_t size)
 {
-    free(mem);
+    if (nmemb == 0 || size == 0) {
+        return malloc(1);
+    }
+    return calloc(nmemb, size);
 }
 
-void *g_realloc(void * mem, size_t n_bytes)
+void *g_malloc0_n(size_t nmemb, size_t size)
 {
-    __coverity_negative_sink__(n_bytes);
-    mem = realloc(mem, n_bytes == 0 ? 1 : n_bytes);
-    if (!mem) __coverity_panic__();
-    return mem;
+    void *ptr = g_try_malloc0_n(nmemb, size);
+
+    if (!ptr) __coverity_panic__();
+    return ptr;
+}
+
+void *g_malloc(size_t size)
+{
+    return g_malloc_n(1, size);
+}
+
+void *g_malloc0(size_t size)
+{
+    return g_malloc0_n(1, size);
+}
+
+void *g_try_realloc_n(void *ptr, size_t nmemb, size_t size)
+{
+    size_t sz;
+
+    __coverity_negative_sink__(nmemb);
+    __coverity_negative_sink__(size);
+    sz = nmemb * size;
+    return realloc(ptr, sz == 0 ? 1 : sz);
 }
 
-void *g_try_malloc(size_t n_bytes)
+void *g_try_realloc(void *ptr, size_t size)
 {
-    __coverity_negative_sink__(n_bytes);
-    return malloc(n_bytes == 0 ? 1 : n_bytes);
+    return g_try_realloc_n(ptr, 1, size);
 }
 
-void *g_try_malloc0(size_t n_bytes)
+void *g_realloc(void *ptr, size_t size)
 {
-    __coverity_negative_sink__(n_bytes);
-    return calloc(1, n_bytes == 0 ? 1 : n_bytes);
+    ptr = g_try_realloc(ptr, size);
+    if (!ptr) __coverity_panic__();
+    return ptr;
 }
 
-void *g_try_realloc(void *mem, size_t n_bytes)
+void g_free(void *ptr)
 {
-    __coverity_negative_sink__(n_bytes);
-    return realloc(mem, n_bytes == 0 ? 1 : n_bytes);
+    free(ptr);
 }
 
 /* Other glib functions */
-- 
1.9.3

Re: [Qemu-devel] [PATCH RFC] coverity: Improve model for GLib memory allocation

[Markus Armbruster]

Local scan results look great on first glance.  Comparing summary.txt, I get

     -2 TAINTED_STRING
      1 MISSING_LOCK
      1 REVERSE_NEGATIVE
     -4 FORWARD_NULL
     -6 CHECKED_RETURN
    -21 RESOURCE_LEAK
      4 TAINTED_SCALAR
     -2 NEGATIVE_RETURNS
     -3 NULL_RETURNS

A closer examination of the RESOURCE_LEAK differences looks finds both
improvements and regressions.  A few defects we've classified as bugs
are gone.  A few false positives appear even though the model tries to
suppress them.

Paolo, can you see anything wrong with my new model?


= RESOURCE_LEAKs new =

== Look like a bug ==

blockdev-nbd.c:35: leaked_handle: Handle variable "fd" going out of scope leaks the handle.

== Look like false positive ==

The ones in qemu-char.c should be suppressed by our model of
g_io_channel_unix_new().  Can't see how it screwed that up.

qemu-char.c:1107: leaked_handle: Handle variable "fd_in" going out of scope leaks the handle.
qemu-char.c:1107: leaked_handle: Handle variable "fd_out" going out of scope leaks the handle.
qemu-char.c:4062: leaked_handle: Handle variable "in" going out of scope leaks the handle.
qemu-char.c:4062: leaked_handle: Handle variable "out" going out of scope leaks the handle.
qemu-char.c:4076: leaked_handle: Handle variable "fd" going out of scope leaks the handle.
qemu-nbd.c:383: leaked_handle: Handle variable "fd" going out of scope leaks the handle.
ui/vnc.c:2930: leaked_handle: Handle variable "csock" going out of scope leaks the handle.
ui/vnc.c:3312: leaked_handle: Handle variable "csock" going out of scope leaks the handle.

== Unsure ==

hw/arm/omap_sx1.c:106: leaked_storage: Variable "__p" going out of scope leaks the storage it points to.
hw/arm/omap_sx1.c:208: leaked_storage: Variable "flash_1" going out of scope leaks the storage it points to.
hw/misc/macio/macio.c:276: leaked_storage: Variable "__p" going out of scope leaks the storage it points to.
hw/misc/macio/macio.c:281: leaked_storage: Variable "timer_memory" going out of scope leaks the storage it points to.
hw/misc/macio/macio.c:299: leaked_storage: Variable "timer_memory" going out of scope leaks the storage it points to.
hw/ppc/e500.c:582: leaked_storage: Variable "__p" going out of scope leaks the storage it points to.
hw/ppc/e500.c:596: leaked_storage: Variable "p" going out of scope leaks the storage it points to.


= RESOURCE_LEAKs gone =

== Dismissed / False Positive ==

block/raw-posix.c:1906: leaked_storage: Variable "local_err" going out of scope leaks the storage it points to.
block/raw-posix.c:1910: leaked_storage: Variable "local_err" going out of scope leaks the storage it points to.
block/raw-posix.c:2165: leaked_storage: Variable "local_err" going out of scope leaks the storage it points to.
block/sheepdog.c:2260: leaked_storage: Variable "local_err" going out of scope leaks the storage it points to.
migration/tcp.c:53: leaked_handle: Ignoring handle opened by "inet_nonblocking_connect(host_port, tcp_wait_for_connect, s, errp)" leaks it.
migration/unix.c:53: leaked_handle: Ignoring handle opened by "unix_nonblocking_connect(path, unix_wait_for_connect, s, errp)" leaks it.

== New / Unclassified ==

hw/i2c/smbus_eeprom.c:158: leaked_storage: Variable "eeprom_buf" going out of scope leaks the storage it points to.
hw/mips/mips_malta.c:864: leaked_storage: Variable "prom_buf" going out of scope leaks the storage it points to.
hw/mips/mips_r4k.c:142: leaked_storage: Variable "params_buf" going out of scope leaks the storage it points to.
hw/ppc/mac_newworld.c:497: leaked_storage: Variable "openpic_irqs" going out of scope leaks the storage it points to.
hw/ppc/mac_oldworld.c:354: leaked_storage: Variable "heathrow_irqs" going out of scope leaks the storage it points to.

== Triaged / Bug ==

These are worrying.  Something wrong with my new model?

hw/s390x/s390-pci-bus.c:195: leaked_storage: Variable "sei_cont" going out of scope leaks the storage it points to.
vl.c:1065: leaked_storage: Ignoring storage allocated by "monitor_fdset_add_fd(dupfd, true, fdset_id, (fd_opaque ? 1 : 0), fd_opaque, NULL)" leaks it.


= Local RESOURCE_LEAKs gone =

Local means my local scan has them, but the Coverity Scan service
doesn't.  No idea why.

== Look like false positive ==

block/qapi.c:368: leaked_storage: Variable "info" going out of scope leaks the storage it points to.
hw/lm32/lm32_boards.c:164: leaked_storage: Variable "reset_info" going out of scope leaks the storage it points to.
hw/lm32/lm32_boards.c:297: leaked_storage: Variable "reset_info" going out of scope leaks the storage it points to.
hw/lm32/milkymist.c:211: leaked_storage: Variable "reset_info" going out of scope leaks the storage it points to.
hw/mips/mips_mipssim.c:233: leaked_storage: Variable "reset_info" going out of scope leaks the storage it points to.
hw/sh4/r2d.c:353: leaked_storage: Variable "reset_info" going out of scope leaks the storage it points to.
hw/sparc/leon3.c:217: leaked_storage: Variable "reset_info" going out of scope leaks the storage it points to.
hw/sparc64/sun4u.c:812: leaked_storage: Variable "reset_info" going out of scope leaks the storage it points to.
qga/main.c:612: leaked_storage: Variable "obj" going out of scope leaks the storage it points to.

== Leaks on error path to exit() ==

Function leaks on error path, but caller exit()s on error, so we don't
care.

xen-hvm.c:1100: leaked_storage: Variable "state" going out of scope leaks the storage it points to.
xen-hvm.c:1106: leaked_storage: Variable "state" going out of scope leaks the storage it points to.

== Look like a bug ==

numa.c:414: leaked_storage: Variable "err" going out of scope leaks the storage it points to.

== Unsure ==

hw/mips/mips_fulong2e.c:171: leaked_storage: Variable "prom_buf" going out of scope leaks the storage it points to.

Re: [Qemu-devel] [PATCH RFC] coverity: Improve model for GLib memory allocation

[Paolo Bonzini]

On 22/01/2015 15:55, Markus Armbruster wrote:
> == Look like a bug ==
> 
> blockdev-nbd.c:35: leaked_handle: Handle variable "fd" going out of scope leaks the handle.

It's a false positive.

After nbd_client_new calls nbd_send_negotiate, either it returns or
client escapes via QTAILQ_INSERT_TAIL (either in nbd_client_new or in
nbd_handle_export_name).

So I think it's the same as below.


> == Look like false positive ==
> 
> The ones in qemu-char.c should be suppressed by our model of
> g_io_channel_unix_new().  Can't see how it screwed that up.

It seems okay to me too, but these are exactly the false positive that
the g_malloc model is supposed to avoid...

Paolo

> qemu-char.c:1107: leaked_handle: Handle variable "fd_in" going out of scope leaks the handle.
> qemu-char.c:1107: leaked_handle: Handle variable "fd_out" going out of scope leaks the handle.
> qemu-char.c:4062: leaked_handle: Handle variable "in" going out of scope leaks the handle.
> qemu-char.c:4062: leaked_handle: Handle variable "out" going out of scope leaks the handle.
> qemu-char.c:4076: leaked_handle: Handle variable "fd" going out of scope leaks the handle.
> qemu-nbd.c:383: leaked_handle: Handle variable "fd" going out of scope leaks the handle.
> ui/vnc.c:2930: leaked_handle: Handle variable "csock" going out of scope leaks the handle.
> ui/vnc.c:3312: leaked_handle: Handle variable "csock" going out of scope leaks the handle.

Re: [Qemu-devel] [PATCH RFC] coverity: Improve model for GLib memory allocation

[Thomas Huth]

On Thu, 22 Jan 2015 15:55:27 +0100
Markus Armbruster <armbru@redhat.com> wrote:
...
> 
> == Triaged / Bug ==
> 
> These are worrying.  Something wrong with my new model?
> 
> hw/s390x/s390-pci-bus.c:195: leaked_storage: Variable "sei_cont" going out of scope leaks the storage it points to.

Did you already include the fix for the sei_count leak before you ran
the test?
(http://lists.nongnu.org/archive/html/qemu-devel/2015-01/msg02348.html)

 Thomas

Re: [Qemu-devel] [PATCH RFC] coverity: Improve model for GLib memory allocation

[Markus Armbruster]

Paolo Bonzini <pbonzini@redhat.com> writes:

> On 22/01/2015 15:55, Markus Armbruster wrote:
>> == Look like a bug ==
>> 
>> blockdev-nbd.c:35: leaked_handle: Handle variable "fd" going out of
>> scope leaks the handle.
>
> It's a false positive.
>
> After nbd_client_new calls nbd_send_negotiate, either it returns or
> client escapes via QTAILQ_INSERT_TAIL (either in nbd_client_new or in
> nbd_handle_export_name).
>
> So I think it's the same as below.
>
>
>> == Look like false positive ==
>> 
>> The ones in qemu-char.c should be suppressed by our model of
>> g_io_channel_unix_new().  Can't see how it screwed that up.
>
> It seems okay to me too, but these are exactly the false positive that
> the g_malloc model is supposed to avoid...

Hmm, I forgot to model g_realloc_n().  And I think I can improve the
modelling of "can / can't return null".  Let me tinker some more...

[...]

Re: [Qemu-devel] [PATCH RFC] coverity: Improve model for GLib memory allocation

[Markus Armbruster]

Thomas Huth <thuth@linux.vnet.ibm.com> writes:

> On Thu, 22 Jan 2015 15:55:27 +0100
> Markus Armbruster <armbru@redhat.com> wrote:
> ...
>> 
>> == Triaged / Bug ==
>> 
>> These are worrying.  Something wrong with my new model?
>> 
>> hw/s390x/s390-pci-bus.c:195: leaked_storage: Variable "sei_cont"
>> going out of scope leaks the storage it points to.
>
> Did you already include the fix for the sei_count leak before you ran
> the test?
> (http://lists.nongnu.org/archive/html/qemu-devel/2015-01/msg02348.html)

No.  The model in this RFC patch is flawed.  I've since posted one that
behaves :)