similar to: Coredump while searching a folder

The log says: Jan 10 19:41:19 postamt dovecot: imap(heixxxxe): Panic: file squat-trie.c: line 876 (squat_build_word): assertion failed: (i + bytelen <= size) Jan 10 19:41:19 postamt dovecot: imap(heixxxxe): Error: Raw backtrace: /usr/dovecot-2/lib/dovecot/libdovecot.so.0(+0x3b861) [0xb7639861] -> /usr/dovecot-2/lib/dovecot/libdovecot.so.0(+0x3b8cf) [0xb76398cf] ->

It's actually 4 crashes in the same minute: Date: Wed, 02 Feb 2011 04:28:35 +0100 GNU gdb (GDB) 7.0.1-debian Copyright (C) 2009 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"

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

This may be identical to the one I posted previously. >From the log: Jan 12 15:25:55 postamt dovecot: imap(mfxxxch): Panic: file squat-trie.c: line 876 (squat_build_word): assertion failed: (i + bytelen <= size) Jan 12 15:25:55 postamt dovecot: imap(mfxxxch): Error: Raw backtrace: /usr/dovecot-2/lib/dovecot/libdovecot.so.0(+0x3b861) [0xb7721861] ->

I've completed my mailbox rebuild - theoretically I should be free of corruption. I used dsync to export from mdbox to maildir (so should be clean) then used a virtual machine with Dovecot to import back to mdbox in another location. So...theoretically I should be free of all corruption now... Running an fts update - "doveadm search text -u user at domain.com xyzzyx" works on

Core dump upon client login with latest changes, gdb attached: ==> /var/log/dovecot.log <== Jun 8 19:26:05 spectre dovecot: master: Dovecot v2.0.beta5 (2d6cf78982dc) starting up Jun 8 19:26:21 spectre dovecot: imap-login: Login: user=<tlx at leuxner.net>, method=PLAIN, rip=10.10.10.10, lip=1.2.3.4, mpid=9997, TLS Jun 8 19:26:21 spectre dovecot: master: Error: service(imap): child

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

Hi, Having installed postgresql-devel-7.4-0.3 and postgresql-libs-7.4-0.3 I'm having probs. compiling cdr_pgsql, can anyone offer any pointers as to what I might be missing? I'm hoping I've just missed out something like postgresql-wibblewobble-7.4-0.3 or something ... Below is the result of a make in the cdr source dir which may help those of you in the know thanks... Andy

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"

I'm not really being too lucky in the last days. After trying to compile cdr_mysql with no success, I am switching to cdr_odbc. I have installed unixODBC, iODBC and MyODBC correctly, I am even able to make queries with isql. But when trying to "make" in the cdr directory of the latest CVS, that's what I get: # cd /usr/src/asterisk/cdr # make cc -o cdr_odbc.so cdr_odbc.o -lodbc

file message-address.c: line 43 (parse_local_part): assertion failed: (ctx->parser.data != ctx->parser.end) #0 0x001b3402 in __kernel_vsyscall () No symbol table info available. #1 0x0043ed20 in raise () from /lib/libc.so.6 No symbol table info available. #2 0x00440631 in abort () from /lib/libc.so.6 No symbol table info available. #3 0x080f6968 in default_fatal_finish

Backtrace:/usr/local/libexec/dovecot/imap 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

I haven't seen this before 1.1b16, it happened to two users today while they were searching using fts. Feb 18 16:41:36 hill dovecot: IMAP(username): file buffer.c: line 288 (buffer_set_used_size): assertion failed: (used_size <= buf->alloc) Feb 18 16:41:36 hill dovecot: child 53560 (imap) killed with signal 6 I can probably narrow it down to an example mail if needed. GNU gdb 6.1.1

>From the log: Jun 5 16:38:46 postamt dovecot: imap-login: Login: user=<username>, method=PLAIN, rip=141.42.142.67, lip=141.42.4.250 Jun 5 16:38:49 postamt dovecot: IMAP(username): Panic: Trying to sync mailbox Sent with open transactions Jun 5 16:38:49 postamt dovecot: IMAP(username): Raw backtrace: imap [0x80f0381] -> imap [0x80f0402] -> imap [0x80efd89] -> imap [0x80b5084]

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

Hi all, yeah ok don''t laugh at my hardware. I got this.... is it normal to get OOM killers with heavy usage of LVM CoW clones and only 64mb ram assigned to dom0 PIII (also is running apache2/nfs/sshd and 4 idling domU''s) Aug 15 14:40:27 xen5etch kernel: printk: 36 messages suppressed. Aug 15 14:40:30 xen5etch kernel: oom-killer: gfp_mask=0x280d2, order=0 Aug 15 14:40:30

I noticed these happen when one of my users searches his Trash folder which he doesn't empty. He uses thunderbird and it is reproducable. Feb 5 22:47:39 boomhauer dovecot: IMAP(username): file message-header-parser.c: line 350 (message_parse_header_next): assertion failed: +(IS_LWSP(line->value[0])) Feb 5 22:47:41 boomhauer dovecot: child 8022 (imap) killed with signal 6 Feb 5

On Mon, Jun 20, 2016 at 05:02:32PM -0400, m.roth at 5-cent.us wrote: > Fred Smith wrote: > > On Mon, Jun 20, 2016 at 04:13:35PM -0400, m.roth at 5-cent.us wrote: > >> Fred Smith wrote: > >> > On Mon, Jun 20, 2016 at 02:59:29PM -0400, Jon LaBadie wrote: > >> >> On Mon, Jun 20, 2016 at 08:58:54AM -0400, Fred Smith wrote: > >> >> > On

On Mon, Jun 20, 2016 at 04:13:35PM -0400, m.roth at 5-cent.us wrote: > Fred Smith wrote: > > On Mon, Jun 20, 2016 at 02:59:29PM -0400, Jon LaBadie wrote: > >> On Mon, Jun 20, 2016 at 08:58:54AM -0400, Fred Smith wrote: > >> > On Mon, Jun 20, 2016 at 01:34:30PM +0300, ????????? ???????? wrote: > >> > > >Can anyone of you provide further hints on what

Hi Jan, After commit 2ca9fbd739b8a72b16dd790d0fff7b75f5488fb8 AMD IOMMU: allocate IRTE entries instead of using a static mapping, booting dom0 stalls several times. Sometimes this results in RCU stall warnings from the dom0 kernel, hitting the "any" key, on normal or serial console, makes the boot continue for a while but it stalls several times. (It also stalls on shutdown BTW) I have