similar to: Message parser loops on certain messages (e.g. with a trailing CR character)

Displaying 20 results from an estimated 100 matches similar to: "Message parser loops on certain messages (e.g. with a trailing CR character)"

2013 Nov 06
1
get_disconnect_reason() gets called with NULL ctx->litinput
Hi, I have found get_disconnect_reason() to be called with NULL ctx->litinput at times, making dovecot crash when accessing v_offset: src/imap/cmd-append.c: 83 switch (i_stream_read(client->input)) { 84 case -1: 85 /* disconnected */ 86 reason = get_disconnect_reason(ctx, ctx->litinput->v_offset); 87
2013 Nov 06
1
Missing i_stream_unref in imap_msgpart_crlf_seek()?
Hi, imap_msgpart_crlf_seek() returns an error stream in case of problems in message_skip_virtual(). The original input stream is not being unreferenced, preventing destroy callbacks from being executed. Shouldn't we have an i_stream_unref(&input) here: src/lib-imap-storage/imap-msgpart.c: 398 if (message_skip_virtual(input, virtual_skip, &cr_skipped) < 0) { 399
2009 Jun 02
2
Panic with signal 6 core dump with revision 9116:9ae55b68cf61
Jun 2 10:05:14 hostname dovecot: IMAP(testuser): Panic: file istream- raw-mbox.c: line 380: assertion failed: (new_pos > 0) Jun 2 10:05:14 hostname dovecot: dovecot: child 544822 (imap) killed with signal 6 (dbx) where raise(??) at 0x90000000005a68c abort() at 0x900000000085c2c default_fatal_finish(type = LOG_TYPE_PANIC, status = 0), line 160 in "failures.c"
2008 Aug 29
1
Dovecot-1.1.2 assertion failure in preparsed_parse_next_header_init
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
2007 Oct 21
1
Problem with fts found against Dovecot hg; examples + trace attached
I've been wanting to try out Squat for full-text indexing for a while now, so I finally gave it a whirl. I did a fresh pull from hg. I have it enabled, but it's taking *forever* to do a query. (Using alpine, I issued a Select command for all messages with some word anywhere, which presumably caused the Squat indexer to run.) I think Dovecot is infinite looping. I thought something
2009 Apr 03
2
Implementation of editheaders in dovecot
Hello. I wrote the hook function for deliver. I want to add support of editheaders in the plug-in for dovecot. For this purpose I wrote the function rarules_get_stream. Remover of headrs works properly, but adding does not work. I took Timo Sirainen's advice from http://markmail.org/message/skb6arnll5gaopdr . Do I use a correct way of creation of a message? I give backtrace and a
2023 Mar 12
2
dovecot crash with Panic: file istream-header-filter.c: line 663
Hi - I'm hitting a crash in dovecot, I get this logged followed by a terse stack trace and systemd-coredump details not included here - full gdb stack trace and more details are further down: Mar 12 10:32:26 goffin dovecot[8269]: imap-login: Login: user=<patman>, method=PLAIN, rip=192.168.1.4, lip=192.168.1.1, mpid=8477, TLS, session=<5RvGYLf2RrDAqAEE> Mar 12 10:32:26 goffin
2010 Sep 17
1
fts_squat hanging on some messages
Hello, I recently upgraded to dovecot 2.0.2 (on gentoo ~amd64) and now fts_squat's index building seems to hang for some of my mailboxes. The imap process gets stuck at 100% cpu usage and dovecot.index.search is never touched. I traced the problem to a message (attached) for one of the problematic mailboxes. Also attached are a full backtrace and the output of dovecot -n. The problem
2016 Dec 06
0
Segmentation fault in imap_bodystructure_is_plain_7bit
Hi, I have a lot of errors like this in my log: Fatal: master: service(imap): child 26049 killed with signal 11 (core dumped) Dovecot 2.2.18 build from sources ./configure --prefix=/opt/dovecot2 --with-mysql --with-sqlite --with-solr --with-ssl --disable-rpath --disable-static. Debian Wheezy 3.2.63-2 x86_64. Filesystem is ZFS. All the core files are similar: $ gdb
2017 Jun 08
0
Segmentation fault in imap_bodystructure_is_plain_7bit
Hi, I have a lot of errors like this in my log: Fatal: master: service(imap): child 26049 killed with signal 11 (core dumped) Dovecot 2.2.18 build from sources ./configure --prefix=/opt/dovecot2 --with-mysql --with-sqlite --with-solr --with-ssl --disable-rpath --disable-static. Debian Wheezy 3.2.63-2 x86_64. Filesystem is ZFS. All the core files are similar: $ gdb
2008 Mar 10
2
Consecutive crashes of serveral imapd processes
This is 1.0.13, the processes crashed a few seconds apart from each other: GNU gdb 6.7.1-debian Copyright (C) 2007 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
2020 Sep 21
1
AW: doveadm search segfault Dovecot 2.2.22
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)
2009 Aug 13
4
Crash in v1.2.3: istream.c: assertion failed on line 99
Hi, I have a couple of people bumping into an issue with their imap process crashing - from the users perspective, their mail client (thunderbird) just stops recieving new mail. It still seems to be possible for them to read their mail using squirell mail. When it crashes, it leaves behind a log message like this on the server: Aug 12 15:52:25 fury dovecot: imap-login: Login:
2008 Mar 11
2
dovecot-1.1.rc3 segmentation fault in fetch_bodystructure
Hi, another imap crash with latest dovecot. segmentation fault in fetch_bodystructure src/imap/imap-fetch.c static int fetch_bodystructure(struct imap_fetch_context *ctx, struct mail *mail, void *context ATTR_UNUSED) { const char *bodystructure; if (mail_get_special(mail, MAIL_FETCH_IMAP_BODYSTRUCTURE,
2008 Feb 20
1
(message_parser_parse_next_block): assertion, failed: (ctx->input->eof)
dovecot 1.1b16 Feb 19 23:32:41 hill dovecot: IMAP(username): Disconnected for inactivity bytes=29831/872 Feb 19 23:32:41 hill dovecot: IMAP(username): file message-parser.c: line 764 (message_parser_parse_next_block): assertion failed: (ctx->input->eof) Feb 19 23:32:41 hill dovecot: child 60831 (imap) killed with signal 6 # gdb /usr/local/libexec/dovecot/imap imap.60831.hill.core GNU
2005 Sep 09
1
1.0alpha1: stack frame core
Hi, Today's core dump from 1.0alpha1 came from a syslog message of: IMAP(user): pool_data_stack_realloc(): stack frame changed gdb info on the resulting core dump attached. Question: how many people are building/using dovecot 1.0alpha1 with gcc 4.0.1 versus gcc 3.4.x? I am wondering if these issues come from the compiler instead of dovecot itself? Jeff Earickson Colby College
2006 Jan 31
1
beta2: strange assert
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
2006 Jun 05
3
possible bug in trunk base.rb? BREAK_RE.
Hello All, first post to the list. I just checked out trunk and it broke my tests. Turns out that the BREAK_RE regex found in base.rb is missing the "/m" mode modifier. I am still getting my head around the library so i may be missing something but was that done on purpose? Thanks. jeremy Index: base.rb =================================================================== --- base.rb
2016 May 29
4
fts lucene crashes in 2.2.24
Hi, I've just enabled FTS via Lucene on my Dovecot 2.2.24 installation but I see the indexer crashing ?always?. This simple testcase with a very tiny testing mailbox exposes the issue immediately: doveadm -v index -u anmesse INBOX Program received signal SIGSEGV, Segmentation fault. rescan_clear_unseen_mailbox (rescan_ctx=rescan_ctx at entry=0x0, vname=0x555555839820 "INBOX.Testfolder
2010 Sep 15
1
imap processing spinning on the CPU
Version: 2.0.2 OS: Mac OS X 10.5.8 IMAP Client: Apple Mail.app on 10.5.8 Since upgrading to 2.0.2 I've noticed one user ends up with 4-5 imap processes all using as much CPU as they can get. I know of one other person who is seeing this on a FreeBSD server (that person moved back to dovecot 1.2 which 'solved' the problem there). I didn't notice anything in the list archive