search for: alloc'd

...ple, I still have a problem were winbindd panics every time I run it. I'd hoped this might get fixed as newer releases of Samba came out, but I'm now running 3.0.2pre1 and still the same problem. I want to deploy Samba on Solaris, but was unable to successfully get samba to compile with dmalloc support, so I've had to install onto RedHat 8 and use valgrind instead. Please can someone take a look at this error, let me know if any additional infromation is required, thanks in advance, Andy Smith. On Fri, 2003-11-21 at 21:27, ww m-pubsyssamba wrote: > Hi, please find attatched t...

...31534== by 0x44E745E: __nss_lookup_function (in /lib/tls/i686/cmov/libc-2.5.so) ==31534== by 0x44E754F: (within /lib/tls/i686/cmov/libc-2.5.so) ==31534== by 0x44E92B5: __nss_passwd_lookup (in /lib/tls/i686/cmov/libc-2.5.so) ==31534== Address 0x555C874 is 36 bytes inside a block of size 38 alloc'd ==31534== at 0x4021620: malloc (vg_replace_malloc.c:149) ==31534== by 0x4007F33: (within /lib/ld-2.5.so) ==31534== by 0x4010D94: (within /lib/ld-2.5.so) ==31534== by 0x400CFA5: (within /lib/ld-2.5.so) ==31534== by 0x40108ED: (within /lib/ld-2.5.so) ==31534== by 0x450C0A1: (w...

...ease+**Asserts/bin/opt) >> ==5134== by 0x8E37385: llvm::PassManager::run(llvm::**Module&) (in >> /home/alex/llvm/Release+**Asserts/bin/opt) >> ==5134== by 0x41AE4D2: (below main) (libc-start.c:226) >> ==5134== Address 0x46cfa40 is 0 bytes after a block of size 200 alloc'd >> ==5134== at 0x402C454: operator new[](unsigned int) (in >> /usr/lib/valgrind/vgpreload_**memcheck-x86-linux.so) >> ==5134== by 0x4037AE0: (anonymous >> namespace)::Hello::**runOnModule(llvm::Module&) (in >> /home/alex/llvm/Release+**Asserts/lib/Hello...

...t; /home/alex/llvm/Release+Asserts/bin/opt) > ==5134== by 0x8E37385: llvm::PassManager::run(llvm::Module&) (in > /home/alex/llvm/Release+Asserts/bin/opt) > ==5134== by 0x41AE4D2: (below main) (libc-start.c:226) > ==5134== Address 0x46cfa40 is 0 bytes after a block of size 200 alloc'd > ==5134== at 0x402C454: operator new[](unsigned int) (in > /usr/lib/valgrind/vgpreload_memcheck-x86-linux.so) > ==5134== by 0x4037AE0: (anonymous > namespace)::Hello::runOnModule(llvm::Module&) (in > /home/alex/llvm/Release+Asserts/lib/Hello.so)*/ > ==5134== Addr...

...(i)) { errs()<<"\nget isntr "<<*(is->getMetadata("path")->getOperand(i))<<"\n"; } } } } values.clear();* I receive a memory corruption error at some basic blocks. Here are the debug outputs: 1. opt - *opt: malloc.c:3801: _int_malloc: Assertion `(unsigned long)(size) >= (unsigned long)(nb)' failed.* 2. gdb - *Program received signal SIGABRT, Aborted. 0xb7fdd424 in __kernel_vsyscall ()* 3. valgrind - it executes all the code and at the problematic loop iteration I have : *==5134== Invalid write of s...

...lIteration (main.c:258) ==4711== by 0x4FA7570: R_ReplConsole (main.c:308) ==4711== by 0x4FA760E: run_Rmainloop (main.c:1082) ==4711== by 0x40075A: main (Rmain.c:29) ==4711== Address 0x19b3ab90 is 0 bytes inside a block of size 160,048 free'd ==4711== at 0x4C2ACBD: free (vg_replace_malloc.c:530) ==4711== by 0x4FAFCB2: ReleaseLargeFreeVectors (memory.c:1055) ==4711== by 0x4FAFCB2: RunGenCollect (memory.c:1825) ==4711== by 0x4FAFCB2: R_gc_internal (memory.c:2998) ==4711== by 0x4FB166F: Rf_allocVector3 (memory.c:2682) ==4711== by 0x4FB2310: Rf_allocVector (Rinlinedfuns.h...

...in/opt) > ==5134== by 0x8E37385: llvm::PassManager::run(llvm::__Module&) (in > /home/alex/llvm/Release+__Asserts/bin/opt) > ==5134== by 0x41AE4D2: (below main) (libc-start.c:226) > ==5134== Address 0x46cfa40 is 0 bytes after a block of size 200 alloc'd > ==5134== at 0x402C454: operator new[](unsigned int) (in > /usr/lib/valgrind/vgpreload___memcheck-x86-linux.so) > ==5134== by 0x4037AE0: (anonymous > namespace)::Hello::__runOnModule(llvm::Module&) (in > /home/alex/llvm/Release...

Hi, I've tracked the first problem (mentioned in my previous email, quoted below) down further, ending up in the handling of alloca in LoopRotation.cpp (from trunk): // If the instruction's operands are invariant and it doesn't read or write // memory, then it is safe to hoist. Doing this doesn't change the order of // execution in the preheader, but does prevent the instruction from // e...

2012/2/3 Patrik Hägglund <patrik.h.hagglund at ericsson.com>: > Hi, > > I've tracked the first problem (mentioned in my previous email, quoted > below) down further, ending up in the handling of alloca in > LoopRotation.cpp (from trunk): > >      // If the instruction's operands are invariant and it doesn't read > or write >      // memory, then it is safe to hoist.  Doing this doesn't change the > order of >      // execution in the preheader, but does prevent t...

Hey folks, I am hoping that someone might be able to help me better understand this design decision: For a 64 bit target, index's into GEP's of arrays are zext up to 64 bit integers, even if the variable itself is an alloca of only i32. Similarly, on a 32 bit target, index's into GEP's are trunc'd down to 32 bits even if they ultimately reference an alloc'd variable of type i64. My guess is that in the latter, there is a 2^32 limit on the number of elements in an array for 32 bit systems....

On 2 Dec 2018, at 22.22, Guillaume via dovecot <dovecot at dovecot.org> wrote: > > I also have this kind of segfault since the update : > > Dec 2 21:12:11 xxxxxxx dovecot: auth-worker: Error: *** Error in `dovecot/auth': double free or corruption (fasttop): 0x000055573bb99f70 Is this easy to reproduce? Can you try with valgrind? It will slow down the logins a bit though.

...c 4 12:09:40 dovecot: auth-worker: Error: ==3071== by 0x1187FF: main (main.c:398) Dec 4 12:09:40 dovecot: auth-worker: Error: ==3071== Address 0x66e3870 is 0 bytes inside a block of size 120 free'd Dec 4 12:09:40 dovecot: auth-worker: Error: ==3071== at 0x4C2CDDB: free (vg_replace_malloc.c:530) Dec 4 12:09:40 dovecot: auth-worker: Error: ==3071== by 0x6E877FE: mysql_close (mariadb_lib.c:1947) Dec 4 12:09:40 dovecot: auth-worker: Error: ==3071== by 0x14768B: driver_sqlpool_disconnect (driver-sqlpool.c:590) Dec 4 12:09:40 dovecot: auth-worker: Error: ==3071== by 0x13D0...

...=4711== by 0x4FA7570: R_ReplConsole (main.c:308) > ==4711== by 0x4FA760E: run_Rmainloop (main.c:1082) > ==4711== by 0x40075A: main (Rmain.c:29) > ==4711== Address 0x19b3ab90 is 0 bytes inside a block of size 160,048 > free'd > ==4711== at 0x4C2ACBD: free (vg_replace_malloc.c:530) > ==4711== by 0x4FAFCB2: ReleaseLargeFreeVectors (memory.c:1055) > ==4711== by 0x4FAFCB2: RunGenCollect (memory.c:1825) > ==4711== by 0x4FAFCB2: R_gc_internal (memory.c:2998) > ==4711== by 0x4FB166F: Rf_allocVector3 (memory.c:2682) > ==4711== by 0x4FB2310: Rf_al...

The following code crashes after about 300 iterations on my?x86_64-w64-mingw32?machine on R 3.5.2 --vanilla.?? Others have duplicated this (see?https://github.com/tidyverse/magrittr/issues/190?if necessary), but I don't know how machine/OS-dependent it may be.?? If it doesn't crash for you, please try increasing the length of the x vector. Substituting the commented-out line for the one

Hi, I have two problems regarding the llvm.stackrestore intrinsic. I'm running on 3.0, but a quick test on trunk also showed the same behavior. First problem: --------------- I have code like: tmp1 = call llvm.stacksave() tmp2 = alloca [do some stuff with tmp2] call llvm.stackrestore(tmp1) [some other stuff] tmp3 = call llvm.stacksave() tmp4 = alloca [do some stuff with tmp4] call llvm.stackrestore(tmp3) Then some transformation rewrites this to tmp1 = call llvm.stacksave() tmp2 = alloca [do som...

http://dovecot.org/releases/2.2/dovecot-2.2.15.tar.gz http://dovecot.org/releases/2.2/dovecot-2.2.15.tar.gz.sig Some small fixes and changes to v2.2.14. This release is mainly in the hope that it could still make it into the next Debian stable instead of v2.2.14 - mainly because of a couple of new assert crashes that started happening in v2.2.14 and should be fixed now. * Plugins can now print

http://dovecot.org/releases/2.2/dovecot-2.2.15.tar.gz http://dovecot.org/releases/2.2/dovecot-2.2.15.tar.gz.sig Some small fixes and changes to v2.2.14. This release is mainly in the hope that it could still make it into the next Debian stable instead of v2.2.14 - mainly because of a couple of new assert crashes that started happening in v2.2.14 and should be fixed now. * Plugins can now print

...auth-worker: Error: ==2476== by 0x1187FF: main (in /usr/lib/dovecot/auth) Dec 4 12:00:27 xxxxx dovecot: auth-worker: Error: ==2476== Address 0x66e3870 is 0 bytes inside a block of size 120 free'd Dec 4 12:00:27 xxxxx dovecot: auth-worker: Error: ==2476== at 0x4C2CDDB: free (vg_replace_malloc.c:530) Dec 4 12:00:27 xxxxx dovecot: auth-worker: Error: ==2476== by 0x6E877FE: mysql_close (mariadb_lib.c:1947) Dec 4 12:00:27 xxxxx dovecot: auth-worker: Error: ==2476== by 0x14768B: ??? (in /usr/lib/dovecot/auth) Dec 4 12:00:27 xxxxx dovecot: auth-worker: Error: ==2436== at 0x6E8767F...

Hi, I am sorry if this is perceived as a C++ question rather than an R question. After uploading an R library to CRAN (MCMCglmm) the C++ code failed to pass the memory checks. The errors come in pairs like: Mismatched free() / delete / delete [] at 0x4A077E6: free (vg_replace_malloc.c:446) by 0x144FA28E: MCMCglmm (MCMCglmm.cc:2184) Address 0x129850c0 is 0 bytes inside a block of size 4 alloc'd at 0x4A07CE4: operator new[](unsigned long) (vg_replace_malloc.c:363) by 0x144F12B7: MCMCglmm (MCMCglmm.cc:99) which is associated with lines allocating and freeing memory (nG is...

The dynamically alloc'd string to protect from strtok modification has not been free'd on start_auto_mode() function Signed-off-by: Felipe Pena <felipensp at gmail.com> --- com32/hdt/hdt-cli.c | 1 + 1 file changed, 1 insertion(+) diff --git a/com32/hdt/hdt-cli.c b/com32/hdt/hdt-cli.c index 7542da8.....