similar to: [PATCH nbdkit] common/bitmap: Don't fail on realloc (ptr, 0)

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' nbdkit -fv --filter=cow null --run 'qemu-img info $nbd' all fail with: nbdkit: memory[1]: error: realloc: Success Initial git bisect pointed to commit 3166d2bcbfd2 (this is not real cause, it merely

v1 was here: https://www.redhat.com/archives/libguestfs/2019-September/msg00100.html In v2 I've changed the patch so it avoids calling realloc at all in this case. The patch is a bit longer this way. But I don't see any other alternative if we are to avoid having a "realloc wrapper" of some kind that we use everywhere, which I guess we should avoid because it makes plugins

I have some patches I'm working on to fix the cache filter. However this is a prelude. It should be simply pure refactoring. All tests pass still. Rich.

This is exactly the same as v1: https://www.redhat.com/archives/libguestfs/2018-December/msg00004.html except that it now frees the bitmap on unload (which the old code did not - there was always a memory leak). Rich.

v2: https://www.redhat.com/archives/libguestfs/2018-December/msg00039.html v2 -> v3: - Fix all the issues raised in Eric's review. - Precompute some numbers to make the calculations easier. - Calculations now use bitshifts and masks in preference to division and modulo. - Clear existing bits before setting (which fixes a bug in the cache filter). Rich.

The cow and cache filters both use a bitmap mapping virtual disk blocks to status stored in the bitmap. The implementation of the bitmaps is very similar because one was derived from the other when the filters were implemented. The main difference is the cow filter uses a simple bitmap (one bit per block), whereas the cache filter uses two bits per block. This commit abstracts the bitmap

The cow and cache filters both use a bitmap mapping virtual disk blocks to status stored in the bitmap. The implementation of the bitmaps is very similar because one was derived from the other when the filters were implemented. The main difference is the cow filter uses a simple bitmap (one bit per block), whereas the cache filter uses two bits per block. This commit abstracts the bitmap

The cow and cache filters both use a bitmap mapping virtual disk blocks to status stored in the bitmap. The implementation of the bitmaps is very similar because one was derived from the other when the filters were implemented. The main difference is the cow filter uses a simple bitmap (one bit per block), whereas the cache filter uses two bits per block. This commit abstracts the bitmap

On 12/2/18 10:33 AM, Richard W.M. Jones wrote: > The cow and cache filters both use a bitmap mapping virtual disk > blocks to status stored in the bitmap. The implementation of the > bitmaps is very similar because one was derived from the other when > the filters were implemented. > > The main difference is the cow filter uses a simple bitmap (one bit > per block), whereas

When compiling on armv7 it becomes clear from the compiler warnings that the current code is wrong. The bitmap has to be allocated in virtual memory, so use size_t to describe the length of the bitmap. When changing the length of the bitmap, compute the new size as an unsigned 64 bit int, and then check whether or not it is too large to fit into size_t before casting it. ---

On Fri, 23 Jun 2023 23:14:39 +0200, Julia Lawall <Julia.Lawall at inria.fr> wrote: > Use array_size to protect against multiplication overflows. > > The changes were done using the following Coccinelle semantic patch: > > // <smpl> > @@ > expression E1, E2; > constant C1, C2; > identifier alloc = {vmalloc,vzalloc}; > @@ > > ( >

This adds a cache filter, which works like the COW filter in reverse. For realistic use it needs a bit more work, especially to add limits on the size of the cache, a more sensible cache replacement policy, and perhaps some kind of background worker to write dirty blocks out. Rich.

Here's the patch (on top of the preceeding one) which uses a bitmap instead of SEEK_DATA. Rich. -- Richard Jones, Virtualization Group, Red Hat http://people.redhat.com/~rjones Read my programming and virtualization blog: http://rwmj.wordpress.com libguestfs lets you edit virtual machines. Supports shell scripting, bindings from many languages. http://libguestfs.org --4VrXvz3cwkc87Wze

Eric, you'll probably find the design "interesting" ... It does work, for me at least. Rich.

It's useful to be able to search for the next non-zero entry in a bitmap. This commit adds a ?bitmap_next? function to do that. Because the bitmap is just a uint8_t buffer, using fast string functions we should be able to do this quickly even if the bitmap is sparse. (However the actual implementation is not optimized since that is quite complicated - see to-do comments in

OpenSSH developers, I have removed the fixed, arbitrary limit on the number of ListenAddress allowed by using realloc to dynamically expand listen_socks as needed. This completely removes MAX_LISTEN_SOCKS from the source. I made this change on the version of OpenSSH shipped with CentOS 5.2, version 4.3p2. Please see the attached .c file and .diff file. Please add these changes to OpenSSH

Hello, I've been writing a program in C that will be called by R. I seem to have stumbled upon an odd error that seems to suggest there is a limit on the number of times "Realloc" (the R version as defined in the manual "R-extenstions" not the C version "realloc") when I try to use the following program: #include <R.h> #include <Rinternals.h> SEXP

https://bugzilla.mindrot.org/show_bug.cgi?id=2684 Bug ID: 2684 Summary: calling realloc with a size <= 0 Product: Portable OpenSSH Version: -current Hardware: amd64 OS: FreeBSD Status: NEW Severity: normal Priority: P5 Component: Miscellaneous Assignee: unassigned-bugs at

Hello, I'm trying to use rjson to parse a JSON object. The object can be found here http://pastebin.com/np0s5hgM (you'll probably need to add quotes around the content) fromJSON returns the error glibc detected home/sguha/lib64/R/bin/exec/R: realloc(): invalid next size: 0x000000000209e210 *** Is there a fix coming soon? Maybe CRAN should also have an outstanding bug field -

In bits.c\speex_bits_pack there is logic to reallocate the bits buffer. In that section there is a call to speex_memset_bytes which appears to wipe out all the old bytes. I found when I encoded a multi-frame message that needed less than the default 2000 bytes for bits->chars, everything worked fine. However, when I encoded a longer message that triggered the realloc code in speex_bits_pack,