Displaying 20 results from an estimated 900 matches similar to: "make check failing in CentOS 6"
2017 Feb 28
0
make check failing in CentOS 6
On 28.02.2017 06:14, Peter Ajamian wrote:
> Dovecot builds just fine, but fails the tests in src/lib-index.
>
> Note that reverting this commit fixes the issue:
> https://github.com/dovecot/core/commit/dfa4b048ec9a174a42d6668e94501db2fb70793a
>
> $ make check
> for bin in test-mail-index-map test-mail-index-modseq
> test-mail-index-sync-ext
2005 Sep 08
1
1.0alpha1: another imap core, no assert
Timo,
Output of gdb session on the core file attached. This
one only produced the following syslog:
IMAP(user): UIDs broken with partial sync in mbox file /var/mail/r/user
with no assert. Setup: Solaris 9, gcc 4.0.1 for dovecot build.
Jeff Earickson
Colby College
-------------- next part --------------
Script started on Thu Sep 08 10:05:53 2005
%gdb imap core.rtohara
GNU gdb 6.3
Copyright
2006 May 22
1
beta8: cores on corrupted index file
Timo,
I saw a couple of these cores over the weekend. The syslog says:
May 21 19:04:48 emerald dovecot: [ID 107833 mail.error] IMAP(user): Corrupted index cache file /home/students/s/user/.imap/sent-mail-apr-2004/dovecot.index.cache: indexid changed
With a resulting core file from imap at this time. I also discovered
a remaining lock file on the person's imap file:
-rw------- 1 user
2005 Dec 14
0
Assertion Failure in Current CVS Version
Just installed the latest (Dec. 12) CVS version and one user keeps getting
this assertion failure.
Todd
dovecot: Dec 13 15:53:01 Error: 29718 imap(username): mbox sync:
UID inserted in the middle of mailbox /mailhome/new/o/h/username/mbox
(4863 > 3417, seq=780, idx_msgs=1913)
dovecot: Dec 13 15:53:06 Error: 29718 imap(username): file
mail-index-transaction.c: line 129
2005 Jun 08
2
Debugging test72
When attempting to save a message from the INBOX to a folder in a
collection (like, .projects.dovecot), I get behavior like this (in
GDB). Any clue what might be going wrong?
Here's where a SIGABRT happens:
280 return array->buffer->used / array->element_size;
This is the stack trace:
(gdb) where
#0 mail_index_map_get_ext_idx (map=0x1200c0db0, ext_id=0,
2008 Dec 04
1
assertion failed in 1.1.7 file mbox-sync.c: line 1305 (mbox_sync_handle_eof_updates)
Dovecot 1.1.7 is running so smoothly that I gave up checking its log
files daily. :)
I've just had a look, and among the usual
"IMAP(username): FETCH for mailbox Sent UID xx got too little data: xx vs xx"
messages (that means that unfortunately sometimes some messages are
still written truncated) I saw this assertion failure:
file mbox-sync.c: line 1305
2009 Jul 25
0
dovecot-1.2 with managesieve patch: imap crash with backtrace
Log:
Jul 25 10:18:18 postamt dovecot: IMAP(virus-al):
/home/v/i/virus-al/Maildir/dovecot-uidlist: next_uid was lowered (216
-> 2)
Jul 25 10:18:18 postamt dovecot: IMAP(virus-al): Panic: file
index-sync.c: line 25 (index_mailbox_set_recent_uid): assertion
failed: (seq_range_exists(&ibox->recent_flags, uid))
Jul 25 10:18:18 postamt dovecot: IMAP(virus-al): Raw backtrace: imap
[0x80efdb1]
2009 Jun 20
1
imap signal 6 crash with backtrace (1.2rc5)
GNU gdb 6.8-debian
Copyright (C) 2008 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 details.
This GDB was configured as
2005 Jul 18
2
Assertion failure in mail-index-transaction.c
I just noticed one instance of this in the current CVS version:
dovecot: Jul 18 15:25:48 Error: 5962 IMAP(mailuser): mbox sync: Expunged
message reappeared in mailbox /mailhome/new/o/h/mailuser/mbox (UID 2834
< 2872)
dovecot: Jul 18 15:25:48 Error: 5962 IMAP(mailuser): file
mail-index-transaction.c: line 129 (mail_index_buffer_convert_to_uids):
assertion failed: (*seq != 0)
dovecot: Jul
2010 Apr 03
1
dovecot 2 beta4 errors & core dumps
Hi,
While running imaptest with "clients=50 seed=123 msgs=100000000 random
secs=600", I got errors : "Error: user at domain.com[55]: Unexpected BYE:
* BYE IMAP session state is inconsistent, please relogin.".
dovecot.log :
Apr 03 10:23:47 imap(user at domain.com): Panic: file index-
transaction.c: line 145 (index_transaction_rollback): assertion
failed:
2014 Oct 29
2
2.2.15 Panic in mbox_sync_read_next_mail()
It might not be a fault in dovecot, as the user is accessing the folder locally
with alpine while also running imap-sessions. However it would have been nice
with a more graceful action than panic?
The panic is preceeded by
Error: Next message unexpectedly corrupted in mbox file PATH
Panic: file mbox-sync.c: line 152 (mbox_sync_read_next_mail): assertion failed:
2009 Sep 30
3
Some issues in Dovecot 1.2.5 after upgrade from 1.0.15
We upgraded from Dovecot 1.0.15 to 1.2.5 last night, on Solaris 10 using
mboxes, mostly without issues.
However I had to trash the index/cache files (too many folders were
showing corruption issues which is especially bad for Prayer Webmail
".prayer" folders that store preferences; Prayer sees a disconnection as
the folder being missing!).
I've had one imap process panic in mailbox
2017 Feb 20
9
v2.2.28 release candidate released
http://dovecot.org/releases/2.2/rc/dovecot-2.2.28.rc1.tar.gz
http://dovecot.org/releases/2.2/rc/dovecot-2.2.28.rc1.tar.gz.sig
Pretty large release. Please test before the final v2.2.28, which should be out in a few days.
BTW. Our plan is to start making new releases approximately every month from now on.
* director: "doveadm director move" to same host now refreshes user's
2017 Feb 20
9
v2.2.28 release candidate released
http://dovecot.org/releases/2.2/rc/dovecot-2.2.28.rc1.tar.gz
http://dovecot.org/releases/2.2/rc/dovecot-2.2.28.rc1.tar.gz.sig
Pretty large release. Please test before the final v2.2.28, which should be out in a few days.
BTW. Our plan is to start making new releases approximately every month from now on.
* director: "doveadm director move" to same host now refreshes user's
2017 Feb 22
0
v2.2.28 release candidate 2 released
http://dovecot.org/releases/2.2/rc/dovecot-2.2.28.rc2.tar.gz
http://dovecot.org/releases/2.2/rc/dovecot-2.2.28.rc2.tar.gz.sig
I'm assuming that most of the bugs are now found and fixed, so the final 2.2.28 should be out in a day or two.
Changes since rc1:
* Reverted [UNKNOWN-CTE] -> [PARSE] change
+ pop3c: Added pop3c_features=no-pipelining setting to prevent using PIPELINING extension
2017 Feb 22
0
v2.2.28 release candidate 2 released
http://dovecot.org/releases/2.2/rc/dovecot-2.2.28.rc2.tar.gz
http://dovecot.org/releases/2.2/rc/dovecot-2.2.28.rc2.tar.gz.sig
I'm assuming that most of the bugs are now found and fixed, so the final 2.2.28 should be out in a day or two.
Changes since rc1:
* Reverted [UNKNOWN-CTE] -> [PARSE] change
+ pop3c: Added pop3c_features=no-pipelining setting to prevent using PIPELINING extension
2017 Feb 24
2
v2.2.28 released
http://dovecot.org/releases/2.2/dovecot-2.2.28.tar.gz
http://dovecot.org/releases/2.2/dovecot-2.2.28.tar.gz.sig
* director: "doveadm director move" to same host now refreshes user's
timeout. This allows keeping user constantly in the same backend by
just periodically moving the user there.
* When new mailbox is created, use initially INBOX's
dovecot.index.cache
2017 Feb 24
2
v2.2.28 released
http://dovecot.org/releases/2.2/dovecot-2.2.28.tar.gz
http://dovecot.org/releases/2.2/dovecot-2.2.28.tar.gz.sig
* director: "doveadm director move" to same host now refreshes user's
timeout. This allows keeping user constantly in the same backend by
just periodically moving the user there.
* When new mailbox is created, use initially INBOX's
dovecot.index.cache
2008 Oct 15
1
Bug: MODSEQ FETCH return (?)
Hi Timo - hope things are well :) Playing around with the CONDSTORE
(RFC 4551) stuff while testing the IMAP lib I am writing and I think I
have found a bug in Dovecot 1.2.
RFC 4551 [4] identifies the FETCH response to a MODSEQ request as follows:
fetch-mod-resp = "MODSEQ" SP "(" permsg-modsequence ")"
with 'permsg-modsequence' defined as:
2008 May 01
5
Replication protocol design #2
Changes:
- Added goal 8 and rewrote mailbox synchronization plan.
- Added new SELECT command to change active mailbox and removed mailbox
ID from command parameters
Goals
-----
1. If a single (or configurable number of) server dies, no mails must be
lost that have been reported to IMAP/SMTP clients as being successfully
stored.
2. Must be able to automatically recover from a server