| Message ID | 1421937913-21613-1-git-send-email-armbru@redhat.com |
|---|---|
| State | New |
| Headers | show |
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.
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.
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
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... [...]
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 :)
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 */
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(-)