search for: vg_replace_malloc

...5463== by 0x81110F6: (within /usr/sbin/winbindd) ==25463== by 0x81117D7: get_dc_list (in /usr/sbin/winbindd) ==25463== by 0x81114DF: get_sorted_dc_list (in /usr/sbin/winbindd) ==25463== Address 0x41D28E50 is 0 bytes after a block of size 192 alloc'd ==25463== at 0x4002986F: malloc (vg_replace_malloc.c:160) ==25463== by 0x8110969: (within /usr/sbin/winbindd) ==25463== by 0x81110F6: (within /usr/sbin/winbindd) ==25463== by 0x81117D7: get_dc_list (in /usr/sbin/winbindd) ==25463== ==25463== Invalid write of size 4 ==25463== at 0x8110A12: (within /usr/sbin/winbindd) ==25463== by 0x8...

...=29930==? possible), you can try to increase the size of the ==29930==? main thread stack using the --main-stacksize= flag. ==29930==? The main thread stack size used in this run was 8388608. ==29930== 64 bytes in 1 blocks are possibly lost in loss record 35 of 77 ==29930==??? at 0x4C2B9B5: calloc (vg_replace_malloc.c:711) ==29930==??? by 0x5277AB5: pool_system_malloc (mempool-system.c:75) ==29930==??? by 0x525D2FD: p_malloc (mempool.h:99) ==29930==??? by 0x525D2FD: hash_table_create (hash.c:70) ==29930==??? by 0x51F377C: settings_parser_init_list (settings-parser.c:215) ==29930==??? by 0x51ED102: master_servi...

...(talloc.c:1525) ==28624== by 0x4A64CB2: _talloc_free_internal (talloc.c:1072) ==28624== by 0x4A65C9C: _talloc_free (talloc.c:1647) ==28624== by 0x10C1DD: main (smbpasswd.c:631) ==28624== Address 0x5f20dd0 is 0 bytes inside a block of size 16 free'd ==28624== at 0x482C2D4: realloc (vg_replace_malloc.c:692) ==28624== by 0x48777F7: realloc_array (util.c:754) ==28624== by 0x5731BE1: smbldap_set_mod_internal (smbldap.c:325) ==28624== by 0x5732166: smbldap_set_mod (smbldap.c:392) ==28624== by 0x4AA410F: ldapsam_create_user (pdb_ldap.c:5305) ==28624== by 0x4AC046E: pdb_create_user (pd...

I tried to run convert-tool from dovecot-1.2-0.rc2 on a tree of mbox files with some containing dots in the filenames and got this failure: # /usr/libexec/dovecot/convert-tool ken /home/ken mbox:/home/ken/mail maildir:/home/ken/Maildir Error: Mailbox conversion: Couldn't create mailbox Lists.WINE.patches: Mailbox already exists Error: Internal failure *** glibc detected ***

...you can try to increase the size of the > ==29930==? main thread stack using the --main-stacksize= flag. > ==29930==? The main thread stack size used in this run was 8388608. > ==29930== 64 bytes in 1 blocks are possibly lost in loss record 35 of 77 > ==29930==??? at 0x4C2B9B5: calloc (vg_replace_malloc.c:711) > ==29930==??? by 0x5277AB5: pool_system_malloc (mempool-system.c:75) > ==29930==??? by 0x525D2FD: p_malloc (mempool.h:99) > ==29930==??? by 0x525D2FD: hash_table_create (hash.c:70) > ==29930==??? by 0x51F377C: settings_parser_init_list > (settings-parser.c:215) > ==29930=...

On Fri, Mar 04, 2016 at 10:53:17AM +0100, Volker Lendecke wrote: > On Wed, Mar 02, 2016 at 09:23:34AM +0000, Rowland penny wrote: > > OK, here is the output: > > Can you try the attached (UNTESTED!) patch? > > Thanks, Gna, should have at least compiled it.... New patch :-) Volker -- SerNet GmbH, Bahnhofsallee 1b, 37081 Göttingen phone: +49-551-370000-0, fax:

Hello list, During the 'make check' (pigeonhole) portion of a building (rpmbuild) a dovecot.spec file I'm getting the following error: testsuite(root): Fatal: Couldn't drop privileges: User is missing UID (see mail_uid setting) I'm not sure how to resolve this, and any help would be appreciated to help me finish the creating the rpm -- Eric Broch White Horse Technical

...7181: Rf_ReplIteration (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...

...Y: ==20504==     in use at exit: 41,420,912 bytes in 284,994 blocks ==20504==   total heap usage: 3,131,113 allocs, 2,846,119 frees, 395,499,180 bytes allocated ==20504== ==20504== 16 bytes in 1 blocks are possibly lost in loss record 4 of 205 ==20504==    at 0x4C2596C: operator new(unsigned long) (vg_replace_malloc.c:220) ==20504==    by 0x906E59: std::vector<llvm::Type const*, std::allocator<llvm::Type const*> >::vector(std::vector<llvm::Type const*, std::allocator<llvm::Type const*> > const&) (in /home/gabi/vgen/Debug/vgen) ==20504==    by 0x9070B4: std::_Rb_tree<llvm::Functio...

...in.c:271) Dec 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...

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.

...tes allocated. ==10132== For counts of detected errors, rerun with: -v ==10132== searching for pointers to 3,611 not-freed blocks. ==10132== checked 1,373,864 bytes. ==10132== ==10132== 4 bytes in 1 blocks are still reachable in loss record 1 of 33 ==10132== at 0x401C7F0: operator new(unsigned) (vg_replace_malloc.c:164) ==10132== by 0x86F7D70: getLibSupportInfoOutputFilename() (Timer.cpp:36) ==10132== by 0x86F98A4: __static_initialization_and_destruction_0(int, int) ( Timer.cpp:49) ==10132== by 0x86F9A58: _GLOBAL__I__ZN26_GLOBAL__N_Timer.cppxRlDad10TrackSpaceE (stl_map.h:120) ==10132== by 0x870B...

...c2130d76b314 # Parent 8cd4de118ca4d0124011bff1611ddc2e04bd6566 libxl: free values in XLU_ConfigSetting. Fixes these valgrind reported leaks, found with "valgrind xl create -n ..." ==21170== 8 bytes in 3 blocks are definitely lost in loss record 1 of 3 ==21170== at 0x4022F0A: malloc (vg_replace_malloc.c:236) ==21170== by 0x411B22F: strdup (in /lib/i686/cmov/libc-2.7.so) ==21170== by 0x4030085: xlu__cfgl_strdup (libxlu_cfg.c:290) ==21170== by 0x402F3C4: xlu__cfg_yylex (libxlu_cfg_l.l:37) ==21170== by 0x402DD86: xlu__cfg_yyparse (libxlu_cfg_y.c:1338) ==21170== by 0x40308AE: xlu_cfg_...

...: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_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

http://bugzilla.netfilter.org/show_bug.cgi?id=741 Summary: ULOGD segfaults on init Product: ulogd Version: SVN (please provide timestamp) Platform: i386 OS/Version: other Status: NEW Severity: blocker Priority: P5 Component: ulogd_MYSQL AssignedTo: netfilter-buglog at lists.netfilter.org

...es, 54,494,371 bytes allocated. ==32503== For counts of detected errors, rerun with: -v ==32503== searching for pointers to 7,915 not-freed blocks. ==32503== checked 12,616,568 bytes. ==32503== ==32503== 4 bytes in 1 blocks are possibly lost in loss record 1 of 45 ==32503== at 0x40046EE: malloc (vg_replace_malloc.c:149) ==32503== by 0x4005B9A: realloc (vg_replace_malloc.c:306) ==32503== by 0x80A5F92: parse_expression (regex.c:5202) ==32503== by 0x80A614F: parse_branch (regex.c:4707) ==32503== by 0x80A621A: parse_reg_exp (regex.c:4666) ==32503== by 0x80A6618: Rf_regcomp (regex.c:4635) ==32503=...

...(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: (within /lib/tls/i686/cmov/libc-2.5.so) ==31534== by 0x400...

...xx dovecot: 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...