search for: reallocation

libFLAC has several places like this: if(0 == (ptr = realloc(ptr, size))) return false; which results in memory leaks if realloc fails (the old value of ptr is lost). The patch should fix this. -------------- next part -------------- A non-text attachment was scrubbed... Name: realloc_memleak_fix.patch Type: application/octet-stream Size: 6272 bytes Desc: not available Url :

...tanding, it seems that the result of realloc will not technically alias the original pointer. When the realloc is done in-place the reference <http://en.cppreference.com/w/c/memory/realloc> says: "The original pointer ptr is invalidated and any access to it is undefined behavior (even if reallocation was in-place)." Additionally from the C11 standard <https://port70.net/~nsz/c/c11/n1570.html#6.2.4p2> we have: "The value of a pointer becomes indeterminate when the object it points to (or just past) reaches the end of its lifetime" Is this enough to infer that we can safely...

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

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

--- include/share/alloc.h | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/include/share/alloc.h b/include/share/alloc.h index 914de9ba..63878db0 100644 --- a/include/share/alloc.h +++ b/include/share/alloc.h @@ -168,7 +168,7 @@ static inline void *safe_realloc_add_2op_(void *ptr, size_t size1, size_t size2) free(ptr); return 0; } - return realloc(ptr, size2); + return

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

....org> wrote: > > According to my understanding, it seems that the result of realloc will not technically alias the original pointer. When the realloc is done in-place the reference says: > "The original pointer ptr is invalidated and any access to it is undefined behavior (even if reallocation was in-place)." > > Additionally from the C11 standard we have: > "The value of a pointer becomes indeterminate when the object it points to (or just past) reaches the end of its lifetime" > > Is this enough to infer that we can safely mark realloc as noalias? Real...

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

In Syslinux-5.00, is the goal that the core and .c32 modules alike will use the same heap? There is a bug I am thinking about: - QEmu with 1024 MiB RAM - Syslinux 4.06 - .c32 can realloc() up to 1013 MiB - QEmu with 1024 MiB RAM - Syslinux 5.00-pre9 - .c32 can realloc() up to 45 MiB I am wondering if there's a maximum-allocation-size being hit, or if it's actually a bug I should look

Hello, I used to use a (somehow complicated) code in C and I have tried to adapt it to be called from R without making an excessive amount of changes. I am afraid I cannot post the code here, but I am going to try to describe the problem as accurately as possible. I have some arguments that are most of the cases required for internal C operations only; but as they are needed a few times as

Call realloc() directly with the pointer to the old data, instead of assigning it to the destination variable, and using that one. The rest of the code is the same, already properly checking for the results of realloc(), so this mostly help static code analyzers. --- common/qemuopts/qemuopts.c | 6 ++---- 1 file changed, 2 insertions(+), 4 deletions(-) diff --git a/common/qemuopts/qemuopts.c

Quoting Uwe Bonnes <bon@elektron.ikp.physik.tu-darmstadt.de>: > Pavel Tsekov <ptsekov@syntrex.com> wrote: > :> > :> Pavel Tsekov <ptsekov@syntrex.com> wrote: > :> : fixme:msvcrt:MSVCRT_signal (11 (nil)):stub > :> It seems to me like you are using builtin MSVCRT. Signal Handling is > broken > :> there. If the programm uses signal handling, it

...Data)[200000]); Here is my confusion: Do I always require to allocate the exact number of data elements in a R Matrix? In the above code segment I have clearly exceeded the number of elements that have been allocated but my program doesn't crash. I don't find any specific R functions for reallocation incase my data set grows. How do I reallocate? Is it necessary to reallocate or is R handling the memory management for the matrix that I have allocated? Regards Abhijit Bera [[alternative HTML version deleted]]

----- Original Message ----- > From: "Nuno Lopes" <nunoplopes at sapo.pt> > To: "Hal Finkel" <hfinkel at anl.gov> > Cc: "LLVM Developers Mailing List" <llvmdev at cs.uiuc.edu>, "Sanjoy Das" <sanjoy at playingwithpointers.com>, "Jeremy > Lakeman" <Jeremy.Lakeman at gmail.com>, nlewycky at google.com >

Hello list, I've been playing with com32 programs lately and I've come across a a problem with the realloc function in libcom32. The code that rounds up the size looks to be missing a '~' operator, resulting in it truncating every request to a size of 0-15 bytes. The little patch below fixes it up to match the corresponding line in malloc, which makes it work for me. K. diff

Hi, I have just switched from FreeBSD 4.11 using 3.0.21b to NetBSD 3.0.1 using 3.0.22. With the same configuration, and the same clients, I am now seeing what appears to be some rather large memory leakage [ I am not sure if this is the fault of Samba or NetBSD ]. Eventually the process will run out of memory (machine only has 256MB of RAM) and the Windows clients (2000, SP4 and all the

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,

Hi, Trying to decrease the size of a SEXP variable without reassigning values individually in a loop. So far, I've tried using Realloc, as the follow source demonstrates: SEXP dothis() { SEXP Rblah; PROTECT(Rblah = NEW_INTEGER(6)); int* blah = INTEGER(Rblah); blah[0] = 1; blah[1] = 2; blah[2] = 3; Realloc(Rblah, 3, INTEGER); UNPROTECT(1); return(Rblah); } According to the

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

Add a new guestfs_int_merge_fs_inspections() function that merges the OS inspection information of two inspect_fs instances into one. This function is useful if the inspection information for an OS are gathered by inspecting multiple filesystems. Signed-off-by: Nikos Skalkotos <skalkoto@grnet.gr> --- src/guestfs-internal.h | 1 + src/inspect-fs.c | 115