similar to: A couple of dovecot issues I've noted recently...

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>,

Hi, Am 24.01.2018 um 23:39 schrieb Josef 'Jeff' Sipek: > It looks like the binaries are stripped. There should be a "debug" package > you can install with symbol information. Then, the backtrace should be much > more helpful. I installed the debug package and the backtrace now is: --- snip --- (gdb) bt full #0 0x00007f73f1386495 in raise () from /lib64/libc.so.6 No

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

Any idea what the problem could be? Is there anything more i could do to encircle the problem? Or perhaps is the information i provided uncomplete? Am 25.01.2018 um 16:24 schrieb Thomas Robers: > Hi, > > Am 24.01.2018 um 23:39 schrieb Josef 'Jeff' Sipek: >> It looks like the binaries are stripped.? There should be a "debug" >> package >> you can

After recently adding the -f parameter to the call to the deliver command which is called by Postfix, I found that e-mail with a null return path (MAIL FROM:<>) was causing Dovecot deliver to SEGFAULT. I verified this by making this patch to deliver.c (notice I fixed a typo here, too): *** deliver.c.orig Fri Oct 13 07:32:28 2006 --- deliver.c Fri Oct 27 21:26:08 2006 ***************

Timo, The gdb analysis is attached. It looks like memory got seriously stomped in this core dump. There was no assert or other useful information in the syslog. My setup: Solaris 9, imap and imaps, mbox format, INBOXes NFS mounted, index files on local ufs filesystem, beta8 configured like so: VERSION=1.0.beta8 CC=gcc CFLAGS="-g -O" CPPFLAGS=-I/opt/openssl/include

Here's a new one. It just started with the latest (April 8) CVS version. In index-mail-headers.c, line 622: fields = t_new(struct mail_cache_field, count); count is 0 I'm seeing this with several mailboxes. We're using mbox. Here's the error message and backtrace. dovecot: Apr 09 10:53:18 Error: 3348 IMAP(chairman): Trying to allocate 0 bytes dovecot: Apr 09

Timo, I noticed this core dump from imap the other day from one of our users; there was no assertion. GDB output attached, I have saved the core if you need more information. Jeff Earickson Colby College -------------- next part -------------- Script started on Tue May 02 09:15:48 2006 %gdb imap core.jloo GNU gdb 6.3 Copyright 2004 Free Software Foundation, Inc. GDB is free software, covered

dovecot-2.2.13 running on Solaris-10, app 5000 concurrent connections, and a pretty standard config where passdb is set up with driver = pam. We have had some situations where an auth-worker gets into a loop, the load on the server rises and the auth-master seems blocked untill finally no new imap nor pop session are accepted. A 'doveadm reload' restores normal operations. With debug

Hello, I though this bug should be reported, although there is workaround already made and in use. Dovecot 2.2.10 crashes into out of memory error when there is defined system users (userdb+passdb) and own virtual users (userdb+passdb). Removing either one solves the issue and Dovecot is working as it should. When memory leak (I replaced pw_init and gr_init with the version that is found

Hi all I'm testing dovecot to migrate from a cyrus 2.2 With TB2 if I use "subscribe" dovecot crash but only if I enable a shared namespace. Without explicit namespace or only with private namespace "subscribe" works Is this a problem already fixed in 1.2.10? is it a problem of my configuration? I tried different value for location in shared namespace but without any

While trying to isolate properly and reproduce, I was able to trigger the same bug with the following code: struct dict *dict; char* dict_uri = "proxy::sieve"; char* key = "priv/key"; char* username = "admin at domain.tld"; char* value, error; dict_drivers_register_builtin(); dict_init(dict_uri, DICT_DATA_TYPE_STRING, username,

I'm setting up a new box with Dovecot 1.0 beta1 and vpopmail. Normal operations works like a charm, i.e. vpopmail virtual can log in sucessfully using TLS. However, when trying to test dovecot-lda out of CVS, it is not locating the user: > *** Starting dovecot-imapd service... > dovecot: Info: Dovecot v1.0.beta1 starting up > dovecot: Info: auth(default): master in: USER 1

Hello, I wanted a commandline switch within deliver to select the destination folder within an IMAP account, so I added the -f switch, heres the diff, the implementation is only "proof of concept" hehe, I didnt checked if theres any security riscs in doing this. Could we add something like this to dovecot? diff deliver.c.orig deliver.c 342c342 < const char

On Wed, Jan 24, 2018 at 18:55:47 +0100, Thomas Robers wrote: > Am 23.01.2018 um 20:07 schrieb Josef 'Jeff' Sipek: > > On Tue, Jan 23, 2018 at 14:03:27 -0500, Josef 'Jeff' Sipek wrote: > > > On Tue, Jan 23, 2018 at 18:21:38 +0100, Thomas Robers wrote: ... > > > 1. Do you have any idea what the imap process was doing at the time of the > > >

While configuring my server with dovecot I noticed that the PAM authentication driver does not support the username_format option as does the password file driver. This didn't seem too hard to implement so I through together a patch. As you can see in the attached patch I only modify the username sent to PAM. Despit doing this I run into the domain lost

Log: Feb 14 20:31:56 postamt dovecot: imap(lumo) m0Yg1mLyKABXuzxs: Panic: file imap-fetch.c: line 554 (imap_fetch_more): assertion failed: (ctx->client->output_cmd_lock == NULL || ctx->client->output_cmd_lock == cmd) Feb 14 20:31:56 postamt dovecot: imap(lumo) m0Yg1mLyKABXuzxs: Error: Raw backtrace: /usr/local/dovecot-2.2/lib/dovecot/libdovecot.so.0(+0x68fee) [0xb75ccfee] ->

Hi! Looking at the code, I think the bug is that it just copies pointer to the value, it should, instead, duplicate the value to some memory region. Can you see if this following patch fixes it? Aki > On October 17, 2016 at 4:14 PM Pierre Jaury <pierre at jaury.eu> wrote: > > > Okay, it seems to me that the bug is due to "t_str_tabunescape" using > the unsafe

Oh duh, it used datastack pool. Try again with the attached patch? Please remember to clear the previous one out before trying. Aki > > The trace is missing some symbols, I will debug tomorrow and see where > the call comes from exactly. > > Regards, > > > On 10/17/2016 06:23 PM, Aki Tuomi wrote: > > Hi! > > > > Looking at the code, I think the bug

Hi there, Other auth modules (eg passwd-file) allow a username_format to be specified, but not the PAM module. The use-case, is where I want a static userdb configuration which takes the domain into account but still want to use PAM for authentication, eg: userdb { driver = static args = uid=8 gid=12 home=/mnt/storage/mail/vhosts/%d/%n } passdb { driver = pam args = username_format=%n