[Dovecot] 1.0-test70
- vpopmail authentication fix
- many mmap_disable=yes fixes and a few optimizations
- pop3 hang fix
- mbox fix for "last-uid lost" error (hopefully last one)
- mbox fix for losing dirty flag, causing lost message flags
mmap_disable=yes seems to be finally working pretty well. There should be no more cache file related errors with it enabled.
I'm still seeing "UID inserted in the middle of mailbox" error a couple of times in hour (out of ~320000 logins/h), so mbox code is still not perfect but I'd think it's good enough for normal use :)
Hello Timo Sirainen tss@iki.fi, Saturday, May 14, 2005, 7:49:02 PM, you wrote:
Excuse me if I insist, but what about the detailed logging proposed by Andrey Panin?
I found it very useful and, in some cases, fundamental, both for checking and for reporting purposes.
Ciao, luigi
-- Acting is an art which consists of keeping the audience from coughing.
On Sat, 2005-05-14 at 20:08 +0200, Luigi Rosa wrote:
Hello Timo Sirainen tss@iki.fi, Saturday, May 14, 2005, 7:49:02 PM, you wrote:
Excuse me if I insist, but what about the detailed logging proposed by Andrey Panin?
I'm not sure how useful configurable logging would be, but how about these:
# POP3 logout format string: # %t - number of TOP commands # %T - number of bytes sent to client as a result of TOP command # %r - number of RETR commands # %R - number of bytes sent to client as a result of RETR command # %d - number of deleted messages # %m - number of messages (before deletion) # %s - mailbox size in bytes (before deletion) #pop3_logout_format = top=%t/%T, retr=%r/%R, del=%d/%m, size=%s
# Space-separated list of elements we want to log. The elements which have # a non-empty variable value are joined together to form a comma-separated # string. #login_log_format_elements = user=<%u> method=%m rip=%r lip=%l %c
# Login log format. %$ contains login_log_format_elements string, %s contains # the data we want to log. #login_log_format = %$: %s
Sweeet :) My boss and I love that idea.
Is anything similar possible with IMAP? Dunno if it has ever been done before. Could see how it would be quite difficult.
Regards Andrew
On Sat, 2005-05-14 at 23:30 +0300, Timo Sirainen wrote:
On Sat, 2005-05-14 at 20:08 +0200, Luigi Rosa wrote:
Hello Timo Sirainen tss@iki.fi, Saturday, May 14, 2005, 7:49:02 PM, you wrote:
Excuse me if I insist, but what about the detailed logging proposed by Andrey Panin?
I'm not sure how useful configurable logging would be, but how about these:
# POP3 logout format string: # %t - number of TOP commands # %T - number of bytes sent to client as a result of TOP command # %r - number of RETR commands # %R - number of bytes sent to client as a result of RETR command # %d - number of deleted messages # %m - number of messages (before deletion) # %s - mailbox size in bytes (before deletion) #pop3_logout_format = top=%t/%T, retr=%r/%R, del=%d/%m, size=%s
# Space-separated list of elements we want to log. The elements which have # a non-empty variable value are joined together to form a comma-separated # string. #login_log_format_elements = user=<%u> method=%m rip=%r lip=%l %c
# Login log format. %$ contains login_log_format_elements string, %s contains # the data we want to log. #login_log_format = %$: %s
-- Andrew Hutchings (A-Wing) Linux Guru - Netserve Consultants Ltd. - www.domaincity.co.uk Admin - North Wales Linux User Group - www.nwlug.org.uk BOFH excuse 336: the xy axis in the trackball is coordinated with the summer solstice
Hello Timo Sirainen tss@iki.fi, Saturday, May 14, 2005, 10:30:23 PM, you wrote:
TS> I'm not sure how useful configurable logging would be, but how about TS> these:
It would be great!
The reason I (and others, I suppose) am asking this is that there are servers where, for various reasons, you need to keep track of the traffic for each service.
Ciao, luigi
-- Bankers do it with interest (penalty for early withdrawal).
(05.05.14 kl.20:49) Timo Sirainen skrev följande till dovecot@dovecot.org:
- vpopmail authentication fix
- many mmap_disable=yes fixes and a few optimizations
- pop3 hang fix
pop3 still hangs for me.
Would it be possible to have some code that detected this condition and kickstarted the output (until all the bugs are found) ?
Thanks, Jens
- mbox fix for "last-uid lost" error (hopefully last one)
- mbox fix for losing dirty flag, causing lost message flags
mmap_disable=yes seems to be finally working pretty well. There should be no more cache file related errors with it enabled.
I'm still seeing "UID inserted in the middle of mailbox" error a couple of times in hour (out of ~320000 logins/h), so mbox code is still not perfect but I'd think it's good enough for normal use :)
'This mail automatically becomes portable when carried.' Jens Låås Email: jens.laas@data.slu.se
Department of Computer Services, SLU Phone: +46 18 67 35 15
Vindbrovägen 1
P.O. Box 7079
S-750 07 Uppsala
SWEDENOn 19.5.2005, at 11:48, Jens Laas wrote:
- pop3 hang fix
pop3 still hangs for me.
Looks like my previous "fix" didn't actually do anything. Hmm. I looked at it quite a long time but couldn't really think of anything.. Or would the patch below help? If not I'll send you a patch that adds some debugging lines.. diff -u -r1.48 ostream-file.c --- src/lib/ostream-file.c 26 Apr 2005 11:08:16 -0000 1.48 +++ src/lib/ostream-file.c 23 May 2005 22:37:21 -0000 @@ -220,8 +220,10 @@ if (fstream->corked != set && !stream->ostream.closed) { if (set && fstream->io != NULL) { - io_remove(fstream->io); - fstream->io = NULL; + if (!fstream->flush_pending) { + io_remove(fstream->io); + fstream->io = NULL; + } } else if (!set) { ret = buffer_flush(fstream); if (fstream->io == NULL &&
Would it be possible to have some code that detected this condition and kickstarted the output (until all the bugs are found) ?
I guess that could be done, but I'd rather spend the time finding the problem than writing a horrible hack :)
(05.05.24 kl.01:46) Timo Sirainen skrev följande till Jens Laas:
On 19.5.2005, at 11:48, Jens Laas wrote:
- pop3 hang fix
pop3 still hangs for me.
Looks like my previous "fix" didn't actually do anything. Hmm. I looked at it quite a long time but couldn't really think of anything.. Or would the patch below help? If not I'll send you a patch that adds some debugging lines..
diff -u -r1.48 ostream-file.c --- src/lib/ostream-file.c 26 Apr 2005 11:08:16 -0000 1.48 +++ src/lib/ostream-file.c 23 May 2005 22:37:21 -0000 @@ -220,8 +220,10 @@
if (fstream->corked != set && !stream->ostream.closed) { if (set && fstream->io != NULL) { - io_remove(fstream->io); - fstream->io = NULL; + if (!fstream->flush_pending) { + io_remove(fstream->io); + fstream->io = NULL; + } } else if (!set) { ret = buffer_flush(fstream); if (fstream->io == NULL &&
No luck :( Debug patch please :)
Would it be possible to have some code that detected this condition and kickstarted the output (until all the bugs are found) ?
I guess that could be done, but I'd rather spend the time finding the problem than writing a horrible hack :)
OK. Sometimes horrible hacks can find horrible bugs too.. Jens ----------------------------------------------------------------------- 'This mail automatically becomes portable when carried.' ----------------------------------------------------------------------- Jens Låås Email: jens.laas@data.slu.se Department of Computer Services, SLU Phone: +46 18 67 35 15 Vindbrovägen 1 P.O. Box 7079 S-750 07 Uppsala SWEDEN -----------------------------------------------------------------------
(05.05.24 kl.20:39) Timo Sirainen skrev följande till Jens Laas:
On 24.5.2005, at 14:42, Jens Laas wrote:
No luck :(
Debug patch please :)
Here's one, writes to /tmp/dovecot* files
Debug output attached.
Good luck, Jens
'This mail automatically becomes portable when carried.' Jens Låås Email: jens.laas@data.slu.se
Department of Computer Services, SLU Phone: +46 18 67 35 15
Vindbrovägen 1
P.O. Box 7079
S-750 07 Uppsala
SWEDENOn Wed, 2005-05-25 at 11:03 +0200, Jens Laas wrote:
(05.05.24 kl.20:39) Timo Sirainen skrev följande till Jens Laas:
On 24.5.2005, at 14:42, Jens Laas wrote:
No luck :(
Debug patch please :)
Here's one, writes to /tmp/dovecot* files
Debug output attached.
OK, I was on the right track, but didn't think that calling client_input() in client_output() could break it. This should fix it: Index: src/lib/ostream-file.c =================================================================== RCS file: /var/lib/cvs/dovecot/src/lib/ostream-file.c,v retrieving revision 1.48 diff -u -r1.48 ostream-file.c --- src/lib/ostream-file.c 26 Apr 2005 11:08:16 -0000 1.48 +++ src/lib/ostream-file.c 25 May 2005 11:37:50 -0000 @@ -349,6 +349,12 @@ struct file_ostream *fstream = context; int ret; + /* Set flush_pending = FALSE first before calling the flush callback, + and change it to TRUE only if callback returns 0. That way the + callback can call o_stream_set_flush_pending() again and we don't + forget it even if flush callback returns 1. */ + fstream->flush_pending = FALSE; + o_stream_ref(&fstream->ostream.ostream); if (fstream->ostream.callback != NULL) ret = fstream->ostream.callback(fstream->ostream.context); @@ -360,7 +366,8 @@ io_remove(fstream->io); fstream->io = NULL; } - fstream->flush_pending = ret <= 0; + if (ret == 0) + fstream->flush_pending = TRUE; o_stream_unref(&fstream->ostream.ostream); }
(05.05.25 kl.14:39) Timo Sirainen skrev följande till Jens Laas:
On Wed, 2005-05-25 at 11:03 +0200, Jens Laas wrote:
(05.05.24 kl.20:39) Timo Sirainen skrev följande till Jens Laas:
On 24.5.2005, at 14:42, Jens Laas wrote:
No luck :(
Debug patch please :)
Here's one, writes to /tmp/dovecot* files
Debug output attached.
OK, I was on the right track, but didn't think that calling client_input() in client_output() could break it.
Still no luck. Btw Im getting a bit confused about which patches to apply. I tried: test70 + this patch (below) test70 + previous patch + this patch. I can send more debug output, but id like to use the right combo of patches for it. Thanks Jens
This should fix it:
Index: src/lib/ostream-file.c =================================================================== RCS file: /var/lib/cvs/dovecot/src/lib/ostream-file.c,v retrieving revision 1.48 diff -u -r1.48 ostream-file.c --- src/lib/ostream-file.c 26 Apr 2005 11:08:16 -0000 1.48 +++ src/lib/ostream-file.c 25 May 2005 11:37:50 -0000 @@ -349,6 +349,12 @@ struct file_ostream *fstream = context; int ret;
+ /* Set flush_pending = FALSE first before calling the flush callback, + and change it to TRUE only if callback returns 0. That way the + callback can call o_stream_set_flush_pending() again and we don't + forget it even if flush callback returns 1. */ + fstream->flush_pending = FALSE; + o_stream_ref(&fstream->ostream.ostream); if (fstream->ostream.callback != NULL) ret = fstream->ostream.callback(fstream->ostream.context); @@ -360,7 +366,8 @@ io_remove(fstream->io); fstream->io = NULL; } - fstream->flush_pending = ret <= 0; + if (ret == 0) + fstream->flush_pending = TRUE;
o_stream_unref(&fstream->ostream.ostream); }
----------------------------------------------------------------------- 'This mail automatically becomes portable when carried.' ----------------------------------------------------------------------- Jens Låås Email: jens.laas@data.slu.se Department of Computer Services, SLU Phone: +46 18 67 35 15 Vindbrovägen 1 P.O. Box 7079 S-750 07 Uppsala SWEDEN -----------------------------------------------------------------------
On 27.5.2005, at 09:15, Jens Laas wrote:
OK, I was on the right track, but didn't think that calling client_input() in client_output() could break it.
Still no luck.
Well, one more fix :) This is the only patch you need: diff -u -r1.48 -r1.50 --- ostream-file.c 26 Apr 2005 11:08:16 -0000 1.48 +++ ostream-file.c 28 May 2005 11:31:19 -0000 1.50 @@ -349,18 +349,27 @@ struct file_ostream *fstream = context; int ret; + /* Set flush_pending = FALSE first before calling the flush callback, + and change it to TRUE only if callback returns 0. That way the + callback can call o_stream_set_flush_pending() again and we don't + forget it even if flush callback returns 1. */ + fstream->flush_pending = FALSE; + o_stream_ref(&fstream->ostream.ostream); if (fstream->ostream.callback != NULL) ret = fstream->ostream.callback(fstream->ostream.context); else ret = _flush(&fstream->ostream); - if (ret > 0 && IS_STREAM_EMPTY(fstream) && fstream->io != NULL) { + if (ret == 0) + fstream->flush_pending = TRUE; + + if (!fstream->flush_pending && + IS_STREAM_EMPTY(fstream) && fstream->io != NULL) { /* all sent */ io_remove(fstream->io); fstream->io = NULL; } - fstream->flush_pending = ret <= 0; o_stream_unref(&fstream->ostream.ostream); }
Hello Timo,
Saturday, May 14, 2005, 8:49:02 PM, you [TS] wrote:
TS> mmap_disable=yes seems to be finally working pretty well. There should TS> be no more cache file related errors with it enabled.
I started to receive these corrupted transaction log file assertion failures, again:
dovecot: May 18 16:48:07 Error: IMAP(tero@ripattila.com): Corrupted transaction log file /var/spool/postfix/virtual/ripattila.com/tero/.Mailing Lists.Mulberry.Discussion/dovecot.index.log: Append with UID 5001, but next_uid = 5002 dovecot: May 18 16:48:07 Error: IMAP(tero@ripattila.com): Corrupted transaction log file /var/spool/postfix/virtual/ripattila.com/tero/.Mailing Lists.Mulberry.Discussion/dovecot.index.log: Append with UID 5001, but next_uid = 5002 dovecot: May 18 16:48:07 Error: IMAP(tero@ripattila.com): utime(/var/spool/postfix/virtual/ripattila.com/tero/.Mailing Lists.Mulberry.Discussion/dovecot-uidlist.lock) failed: No such file or directory dovecot: May 18 16:48:07 Warning: IMAP(tero@ripattila.com): Our dotlock file /var/spool/postfix/virtual/ripattila.com/tero/.Mailing Lists.Mulberry.Discussion/dovecot-uidlist.lock was deleted dovecot: May 18 16:48:07 Error: IMAP(tero@ripattila.com): Corrupted transaction log file /var/spool/postfix/virtual/ripattila.com/tero/.Mailing Lists.Mulberry.Discussion/dovecot.index.log: Append with UID 5001, but next_uid = 5002 dovecot: May 18 16:48:07 Error: IMAP(tero@ripattila.com): Corrupted transaction log file /var/spool/postfix/virtual/ripattila.com/tero/.Mailing Lists.Mulberry.Discussion/dovecot.index.log: Append with UID 5001, but next_uid = 5002 dovecot: May 18 16:48:07 Error: IMAP(tero@ripattila.com): Corrupted transaction log file /var/spool/postfix/virtual/ripattila.com/tero/.Mailing Lists.Mulberry.Discussion/dovecot.index.log: Append with UID 5001, but next_uid = 5002 dovecot: May 18 16:48:07 Error: IMAP(tero@ripattila.com): Lost transaction log file /var/spool/postfix/virtual/ripattila.com/tero/.Mailing Lists.Mulberry.Discussion/dovecot.index.log seq 3
I've had two or three similar situations within last two-three days or so. I'm running an OpenBSD 3.6-based snapshot that's practically almost a 3.7-stable one.
Thanks, Tero
-- Tero Ripattila
On 20.5.2005, at 21:38, Tero Ripattila wrote:
..
dovecot: May 18 16:48:07 Error: IMAP(tero@ripattila.com): utime(/var/spool/postfix/virtual/ripattila.com/tero/.Mailing Lists.Mulberry.Discussion/dovecot-uidlist.lock) failed: No such file or directory dovecot: May 18 16:48:07 Warning: IMAP(tero@ripattila.com): Our dotlock file /var/spool/postfix/virtual/ripattila.com/tero/.Mailing Lists.Mulberry.Discussion/dovecot-uidlist.lock was deleted
Looks like something to do with locking.. Hmm.
Have you started using Dovecot's LDA?
Hello Timo,
On Tue, May 24, 2005 02:00, Timo Sirainen said:
Looks like something to do with locking.. Hmm. Have you started using Dovecot's LDA?
Not that I know as Postfix takes care of mail delivery in my system.
Thanks, Tero
-- Tero Ripattila
Hi Timo,
Saturday, May 14, 2005, 8:49:02 PM, you [TS] wrote:
TS> mmap_disable=yes seems to be finally working pretty well. There should TS> be no more cache file related errors with it enabled.
Now I get duplicate field in header -error messages, please see the following:
dovecot: May 22 15:11:43 Error: IMAP(tero@ripattila.com): Corrupted index cache file /var/spool/postfix/virtual/ripattila.com/tero/dovecot.index.cache: Duplicated field in header: hdr.SUBJECT dovecot: May 22 15:11:43 Error: IMAP(tero@ripattila.com): Corrupted index cache file /var/spool/postfix/virtual/ripattila.com/tero/dovecot.index.cache: invalid field header size dovecot: May 22 15:11:43 Error: IMAP(tero@ripattila.com): Corrupted index cache file /var/spool/postfix/virtual/ripattila.com/tero/dovecot.index.cache: used_file_size too small dovecot: May 22 15:11:46 Error: IMAP(tero@ripattila.com): Corrupted index cache file /var/spool/postfix/virtual/ripattila.com/tero/dovecot.index.cache: Duplicated field in header: hdr.SUBJECT dovecot: May 22 15:11:46 Error: IMAP(tero@ripattila.com): Corrupted index cache file /var/spool/postfix/virtual/ripattila.com/tero/dovecot.index.cache: Duplicated field in header: hdr.SUBJECT dovecot: May 22 15:12:09 Error: IMAP(tero@ripattila.com): Corrupted index cache file /var/spool/postfix/virtual/ripattila.com/tero/dovecot.index.cache: Duplicated field in header: hdr.SUBJECT
In general, this -test70 is far more unstable than any of the ten test builds I've been running before.
Thanks, Tero
-- Tero Ripattila
Hello Timo,
Saturday, May 14, 2005, 8:49:02 PM, you [TS] wrote:
TS> mmap_disable=yes seems to be finally working pretty well. There should TS> be no more cache file related errors with it enabled.
In addition to these two problems I've told about on the list, there's yet another issue that bugs me. I've got a couple of IMAP folders that holds something like 20k messages each of them. When I try to move messages from one to another, both of my e-mail stable e-mail clients, Mulberry and The Bat!, gets stucked and I have to use task manager to kill 'em. When this happens, there's nothing in dovecot.log.
And when I check the source and destination folders of this movement operation, there's zero messages copied to destination folder and zero expunged from the source folder.
What kind of log would be useful to track this problem down? I can try to get some trace with Mulberry now. backtrace would be nice, but the imap process never dies.
Thanks, Tero
-- Tero Ripattila
Hei Timo,
Saturday, May 14, 2005, 8:49:02 PM, you [TS] wrote:
TS> mmap_disable=yes seems to be finally working pretty well. There should TS> be no more cache file related errors with it enabled.
Dovecot started to do core dumps when I try to open some particular IMAP folders, please see the following:
$ ls -l imap.core -rw------- 1 5303 wheel 20448104 May 22 18:56 imap.core
$ gdb /usr/local/libexec/dovecot/imap /tmp/imap.core GNU gdb 6.3 Copyright 2004 Free Software Foundation, Inc. GDB is free software, covered by the GNU General Public License, and you are welcome to change it and/or distribute copies of it under certain conditions. Type "show copying" to see the conditions. There is absolutely no warranty for GDB. Type "show warranty" for details. This GDB was configured as "i386-unknown-openbsd3.6"... Core was generated by `imap'. Program terminated with signal 11, Segmentation fault. Reading symbols from /usr/lib/libc.so.34.2...done. Loaded symbols for /usr/lib/libc.so.34.2 Reading symbols from /usr/libexec/ld.so...done. Loaded symbols for /usr/libexec/ld.so #0 0x1c0518e9 in pool_alloconly_clear (pool=0x3c02fe10) at mempool-alloconly.c:281 281 free(block); (gdb) bt full #0 0x1c0518e9 in pool_alloconly_clear (pool=0x3c02fe10) at mempool-alloconly.c:281 avail_size = 1006829072 #1 0x1c051678 in pool_alloconly_destroy (apool=0x3c02fe10) at mempool-alloconly.c:109 block = (void *) 0x0 #2 0x1c02b794 in index_header_lookup_deinit (_ctx=0x0) at index-mail-headers.c:681 No locals. #3 0x1c04106f in mailbox_header_lookup_deinit (ctx=0x0) at mail-storage.c:381 No locals. #4 0x1c029ee4 in index_mail_get_special (_mail=0x3c02fa40, field=0) at index-mail.c:617 data = (struct index_mail_data *) 0x3c02faa4 cache_fields = (struct mail_cache_field *) 0x3c01f500 str = (string_t *) 0x5f ext_data = (const void *) 0x5f #5 0x1c01c526 in maildir_mail_get_special (_mail=0x9, field=0) at maildir-mail.c:167 mbox = (struct maildir_mailbox *) 0x1 flags = 1006828096 fname = 0x3c023088 "" #6 0x1c040534 in mail_get_special (mail=0x0, field=MAIL_FETCH_IMAP_ENVELOPE) at mail.c:113 No locals. #7 0x1c01199c in fetch_envelope (ctx=0x3c023088, mail=0x3c02fa40, context=0x0) at imap-fetch.c:411 envelope = 0x3c023088 "" #8 0x1c011572 in imap_fetch (ctx=0x3c023088) at imap-fetch.c:264 handlers = (const struct imap_fetch_context_handler *) 0x3c0231a8 size = 6 ret = 1 #9 0x1c00d708 in cmd_fetch (cmd=0x3c020040) at cmd-fetch.c:165 client = (struct client *) 0x3c020000 ctx = (struct imap_fetch_context *) 0x3c023088 args = (struct imap_arg *) 0x3c021048 search_arg = (struct mail_search_arg *) 0x3c023050 messageset = 0x9 "" ret = 0 #10 0x1c00fa7d in cmd_uid (cmd=0x3c020040) at cmd-uid.c:19 cmd_name = 0x3c0210f8 "FETCH" #11 0x1c01023b in client_handle_input (cmd=0x3c020040) at client.c:334 client = (struct client *) 0x3c020000 #12 0x1c010369 in _client_input (context=0x3c020000) at client.c:383 client = (struct client *) 0x3c020000 cmd = (struct client_command_context *) 0x3c020040 #13 0x1c050a68 in io_loop_handler_run (ioloop=0x3c01d000) at ioloop-poll.c:184 data = (struct ioloop_handler_data *) 0x3c0110a0 pollfd = (struct pollfd *) 0x3c01e000 tv = {tv_sec = 0, tv_usec = 572544} io = (struct io *) 0x3c0353c0 t_id = 2 msecs = 0 ret = 0 call = 1 #14 0x1c050505 in io_loop_run (ioloop=0x3c01d000) at ioloop.c:218 No locals. #15 0x1c016d37 in main (argc=3, argv=0xcfbefd3c, envp=0xcfbefd4c) at main.c:228 No locals. (gdb)
I'm currently trying to find out what's so special with these folders that cannot be opened normally, but havent find anything in common between them. They all contain something like 20-40k messages.
I have to seriously consider reverting back to -test69 now :-(
Thanks, Tero
-- Tero Ripattila
Hello Timo, I can reproduce this issue even with mmap_disable and mmap_no_write set to yes, please see the following back trace:
$ gdb /usr/local/libexec/dovecot/imap /tmp/imap.core GNU gdb 6.3 Copyright 2004 Free Software Foundation, Inc. GDB is free software, covered by the GNU General Public License, and you are welcome to change it and/or distribute copies of it under certain conditions. Type "show copying" to see the conditions. There is absolutely no warranty for GDB. Type "show warranty" for details. This GDB was configured as "i386-unknown-openbsd3.6"... Core was generated by `imap'. Program terminated with signal 11, Segmentation fault. Reading symbols from /usr/lib/libc.so.34.2...done. Loaded symbols for /usr/lib/libc.so.34.2 Reading symbols from /usr/libexec/ld.so...done. Loaded symbols for /usr/libexec/ld.so #0 0x1c03d7f2 in mail_transaction_log_view_set (view=0x3c020500, min_file_seq=8, min_file_offset=7148, max_file_seq=8, max_file_offset=7148, type_mask=8) at mail-transaction-log-view.c:102 102 if (min_file_seq == view->log->tail->hdr.prev_file_seq && (gdb) #0 0x1c03d7f2 in mail_transaction_log_view_set (view=0x3c020500, min_file_seq=8, min_file_offset=7148, max_file_seq=8, max_file_offset=7148, type_mask=8) at mail-transaction-log-view.c:102 file = (struct mail_transaction_log_file *) 0x2b1dbec8 first = (struct mail_transaction_log_file *) 0xb21b372 seq = 0 end_offset = 4324021345303134216 ret = 3932679 #1 0x1c03a17a in view_sync_get_expunges (view=0x3c01f700, expunges_r=0xcfbf97d0) at mail-index-view-sync.c:105 hdr = (const struct mail_transaction_header *) 0xe4e1c00 src = (struct mail_transaction_expunge *) 0xff src_end = (struct mail_transaction_expunge *) 0x3c011020 dest = (struct mail_transaction_expunge *) 0x0 data = (const void *) 0x23ee00 count = 1117130127 ret = 8 #2 0x1c03a366 in mail_index_view_sync_begin (view=0x3c01f700, sync_mask=255, ctx_r=0x8) at mail-index-view-sync.c:176 hdr = (const struct mail_index_header *) 0x3c01f804 ctx = (struct mail_index_view_sync_ctx *) 0x1c039b4d map = (struct mail_index_map *) 0xff mask = 8 want_mask = 0 expunges = {buffer = 0x0, element_size = 0} #3 0x1c02d6cd in index_mailbox_sync_init (box=0x3c01e840, flags=0, failed=0) at index-sync.c:150 ctx = (struct index_mailbox_sync_context *) 0x3c011020 sync_mask = 1006764673 #4 0x1c019b25 in maildir_storage_sync_init (box=0x3c01e840, flags=MAILBOX_SYNC_FLAG_FAST) at maildir-sync.c:991 ctx = (struct maildir_sync_context *) 0x3c0139b0 ret = 0 #5 0x1c040fc4 in mailbox_sync_init (box=0x8, flags=MAILBOX_SYNC_FLAG_FAST) at mail-storage.c:333 No locals. #6 0x1c015150 in imap_sync_init (client=0x3c020000, box=0x3c01e840, flags=MAILBOX_SYNC_FLAG_FAST) at imap-sync.c:43 ctx = (struct imap_sync_context *) 0x3c01d1c0 #7 0x1c01554f in cmd_sync (cmd=0x3c020040, flags=MAILBOX_SYNC_FLAG_FAST, tagline=0x3c00056f "OK Search completed.") at imap-sync.c:210 ctx = (struct cmd_sync_context *) 0x3c0230a0 #8 0x1c00eb66 in cmd_search (cmd=0x3c020040) at cmd-search.c:102 client = (struct client *) 0x3c020000 sargs = (struct mail_search_arg *) 0x8 args = (struct imap_arg *) 0x3c021048 args_count = 8 error = 0x0 charset = 0x0 #9 0x1c00fa7d in cmd_uid (cmd=0x3c020040) at cmd-uid.c:19 cmd_name = 0x3c0210f8 "SEARCH" #10 0x1c01023b in client_handle_input (cmd=0x3c020040) at client.c:334 client = (struct client *) 0x3c020000 #11 0x1c010369 in _client_input (context=0x3c020000) at client.c:383 client = (struct client *) 0x3c020000 cmd = (struct client_command_context *) 0x3c020040 #12 0x1c050a68 in io_loop_handler_run (ioloop=0x3c01d000) at ioloop-poll.c:184 data = (struct ioloop_handler_data *) 0x3c0110a0 pollfd = (struct pollfd *) 0x3c01e000 tv = {tv_sec = 7, tv_usec = 9219} io = (struct io *) 0x3c0111c0 t_id = 2 msecs = 8 ret = 0 call = 1 #13 0x1c050505 in io_loop_run (ioloop=0x3c01d000) at ioloop.c:218 No locals. #14 0x1c016d37 in main (argc=3, argv=0xcfbf9a3c, envp=0xcfbf9a4c) at main.c:228 No locals. (gdb)
Any suggestions how to fix these ongoing problems?
Thanks, Tero
-- Tero Ripattila
On 26.5.2005, at 21:25, Tero Ripattila wrote:
Hello Timo, I can reproduce this issue even with mmap_disable and mmap_no_write set to yes, please see the following back trace:
Can you do it always by giving some command, or does it just happen often? (how often?)
#0 0x1c03d7f2 in mail_transaction_log_view_set (view=0x3c020500, min_file_seq=8, min_file_offset=7148, max_file_seq=8, max_file_offset=7148, type_mask=8) at mail-transaction-log-view.c:102 102 if (min_file_seq == view->log->tail->hdr.prev_file_seq && (gdb)
Could you do here:
p *view.log p *view.log.tail
participants (5)
-
Andrew Hutchings
-
Jens Laas
-
Luigi Rosa
-
Tero Ripattila
-
Timo Sirainen