[Dovecot] Panic in Dovecot 1.1.3: index-mail.c: line 1091: assertion failed: (!mail->data.destroying_stream)
Peter Eriksson
peter at ifm.liu.se
Wed Sep 10 15:58:05 EEST 2008
Timo Sirainen wrote:
> On Tue, 2008-09-09 at 13:23 +0200, Peter Eriksson wrote:
>> Maildir on NFS
>
> This is the first time I've heard this happening with maildir. It's
> always been with mboxes before.
>
>> IMAP process crashes for certain (many, but not all) users when
>> accessing certain folders (in the example below, in crashes when
>> accessing my INBOX, about 1700 mails). I could access other
>> mailboxes without problems. And a simple telnet to the imap port
>> followed by a login works fine.
>
> Any idea what the users were doing when it crashed? Was it just opening
> the mailbox or opening some mail or deleting/copying mails?
I can trigger this issue by the following sequence of IMAP commands:
telnet dovecot imap
...
0 login peter <super-duper-secret-password-goes-here>
1 select inbox
2 fetch 1 body.peek[]
After the fetch command I will get the message sent to me
and then the connection goes away. ("2 OK Fetch completed."
is _not_ printed)
A debugger attached to the imap process after the inital login
has been handled gives the following traceback:
(dbx) where
[1] __lwp_kill(0x0, 0x6, 0x1000e7934, 0x1a1a80, 0x0, 0x0), at
0xffffffff7ebd40a4
[2] raise(0x6, 0x0, 0x1000e8338, 0xffffffffffffffff,
0xffffffff7ecec000, 0x0), at 0xffffffff7eb71110
[3] abort(0x1, 0x1b8, 0x1000e7934, 0x1a1a80, 0x0, 0x0), at
0xffffffff7eb4a68c
=>[4] i_internal_fatal_handler(type = ???, status = ???, fmt = ???, args
= ???) (optimized), at 0x1000e8338 (line ~150) in "failures.c"
[5] i_panic(format = ???, ... = ???, ...) (optimized), at 0x1000e7934
(line ~197) in "failures.c"
[6] index_mail_close(_mail = ???) (optimized), at 0x10008180c (line
~1091) in "index-mail.c"
[7] index_mail_free(_mail = ???) (optimized), at 0x100081d78 (line
~1279) in "index-mail.c"
[8] mail_free(mail = ???) (optimized), at 0x100091214 (line ~18) in
"mail.c"
[9] imap_fetch_deinit(ctx = ???) (optimized), at 0x10002cc14 (line
~392) in "imap-fetch.c"
[10] cmd_fetch(cmd = ???) (optimized), at 0x10001c5e0 (line ~74) in
"cmd-fetch.c"
[11] client_command_input(cmd = ???) (optimized), at 0x100028890 (line
~580) in "client.c"
[12] client_handle_input(client = ???) (optimized), at 0x100028fe0
(line ~670) in "client.c"
[13] client_input(client = ???) (optimized), at 0x1000291cc (line
~725) in "client.c"
[14] io_loop_handler_run(ioloop = ???) (optimized), at 0x1000f2614
(line ~204) in "ioloop-poll.c"
[15] io_loop_run(ioloop = ???) (optimized), at 0x1000f1bb8 (line ~320)
in "ioloop.c"
[16] main(argc = ???, argv = ???, envp = ???) (optimized), at
0x1000391b8 (line ~293) in "main.c"
(dbx) frame 6
Current function is index_mail_close (optimized)
1091 i_assert(!mail->data.destroying_stream);
(dbx) list 1085
1085 }
(dbx) list
1086 if (mail->data.filter_stream != NULL)
1087 i_stream_unref(&mail->data.filter_stream);
1088 if (mail->data.stream != NULL) {
1089 mail->data.destroying_stream = TRUE;
1090 i_stream_unref(&mail->data.stream);
1091 i_assert(!mail->data.destroying_stream);
1092 }
1093 }
1094
1095 static void index_mail_reset(struct index_mail *mail)
> Some kind of a way to reproduce this would be helpful. Or I guess in
> your case even a backtrace, since all the previous ones have been with
> COPY command and mbox.
I've tried a couple of different compilers and optimization settings now
and the results are as follows:
Sun Studio 12:
------------------------
-g -fast -m64 FAILS
-g -O -m64 FAILS
-g -m64 WORKS
-fast -m64 FAILS
-g -O -m32 WORKS
GCC 4.3.0:
------------------------
-g -O -m64 FAILS
-g -m64 WORKS
-g -O -m32 WORKS
Ie: Optimized 64 bit code fails. Other variants works.
Hmm.. Perhaps some 64 vs 32 bits issue somewhere? Pointers passed as
32 bit ints due to missing prototypes somewhere?
I saw the other mail regarding imap problems (subject: imap crashes
with SIGSEGV). The machine I'm running this on is a Sun Fire T1000
that have a CPU with 6 cores and 4 threads per core - ie, it looks
like a 24 CPU multicore machine. Perhaps a related issue?
- Peter
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 185 bytes
Desc: OpenPGP digital signature
Url : http://dovecot.org/pipermail/dovecot/attachments/20080910/7518b3d7/attachment-0001.bin
More information about the dovecot
mailing list