The following commands: nbdkit -fv --filter=cow memory size=512 --run 'qemu-img info $nbd' nbdkit -fv --filter=cache memory size=512 --run 'qemu-img info $nbd' both fail with: nbdkit: memory[1]: error: realloc: Success Initial git bisect pointed to commit 3166d2bcbfd2 (but I don't believe that commit is the real cause, it merely exposes the bug). The reason this happens is because the new behaviour after commit 3166d2bcbfd2 is to round down the size of the underlying disk to the cow/cache filter block size (4096 bytes). => The size of the disk is rounded down to 0. => The cow/cache filter requests a bitmap of size 0. => We call realloc (ptr, 0). => realloc returns NULL + errno == 0 in this case since it is not an error. The current commit changes the realloc call so that it does not fail in this case. There are many other places in nbdkit where we call realloc, and I did not vet any of them to see if similar bugs could be present, but it is quite likely. Note that the correct use of the cow/cache filter in this case is to combine it with the truncate filter, eg: nbdkit -fv --filter=cow --filter=truncate memory size=512 round-up=4096 --- common/bitmap/bitmap.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/common/bitmap/bitmap.c b/common/bitmap/bitmap.c index caac916..6bf04dc 100644 --- a/common/bitmap/bitmap.c +++ b/common/bitmap/bitmap.c @@ -60,7 +60,7 @@ bitmap_resize (struct bitmap *bm, uint64_t new_size) new_bm_size = (size_t) new_bm_size_u64; new_bitmap = realloc (bm->bitmap, new_bm_size); - if (new_bitmap == NULL) { + if (new_bm_size && new_bitmap == NULL) { nbdkit_error ("realloc: %m"); return -1; } -- 2.23.0