similar to: alpha5: (message_body_search_ctx) assert

My setup: Solaris 9, dovecot built with gcc 4.0.2. Mailboxes on remote NFS file mount from another S9 box (mbox format), index files local disk. IMAP usage only. Dovecot build like so: VERSION=1.0.alpha5 CC=gcc CFLAGS="-g -O" CPPFLAGS=-I/opt/openssl/include \ LDFLAGS=-L/opt/openssl/lib \ ./configure --prefix=/opt/dovecot.$VERSION --with-ssl=openssl \ --with-ssldir=/opt/openssl/ssl

Hi, Two cores over the weekend, same assert message in syslog: imap(user): file message-body-search.c: line 393 (message_body_search_ctx): assertion failed: (input->v_offset <= part->physical_pos) Setup: Solaris 9, imap usage only, mbox format, dovecot compiled with gcc 4.0.1. gdb sessions of the two core files attached. Let me know if you need further analysis of the cores.

Hi, I saw a new assert and core dump today in 1.0alpha1. Setup is Solaris 9, dovecot built with gcc 4.0.1, running as imap server for mbox format. The syslog said: IMAP(user): file message-body-search.c: line 393 (message_body_search_ctx): assertion failed: (input->v_offset <= part->physical_pos) A gdb analysis of the core dump is attached. BTW, I save core dumps in case you need

Hi, An assert and core with 1.0alpha3 on Solaris 9, mbox format, imap only, compiled with gcc 4.0.1. The syslog message was: imap(user): file message-body-search.c: line 393 (message_body_search_ctx): assertion failed: (input->v_offset <= part->physical_pos) gdb core dump analysis is attached. Jeff Earickson Colby College -------------- next part -------------- Script started on

Hi, Wow, I haven't had an assert/core in dovecot in a long time. Here goes: Setup: Solaris 10, dovecot built with gcc 4.1.1, imap and imaps only. User's home directory lives on a ZFS filesystem, but I don't think that makes a difference. So does every other user here (>3K). Assert: IMAP(mulepri): file message-body-search.c: line 393 (message_body_search_ctx): assertion failed:

Hello, My imap daemon get SIGABRT with following message. "pool_data_stack_realloc(): stack frame changed" This is caused with cvs head sources.(and or not with my last 2 patches.) This causes while doing search command. This is IMAP command log: --------------------------------------------------------------------------- * PREAUTH [CAPABILITY IMAP4rev1 SORT THREAD=REFERENCES

Hey, i am now a bit deeper into dovecot debugging with gdb and have a full bt now, with debugging infos. Is there a patch that resolve this Problem in dovecot 2.2.22-1ubuntu2.13 for ubuntu 16? Here the bt: (gdb) bt full #0 0x00007ffff73cf3f3 in array_count_i (array=0x555555810d38) at ../../src/lib/array.h:155 No locals. #1 message_part_finish (ctx=ctx at entry=0x555555810ce0)

I've noticed a burst of about 12000 of these mbox-rewrite msgs in the log, spread over about 10 minutes. They are always for the same person (XXX'd out here), and have not occurred before or since. There's no evidence of device problems in the message log. Jan 10 17:46:43 ls1 imap-login: Login: XXX [::ffff:10.2.0.1] Jan 10 17:46:43 ls1 imap(XXX): file mbox-rewrite.c: line 429

Hi, there is a line in TODO: "- sieve-cmu.c crash: i_assert(buf->used - 1 == part->body_size.physical_size); ". Yes, we've really seen this crash. Therefore we upgraded to dovecot-1.2.3 with dovecot-1.2-sieve-0.1.11 in order to use sieve plugin (i.e. not cmu-sieve). We use Solaris 10 on Sun servers, we don't use NFS. However, unfortunately, dovecot with sieve crashes

Found a new segfault in imap. The first log entry always happens on my mailbox, but doesn't seem to affect anything. This is CVS version from Aug. 15. dovecot: Aug 21 17:16:56 Error: 28017 IMAP(todd): Corrupted index cache file /mailhome/new/t/b/todd/.imap/INBOX/dovecot.index.cache: Duplicated field in header: hdr.RESENT-TO dovecot: Aug 21 17:19:44 Error: child 28017 (imap) killed with

Hi, I did a bit of digging into the assertions from mbox-rewrite.c (hdr_parsed_size.physical_size == hdr_size). Every time it happens, hdr_size is 0, while hdr_parsed_size.physical_size is non-zero (presumably the correct value). Does this help track it down? I can't manage to get hold of an mbox that causes this though. Another infrequent assertion that's popped up: file

When I do a search in squirrelmail, it will start giving several results, but then fails. I use squirrelmail via https. maillog reveils: file message-body-search.c: line 391 (message_body_search_ctx): assertion failed: (input->v_offset <= part->physical_pos) Squirrel mail browser interface reveils: ERROR: Connection dropped by IMAP server. Query: SEARCH CHARSET UTF-8 ALL TEXT {4}

Hello, I'm seeing this in my dovecot log file: imap(blair): Dec 16 13:53:06 Panic: file istream.c: line 93 (i_stream_set_read_limit): assertion failed: (stream->v_size == 0 || v_offset <= stream->v_size) I get this consistently when I search for the string "unknown C primitive" across 10 mailboxes using the Windows Netscape 4.80 client. If there's any more

Hello, It's my first mailserver I set up. Thanks to everybody who contributes to dovecot. Dovecot works great for me! One thing I want to get rid off is this traceback error using dovecot with sieve. Somebody can help on this? System: Ubuntu server 8.10 dovecot --version 1.1.4 I filter for keywords in mail body with sieve. Mail is stored at lokal harddrive. I already deleted

I've attached two backtraces, one from a segfault and another from an assertion error in imap. I've seen a couple of the same assertion and this is the only segfault. It looks like they could be related. They both have to do with indexing anyway... The code is from CVS as of May 30. The segfault happened while imap was doing searches for my pine filters. I've also noticed that in

Hi, My setup: Solaris 9, mbox format, mailboxes NFS mounted from another S9 system, imap. I got the following assert yesterday: Jan 30 19:57:15 emerald dovecot: [ID 107833 mail.error] imap(user): file index-mail-headers.c: line 258 (index_mail_parse_header): assertion failed: (part != NULL) Jan 30 19:57:16 emerald dovecot: [ID 107833 mail.error] imap(user): file index-mail-headers.c: line

Panic: IMAP(user): file message-parser.c: line 684 (preparsed_parse_next_header_init): assertion failed: (ctx->part- >physical_pos >= ctx->input->v_offset) Linux 2.6.24-19-386 Maildir on ext3 Looks similar to but different from http://dovecot.org/list/dovecot/2008-June/031523.html . #0 0xb7faf410 in __kernel_vsyscall () #1 0xb7e6f085 in raise () from

Hi everybody We are running in the same issue as Maciej Polewczynski does in http://www.dovecot.org/list/dovecot/2008-September/033645.html Is there already a solution? I dont think so? In the TODO-File for 1.2.2 this issue is still reported: #### [...] - sieve-cmu.c crash: i_assert(buf->used - 1 == part->body_size.physical_size); [...] #### I am not able to reproduce the problem but I

> > Is this behavior cured, or do you continue to see it? > No, the behavior isn't cured. We still continue to see it with various clients. I have posted a couple of truss outputs, but so far no resolution. Sorry for the slow response. I've been "fighting other fires". Jackie > Jackie Hunt wrote: > >> On Mon, 2007-09-03 at 12:37 +0200, Robert

Hi- I was able to get a coredump out of the new pop3 (from 0.99.9-test4) by attempting to simulate the execution environment and simply running the pop3 program. Running the older pop3 from 0.99.8.1 works fine, repeatedly: % /usr/local/libexec/dovecot/pop3 quit +OK Logging out. However running the new one: % /usr/local/libexec/dovecot/pop3.new pop3(user9): Error: Corrupted index file