similar to: core dump in mail_cache_header_fields_read()

This is log from dovecot 2.1.17 (I had to downgrade from 2.2.10 because lot of problems) on CentOS 6.5: 2014-01-14T18:36:03+01:00 server/a.b.c.d dovecot: lmtp(5927): Fatal: master: service(lmtp): child 5927 killed with signal 11 (core dumped) # uname -a Linux server 2.6.32-431.1.2.0.1.el6.x86_64 #1 SMP Fri Dec 13 13:06:13 UTC 2013 x86_64 x86_64 x86_64 GNU/Linux (gdb) bt full #0

I'm using release 2.2.12, during a copy operation i get segfault on imap process. I have full bt of the issue: (gdb) bt #0 0x00007fcc521029cd in mail_cache_header_fields_read (cache=0x15c7210) at mail-cache-fields.c:369 #1 0x00007fcc52100664 in mail_cache_open_and_verify (cache=0x15c7210) at mail-cache.c:497 #2 0x00007fcc5210244d in mail_cache_register_get_list (cache=0x15c7210,

We uograded our dovecot from version 2.1.10 -> 2.10.12, but within the first hour of use, dovecot-lda would segfault during delivery. This left a lock file lying around causing the user's mail readers to hang; much hilarity ensues. All further deliveries to the same user will result in a crash. The only thing that fixes this condition is to blow away the user's INBOX cache index.

This is log from dovecot 2.2.10: 2014-01-13T15:34:39+01:00 server/a.b.c.d dovecot: imap(user at domain): Fatal: master: service(imap): child 6290 killed with signal 11 (core dumped) (gdb) bt full #0 0x00007fe78683aba5 in mail_cache_header_fields_read () from /usr/local/dovecot-2.2.10/lib/dovecot/libdovecot-storage.so.0 No symbol table info available. #1 0x00007fe78683890a in

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA512 Hi all, we're experiencing "Out of Memory" Problems caused by Sieve-Filters delivering mail to huge IMAP folders. From the logs, I'm beginning to think the problem is that the sieve/lmtp process loads the "dovecot.index.cache" file apparently twice into memory to do something with it. We've set our memory limit per

Hi, I just took a look into the dovecot 2.1 sources and just saw a possible issue in array.h. This code snippet as an example: #static inline void * #array_get_modifiable_i(struct array *array, unsigned int *count_r) #{ # *count_r = array->buffer->used / array->element_size; # return buffer_get_modifiable_data(array->buffer, NULL); #} array->buffer->used and

Hi folks, with Dovecot 1.1.1, I've had two "crashes" (SIGABRT) recently. Dovecot 1.1.1 has been compiled from source and is running on Fedora 8 Linux 32 Bit (all patches) with custom OpenSSL 0.9.8h. [ output of "dovecot -n" ] # 1.1.1: /usr/local/dovecot/etc/dovecot.conf ssl_cert_file: /usr/local/dovecot/etc/dovecot.crt ssl_key_file: /usr/local/dovecot/etc/dovecot.key

>From the log: Aug 11 09:07:23 postamt dovecot: IMAP(zensy): Panic: file mail-index-transaction-view.c: line 106 (tview_apply_flag_updates): assertion failed: (map->hdr.record_size <= tview->record_size) Aug 11 09:07:23 postamt dovecot: IMAP(zensy): Raw backtrace: imap [0x80f0411] -> imap [0x80f0482] -> imap [0x80efe29] -> imap [0x80c839b] -> imap [0x80cea95] -> imap

Hi, yesterday i tried to setup Dovecot with Solr (3.6.2) + Tika (1.8) for FTS. i used a fresh Debian 8.0 system in the beginning with Dovecot 2.2.13 from the Debian repository. After i got some issues with Tika/Dovecot and i read on the mailinglist that these problems where fixed in 2.2.14+, so i tried 2.2.18. With 2.2.18 i get panics with big (ok... huge) attachments. Most mailboxes (and their

I'm seeing a few warnings emitted when building for x86. They're pretty obvious, but if you want the configure options etc, I can provide those. In Dovecot 2.1.2 (I also see some of these in 2.1.1): 1) src/lib-index/mail-cache-fields.c (comparison between two last_used fields) mail-cache-fields.c: In function 'mail_cache_header_fields_read': mail-cache-fields.c:406: warning:

Hi, dovecot-sieve-1.1.2 + dovecot-1.1.beta13 segfaults with the following sieve filter: --- require ["imapflags"]; if header :contains "subject" ["test"] { addflag "$testflag"; } --- when a message with a subject containing "test" is delivered via dovecot lda. The fault backtrace is: (gdb) run Starting

Hi, I'm testing Dovecot v2.3.9.2. So, I found a problem that a Dovecot process termed with Panic, like below: Feb 10 08:50:09 imap(user1 at example.com)<38440><p9ec0zSeSIQKEAIK>: Panic: file message-snippet.c: line 71 (snippet_add_content): assertion failed: (*count_r <= size) Feb 10 08:50:09 imap(user1 at example.com)<38440><p9ec0zSeSIQKEAIK>: Error: Raw

Hi All, I have my dovecot/imap crashing on my Centos7 server. Below is the stacktrace I got: #0? 0x00007f32d9b84e58 in array_count_i (array=0x55b332a1f8f8) at array.h:155? ? ? ? ? ? ? ? ? ? ? ? ? ?No locals.? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ??#1? array_get_i (count_r=<synthetic pointer>, array=0x55b332a1f8f8) at array.h:209? ? ? ? ? ?

Hi, I get a core dump with 2.0.beta6 (573cb66e9180) when I access virtual folders with the master user. Since ACLs are active I have to set a global ACL in .DEFAULTS to access all folders. Coredump: Core was generated by `dovecot/imap'. Program terminated with signal 11, Segmentation fault. [New process 15910] #0 0x00002afabdfbd6a2 in virtual_config_free (mbox=0x10a34128) at

Hi, I obtain continuosly segmentation fault of processes pop3 and imap, with version 2.2.10. This is the error for the pop3 process (but for imap is is the same): 2014-02-10 11:06:22 pop3(xxxxxxx at yyyyyyyy.zz): Fatal: master: service(pop3): child 23804 killed with signal 11 (core dumped) This is the kernel log: Feb 10 11:06:22 pecpop5 kernel: pop3[23804]: segfault at 7fa42a3f4070 ip

Dovecot 1.1.2 crashes reliably for me now on a Mac OS X machine. Here's some info: --- Telnet session --- $ telnet localhost 143 Trying 127.0.0.1... Connected to localhost. Escape character is '^]'. * OK Dovecot ready. a login user1 password a OK Logged in. b select inbox * FLAGS (\Answered \Flagged \Deleted \Seen \Draft) * OK [PERMANENTFLAGS (\Answered \Flagged \Deleted \Seen

Hi all, I have a Dovecot core that I am trying to track down, in an attempt to replicate so I can log a bug report, and am hoping others might be able to help me as I?m reaching my limit. My working theory is that two user sessions are active at the same time, one of the sessions is ?mid-search? (or perhaps in idle state) on a virtual folder where the number of results is zero (due to a null

Hello, I have a segfault problem, and I can not resolve myself. The details below (stack trace, config....). Maybe important to reproduce, everithing working well until I connect with SoGo ActiveSync (SoGo web, and other IMAP clients are working well). So maybe the SoGo send something magical command if the user client use the ActiveSyn... (the IMAP debug attached too) Thanks, Balazs Toth

Here is the log over a 12 hour period: pid 91923 (pop3), uid 25039: exited on signal 6 pid 98265 (pop3), uid 25039: exited on signal 6 pid 95547 (pop3), uid 25039: exited on signal 6 pid 235 (pop3), uid 25039: exited on signal 6 pid 239 (pop3), uid 25039: exited on signal 6 pid 318 (pop3), uid 25039: exited on signal 6 pid 386 (pop3), uid 25039: exited on signal 6 pid 415 (pop3), uid 25039:

On 24.01.2017 11:31, Tom Sommer wrote: > On 2017-01-24 10:25, Aki Tuomi wrote: >> On 24.01.2017 11:13, Tom Sommer wrote: >>> On 2017-01-18 15:27, mkliewe at gmx.de wrote: >>> >>>> dovecot crashes when I switch the quota tracking from dict to count. >>> >>> I have the same problem, but I use 'dict:file' as quota backend - >>>