On 8/4/20 5:09 AM, Daniel P. Berrangé wrote:
On Mon, Aug 03, 2020 at 07:29:19PM +0200, Peter Krempa wrote:
On Mon, Aug 03, 2020 at 19:18:53 +0200, Ján Tomko wrote:
Signed-off-by: Ján Tomko <jto...@redhat.com>
---
src/util/virbitmap.c | 20 ++++++--------------
1 file changed, 6 insertions(+), 14 deletions(-)
diff --git a/src/util/virbitmap.c b/src/util/virbitmap.c
index 4c205016ff..f7dd5d05ad 100644
--- a/src/util/virbitmap.c
+++ b/src/util/virbitmap.c
[...]
@@ -126,10 +121,9 @@ virBitmapNewEmpty(void)
void
virBitmapFree(virBitmapPtr bitmap)
{
- if (bitmap) {
- VIR_FREE(bitmap->map);
- VIR_FREE(bitmap);
- }
+ if (bitmap)
+ g_free(bitmap->map);
Preferrably keep this VIR_FREE or it's expansion to g_clear_pointer. If
a caller uses a stale pointer, it will crash on dereferencing this part.
There's no strong reason to do that in a vir*Free() function, since
'bitmap' itself is being freed.
I think he was pointing out that if you zero out the contents of the
virBitmap object before you free it, then a caller who mistakenly keeps
around a pointer to "bitmap" after calling virBitmapFree(bitmap), and
then attempts to use it, thus causing a dereference of bitmap->map, will
get an immediate segfault rather than using some chunk of memory that
may have already been allocated to something else.
This is a useful concept, but unless we do it *everywhere*, making a
special case here and there isn't going to have much effect (that was
the implication of my original response) - it's kind of emptying the
ocean with a tea spoon. (and also it makes the code uglier and more
confusing). Now if we could efficiently zero out all blocks of memory as
they were freed, then maybe there would be some real bug catching value.
