search for: free'd

...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 *** /usr/libexec/dovecot/convert-tool: double free or corruption (fasttop): 0x08ce6cc8 *** The directory in question contains these files: # ls Lists/WINE/ announce bugs cvs devel patches patches.20050130 Will I need to go through the (large) file tree and rename all files with dots in the names? If so, anyone have a script that will do...

...ws more errors, see attached files Rowland -------------- next part -------------- smbpasswd -a ldap03 New SMB password: Retype new SMB password: Added user ldap03. Segmentation fault root at testpdc:/usr/src/samba/samba-master# gdb smbpasswd GNU gdb (Debian 7.7.1+dfsg-5) 7.7.1 Copyright (C) 2014 Free Software Foundation, Inc. License GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/gpl.html> This is free software: you are free to change and redistribute it. There is NO WARRANTY, to the extent permitted by law. Type "show copying" and "show warranty" for det...

...reattach it, the reattached disk gets the same disk name and ids as the hot removed one. This leads to very nasty effects - mostly rendering the newly attached device completely unusable. Trying what happens when I do the same thing with a USB device, I saw that the sd node simply doesn't get free'd when a device gets forcefully removed. Imitate the same behavior for vd devices. This way broken vd devices simply are never free'd and newly attached ones keep working just fine. Signed-off-by: Alexander Graf <agraf at suse.de> --- drivers/block/virtio_blk.c | 7 ++++++- 1 file...

...reattach it, the reattached disk gets the same disk name and ids as the hot removed one. This leads to very nasty effects - mostly rendering the newly attached device completely unusable. Trying what happens when I do the same thing with a USB device, I saw that the sd node simply doesn't get free'd when a device gets forcefully removed. Imitate the same behavior for vd devices. This way broken vd devices simply are never free'd and newly attached ones keep working just fine. Signed-off-by: Alexander Graf <agraf at suse.de> --- drivers/block/virtio_blk.c | 7 ++++++- 1 file...

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:

Hi, I was just updating dovecot to nightly snapshot for Fedora rawhide, but got following issue: fts-backend-solr.c: In function 'fts_box_name_get_root': fts-backend-solr.c:60: error: 'NAMESPACE_FLAG_INBOX' undeclared (first use in this function) fts-backend-solr.c:60: error: (Each undeclared identifier is reported only once and once again on line 750 seems the change

...: Rf_eval (eval.c:691) ==4711== by 0x4FA7181: 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)...

..., Jeremy Allison wrote: > On Tue, Mar 01, 2016 at 10:11:15PM +0000, Rowland penny wrote: >> On 01/03/16 21:35, Garming Sam wrote: >>> Hi Rowland, >>> >>> This new segfault seems unrelated to the previous one. It's probably >>> something like a double free, which typically shouldn't be that hard to >>> fix. If you try running the tool under valgrind, it should provide >>> enough information to fix the issue. >>> >>> >>> Cheers, >>> >>> Garming >>> >> Who or what is '...

On 01/03/16 21:35, Garming Sam wrote: > Hi Rowland, > > This new segfault seems unrelated to the previous one. It's probably > something like a double free, which typically shouldn't be that hard to > fix. If you try running the tool under valgrind, it should provide > enough information to fix the issue. > > > Cheers, > > Garming > Who or what is 'valgrind' ? I know what a 'valvegrinder' is, but I don'...

...=28913== by 0x406867: handle_meta_connection_data (net.c:225) ==28913== by 0x4C0FAC0: event_base_loop (event.c:318) ==28913== by 0x40601F: main_loop (net.c:374) ==28913== by 0x411853: main (tincd.c:329) ==28913== Address 0x9E8DE1BDD5EA3BE6 is not stack'd, malloc'd or (recently) free'd (The "Invalid read of size 8" is the "prev" pointer; this is on Linux/x86_64.) crash 2: ==931== Jump to the invalid address stated on the next line ==931== at 0x771BBEEEFD5804F2: ??? ==931== Address 0x771BBEEEFD5804F2 is not stack'd, malloc'd or (recently) f...

...0CCAC1: do_begin (eval.c:1107) ==11423== by 0x80CB320: Rf_eval (eval.c:431) ==11423== by 0x80CB5E0: Rf_applyClosure (eval.c:614) ==11423== by 0x80CB1B7: Rf_eval (eval.c:455) ==11423== by 0x80CCAC1: do_begin (eval.c:1107) ==11423== Address 0x473D163 is 3 bytes inside a block of size 168 free'd ==11423== at 0x401B2A3: free (vg_replace_malloc.c:233) ==11423== by 0x80ED27C: ReleaseLargeFreeVectors (memory.c:759) ==11423== by 0x80EED30: RunGenCollect (memory.c:1351) ==11423== by 0x80F0635: R_gc_internal (memory.c:2141) ==11423== by 0x80F000C: Rf_allocVector (memory.c:194...

Hi, I used Samba 4.0.5 in Wheezy. Here is that I have done: --------------------------------------------------------------- samba-tool domain provision --realm=CHEZMOI.PRIV --domain=CHEZMOI \ --server-role=dc --dns-backend=SAMBA_INTERNAL --adminpass='+toto123' echo "nameserver 192.168.0.21" > /etc/resolv.conf samba ln -s /usr/local/samba/lib/libnss_winbind.so

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. service auth-worker { executable = /usr/bin/valgrind -q --vgdb=no /usr/lib/dovecot/auth -w } At least one good thing about this crash is that it seems to...

...3) Dec 4 12:09:40 dovecot: auth-worker: Error: ==3071== by 0x1187FF: main_deinit (main.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...

...4711== by 0x4FA7181: 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_allo...

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

...3135-- REDIR: 0x5377850 (libc.so.6:__memcpy_chk) redirected to 0x4a24716 (_vgnU_ifunc_wrapper) --3135-- REDIR: 0x52f4e00 (libc.so.6:__GI_strrchr) redirected to 0x4c2c520 (__GI_strrchr) --3135-- REDIR: 0x52ec890 (libc.so.6:malloc) redirected to 0x4c29b76 (malloc) --3135-- REDIR: 0x52ecc90 (libc.so.6:free) redirected to 0x4c2ac90 (free) --3135-- REDIR: 0x52f18d0 (libc.so.6:__GI_strcmp) redirected to 0x4c2dcc0 (__GI_strcmp) --3135-- REDIR: 0x52f3330 (libc.so.6:__GI_strlen) redirected to 0x4c2cbc0 (__GI_strlen) --3135-- REDIR: 0x52f3530 (libc.so.6:__GI_strncmp) redirected to 0x4c2d3f0 (__GI_strncmp) -...

...r: Error: ==2476== by 0x119C88: auths_deinit (in /usr/lib/dovecot/auth) Dec 4 12:00:27 xxxxx 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:...

...zer list, and discovered quite a few usages of construct-from-temporary (before the build gave up!) that would need to be fixed as well. 2- Implement the r-value ctors to allocate. This is likely going to require an additional member to capture the fact that this was allocated and thus needs to be free'd. I suspect that this violates the purpose of the ArrayRef. 3- Others? Thanks, Erich Keane

Hi all, My program is crashing somewhere in LLVM code. It's one of these C/C++ memory bugs that I don't have much experience with... having programmed too much in high level languages. I'm not sure how to track it down. If someone can tell me what could be getting free'd in the getFoldedCast function, that might help me. Here is the error when I run my program: bamboo(49749) malloc: *** error for object 0x102750a10: incorrect checksum for freed object - object was probably modified after being freed. *** set a breakpoint in malloc_error_break to debug (I...