similar to: patch for 2.0.alpha3 crash

Okay. Got to the next bit pretty quickly.: Breakpoint 4, auth_settings_read (service=0x0, pool=0x4104b020, output_r=0x7fdfffff6d0) at auth-settings.c:522 522 input.module = "auth"; (gdb) n 523 input.service = service; (gdb) n 524 if (master_service_settings_read(master_service, &input, (gdb) s Program received signal SIGTRAP, Trace/breakpoint trap. Cannot remove breakpoints

When I change the option 'i' to the letter 'a' is everything as designed. Why is 'i' at this location the problem? ******************************** diff -Nurb dovecot-2.2.16rc1/src/util/rawlog.c dovecot-2.2.16rc1.build/src/util/rawlog.c --- dovecot-2.2.16rc1/src/util/rawlog.c 2015-03-04 13:49:28.000000000 +0100 +++ dovecot-2.2.16rc1.build/src/util/rawlog.c 2015-03-11

Not sure if I mentioned it but I'm on FreeBSD too. I wonder if any of the patches FreeBSD applies automatically is causing this. I looked through them but couldn't find anything obvious that might cause this --- configure.orig? ? ? 2020-08-12 12:20:51 UTC +++ configure @@ -28901,13 +28901,13 @@ fi ? ?if test $want_stemmer != no; then -? ? { $as_echo "$as_me:${as_lineno-$LINENO}:

On 13 Dec 2018, at 11.18, Arkadiusz Mi?kiewicz <arekm at maven.pl> wrote: > > > Hello. > > The problem with dovecot/config processes never ending and spawning new > one on each reload > (https://www.dovecot.org/list/dovecot/2016-November/106058.html) is > becoming a problem here: > > # ps aux|grep dovecot/config|wc -l > 206 I think you also have 206

Hi! On Thu, 31 May 2018 00:44:58 +0900, A. Schulze wrote: > When running multiple instances of dovecot on the same host (or running multiple docker container), > it is hard to distinguish logs from different processes: the syslog entries are all prefixed with the same identifier "dovecot" > It is hardcoded here: >

Sharing an installed copy of dovecot between several users each running a daemon within their own account (or using the same binaries for a system daemon and a user daemon) is difficult because the compile-time directory PKG_STATEDIR (typically /var/lib/dovecot) is hard-coded as the location of things like the ssl-parameters.dat file and the replicator database. Replace all these uses of

In looking at this further, I?m not seeing how this can be configured as documented and still work. The sieve_pipe_socket_dir setting, as the documentation suggests, appears to be used by the plugin to construct a path to find the ?script? (the socket in this case), and it is always relative to base_dir and must include the contents of sieve_pipe_socket_dir. /* Try socket first */ if (

Hi! Unfortunately we do not have a Sparc64 with any OS at hand. Maybe you could break main r s until it breaks? Aki > On 22 February 2018 at 05:14 Chris Ross <cross+dovecot at distal.com> wrote: > > > Sadly, that doesn?t help either. Over the past day, I?ve built and installed a different branch of the OS (stable/11, instead of release/11.1), to see if a new

I've installed grep PRETTY /etc/os-release PRETTY_NAME="Fedora 32 (Server Edition)" dovecot --version 2.3.10.1 (a3d0e1171) openssl version OpenSSL 1.1.1g FIPS 21 Apr 2020 iiuc, Dovecot has apparently had support for setting TLS 1.3 ciphersuites since v2.3.9, per this commit lib-ssl-iostream: Support TLSv1.3 ciphersuites

Sadly, that doesn?t help either. Over the past day, I?ve built and installed a different branch of the OS (stable/11, instead of release/11.1), to see if a new compiler/libc might change things. Sadly, it does not. In the same situation now, auth fails immediately with signal 11. Running gdb on auth (from build dir, compiled -g -O2) shows something similar. - Chris # gdb

hi, Am Mittwoch, den 27.04.2011, 12:37 +0300 schrieb Timo Sirainen: > Give "bt full" command here and show the output. lot of lines :-) ============================ (gdb) bt full #0 0xfeb559f8 in strcmp () from /lib/libc.so.1 No symbol table info available. #1 0xfee73e7a in settings_find_key_nth (ctx=0x809bec0, key=0x807ab38 "plugin//imap", n=0x80477f0,

Hi, after the upgrade to Dovecot 2.3.11.3, from 2.3.10.1, I see frequently these errors from different users: Aug 18 11:02:35 Panic: indexer-worker(info at domain.com) session=<g71KISOttvS5LNVj:O3ahCyuZO18cYAAAEPCW+w>: file http-client-request.c: line 1232 (http_client_request_send_more): assertion failed: (req->payload_input != NULL) Aug 18 11:02:35 Error: indexer-worker(info at