search for: v_size

Hi, I'm seeing these errors in our logs periodically: file istream.c: line 135 (i_stream_skip): assertion failed: (stream->v_size == 0 || stream->v_offset + count <= stream->v_size) Timeout leak: 0x8069328 Any idea on what may be causing these? System is freebsd, format is mbox. I'm also seeing periodic corruption of mailboxes. It's easily fixed because it's always a few stray lines of text left at...

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 information I can provide, please let me know. Best, Blair -- Blair Zajac <bla...

doveadm search -u dmiller at amfes.com text xyzxyz doveadm(dmiller at amfes.com): Panic: file istream-limit.c: line 79 (i_stream_limit_seek): assertion failed: (v_offset <= lstream->v_size) doveadm(dmiller at amfes.com): Error: Raw backtrace: /usr/local/lib/dovecot/libdovecot.so.0(+0x3ca8a) [0x7fcf3daaca8a] -> /usr/local/lib/dovecot/libdovecot.so.0(default_fatal_handler+0x32) [0x7fcf3daacb72] -> /usr/local/lib/dovecot/libdovecot.so.0(+0x16dea) [0x7fcf3da86dea] -> /usr/lo...

[ This is ancient code. - dan ] fs/fs_context.c 168 { 169 int ret; 170 171 struct fs_parameter param = { 172 .key = key, 173 .type = fs_value_is_flag, 174 .size = v_size, 175 }; 176 177 if (value) { --> 178 param.string = kmemdup_nul(value, v_size, GFP_KERNEL); ^^^^^^^^^^ Sleeping 179 if (!param.string) 180...

I'm getting thease messages in log file: file istream.c: line 135 (i_stream_skip): assertion failed: (stream->v_size == 0 || stream->v_offset + count <= stream->v_size) kernel: pid 23364 (pop3), uid 1042: exited on signal 6 It doesn't happen very often, but I'd like to know what is causing them, any ideas? Should I be worried about it ? System is freebsd, format is mbox and dovecot is 0.99.12.1...

dovecot: Jan 14 12:25:49 Error: IMAP(xxxuser): file istream-limit.c: line 85 (_seek): assertion failed: (v_offset <= lstream->v_size) That error message is generated when squirrelmail 1.4.4-rc1 attempts to access this peculiar message partially quoted below. It doesn't happen (after copying the message to our testing account) accessing it through squirrelmail now. But it did. The server is running test61 configured --wit...

...ling and such...). This broke dovecot since it expected different filesizes while reading contents of files that were previously indexed. Therefore dovecot returned some assert like this: imap(jwk at bug.it): file istream.c: line 163 (i_stream_seek): assertion failed: (v_offset <= stream->v_size) Obviously, the solution was to remove indices and have dovecot recreate them. I suppose it would be more "polite" to have this kind of routines (i_stream_seek etc) handle this case by requesting indices recreation for indices that are no longer "real", instead of just dropp...

Hi there, We're running dovecot 2.06, with mdbox. Following message was in our syslog: Jan 20 09:26:48 servername dovecot: [ID 583609 mail.crit] imap(user): Panic: file istream-limit.c: line 79: assertion failed: (v_offset <= lstream->v_size) The problem could be solved on client side, by just deleting the ImapMail-Folder in Thunderbird. Why? Thunderbird tried to move a message, that obviously wasn't there. Dovecot got killed and the message above was in the syslog. Connection was closed and Thunderbird told me the server is dead...

...mount /var/mail-nfs-indexes - local fs /usr/bin/dsync -f -u user at site.ru mirror mdbox:/var/mail-nfs-1/mail/site.ru/user/mail:INDEX=/var/mail-nfs-indexes/site.ru/user dsync(user at site.ru): Panic: file istream-limit.c: line 79 (i_stream_limit_seek): assertion failed: (v_offset <= lstream->v_size) gdb bt: #0 0xb7fe1424 in ?? () #1 0xb7d66e42 in abort () from /lib/libc.so.6 #2 0xb7ee6f55 in default_fatal_finish (type=<value optimized out>, status=<value optimized out>) at failures.c:187 #3 0xb7ee7057 in default_fatal_handler (ctx=0xbfffef84, format=0xb7f08c78 "file %s:...