search for: buffer_writing

I thought I had cleared out the corruption I had before - perhaps I was mistaken. What steps should I take to help locate these issues? Currently using 2.1rc1. I see the following errors in my logs, including out of memory and message size issues (at 15:30): Jan 4 05:17:17 bubba dovecot: indexer-worker(user1 at domain.com): Error: Raw backtrace:

....c b/examples/glib-main-loop.c index 9f98033..826651e 100644 --- a/examples/glib-main-loop.c +++ b/examples/glib-main-loop.c @@ -247,6 +247,7 @@ static const char *dest_args[] = { #define BUFFER_SIZE 65536 enum buffer_state { + BUFFER_UNUSED = 0, BUFFER_READING, BUFFER_READ_COMPLETED, BUFFER_WRITING, @@ -254,13 +255,6 @@ enum buffer_state { struct buffer { uint64_t offset; - /* Note that command cookies are only unique per libnbd handle. - * Since we have two handles but we must look up completed commands - * in the buffer table by cookie we must maintain separate read and - * wri...

I have the following in my log: Mar 21 14:46:59 bubba dovecot: replicator: Panic: data stack: Out of memory when allocating 1073741864 bytes Mar 21 14:46:59 bubba dovecot: replicator: Error: Raw backtrace: /usr/local/lib/dovecot/libdovecot.so.0(+0x97c90) [0x7f4638a7cc90] -> /usr/local/lib/dovecot/libdovecot.so.0(+0x97d6e) [0x7f4638a7cd6e] ->

Where would I find the core file? I'm not finding anything obvious. The replicator path is /usr/local/libexec/dovecot/replicator Daniel On 3/22/2017 12:52 AM, Aki Tuomi wrote: > Can you provide us gdb bt full dump? > > gdb /usr/libexec/dovecot/replicator /path/to/core > > on some systems, it's /usr/lib/dovecot/replicator > > Aki > > On 21.03.2017 23:48,

Previously discussed here: https://www.redhat.com/archives/libguestfs/2019-July/msg00213.html It turns out that deferring callbacks is a PITA. (It would be a bit easier if C has closures.) However by rewriting the example we can avoid the need to use the cookie at all and make it run a bit more efficiently, so let's do that instead. Rich.

I did Dovecot profiling on huge e-mail system, and p_strdup was very high on list. I do minor change: p_strdup: /* for (len = 0; (str)[len] != '\0'; ) len++; len++; */ len = strlen(str) + 1; p_strndup: /* len = 0; while (len < max_chars && ((const char *) str)[len] != '\0') len++; */ len = strnlen(str, max_chars); And after changes strdup drop down on the

Building on Solaris 8 with Sun's compiler, I get the following error. Would you fix this? Using gcc is not really a good option for me. /opt/forte8/SUNWspro/bin/cc -DHAVE_CONFIG_H -I. -I. -I../.. -I/opt/csw/inclu\de -fast -xarch=v8 -I/opt/csw/include -c buffer.c "buffer.c", line 159: void function cannot return value "buffer.c", line 205: void function cannot return

Think I got it: #0 0x00007fddaf597c37 in __GI_raise (sig=sig at entry=6) at ../nptl/sysdeps/unix/sysv/linux/raise.c:56 #1 0x00007fddaf59b028 in __GI_abort () at abort.c:89 #2 0x00007fddaf9c0c86 in default_fatal_finish (type=<optimized out>, status=status at entry=0) at failures.c:201 #3 0x00007fddaf9c0d6e in i_internal_fatal_handler (ctx=0x7fff7197d000, format=<optimized out>,

Sorry for the re-post - just want to make sure you saw this: #0 0x00007fddaf597c37 in __GI_raise (sig=sig at entry=6) at ../nptl/sysdeps/unix/sysv/linux/raise.c:56 #1 0x00007fddaf59b028 in __GI_abort () at abort.c:89 #2 0x00007fddaf9c0c86 in default_fatal_finish (type=<optimized out>, status=status at entry=0) at failures.c:201 #3 0x00007fddaf9c0d6e in i_internal_fatal_handler

..._callback) { .callback = finished_read, .user_data = &buffers[i] }, > + 0) == -1) { > fprintf (stderr, "%s\n", nbd_get_error ()); > exit (EXIT_FAILURE); > } > @@ -428,7 +429,8 @@ write_data (gpointer user_data) > buffer->state = BUFFER_WRITING; > if (nbd_aio_pwrite (gsdest->nbd, buffer->data, > BUFFER_SIZE, buffer->offset, > - finished_write, buffer, 0) == -1) { > + (nbd_completion_callback) { .callback = finished_write, .user_data = buffer }, Worth...

Hi all, as described here: https://www.dovecot.org/pipermail/dovecot/2018-July/112173.html we are experiencing the same error on dovecot version 2.3.2.1 while it never occurs on an old version as 2.2.15 It followings the error logs: On an upgraded dovecot backend: Aug 21 12:03:51 backend20 dovecot: lmtp(test1 at internalinboundcm.eu)<SONkAYfje1veGgAAu8+/vw>: Panic: Buffer write out of

** NOT WORKING ** This patch shows how to integrate libnbd and the glib main loop. Posted mainly as a point of discussion as it doesn't quite work yet. Rich.

So nobody has any idea why this could happen? Let me know if I should provide more Information Thanks Thomas Tsiakalakis Team Applikationsbetrieb GDV Dienstleistungs-GmbH Tel: +49(40)33449-4318 Fax: E-Mail: Thomas.Tsiakalakis at gdv-dl.de<mailto:Thomas.Tsiakalakis at gdv-dl.de> GDV Dienstleistungs-GmbH Glockengie?erwall 1 D-20095 Hamburg www.gdv-dl.de<http://www.gdv-dl.de>

Hello, Dovecot keeps crashing at login time. Things were fine on 2.2.2 Fatal: master: service(imap): child 5014 killed with signal 11 Here is the trace: Core was generated by `imap'. Program terminated with signal 11, Segmentation fault. #0 0x00000000105cdfdf in mailbox_list_get_storage (list=0x7fffffffe310, vname=0x10a04ab0 "INBOX/spam", storage_r=0x7fffffffe308) at

Can you provide us gdb bt full dump? gdb /usr/libexec/dovecot/replicator /path/to/core on some systems, it's /usr/lib/dovecot/replicator Aki On 21.03.2017 23:48, Daniel Miller wrote: > I have the following in my log: > > Mar 21 14:46:59 bubba dovecot: replicator: Panic: data stack: Out of > memory when allocating 1073741864 bytes > Mar 21 14:46:59 bubba dovecot: replicator:

sysctl kernel.core_pattern usually indicates where cores are placed. If it says 'core' you are probably not gonna find it. Aki On 22.03.2017 18:11, Daniel Miller wrote: > Where would I find the core file? I'm not finding anything obvious. > > The replicator path is /usr/local/libexec/dovecot/replicator > > Daniel > > On 3/22/2017 12:52 AM, Aki Tuomi wrote:

DOVECOT -N # 2.2.36 (1f10bfa63): /etc/dovecot/dovecot.conf # Pigeonhole version 0.4.24 (124e06aa) # OS: Linux 2.6.32-431.23.3.el6.x86_64 x86_64 CentOS release 6.9 (Final) '''' plugin { ''' mail_replica = tcp:10.1.1.20:1111 # replication_sync_timeout = 2s replication_sync_timeout = 2 '''' } '''' ?

DOVECOT -N # 2.2.36 (1f10bfa63): /etc/dovecot/dovecot.conf # Pigeonhole version 0.4.24 (124e06aa) # OS: Linux 2.6.32-431.23.3.el6.x86_64 x86_64 CentOS release 6.9 (Final) '''' plugin { ''' mail_replica = tcp:10.1.1.20:1111 # replication_sync_timeout = 2s replication_sync_timeout = 2 '''' } ''''

Hi, I've upgraded to dovecot 1.1beta2 and the latest dovecot-sieve release yesterday and have one single mail that cannot be delivered repeatedly. Log (reformatted): Oct 12 15:19:19 vs02 deliver(bernilrz): pool_data_stack_realloc(): stack frame changed Oct 12 15:19:19 vs02 deliver(bernilrz): Raw backtrace: /usr/local/libexec/dovecot/deliver(i_syslog_panic_handler+0x1e) [0x47117e] ->

Hello everyone, I tried to compile the mbox-snarf-plugin.c (downloaded today, so I assume it's the most recent version available) on AIX 5.3 with gcc 4.0. Building Dovecot 1.0.1 and 1.0.2 works fine. [root at aix root]# export DOVECOT=/root/dovecot-1.0.1 [root at aix root]# gcc -fPIC -shared -Wall -I$DOVECOT -I$DOVECOT/src/lib -I$DOVECOT/src/lib-storage -I$DOVECOT/src/lib-mail -I