I tried posting this to the list last night but it seemed to have been
dropped. The following are my original post plus reply. The dovecot
bug has since been fixed in 0.99.9-test4, evolution was never the
problem, but I think this exposed some kind of kernel bug in
kernel-2.4.20-9. Should I Bugzilla this?
==============
From:
Warren Togami
<warren@xxxxxxxxxx>
To:
dovecot@xxxxxxxxxxxxx, fedora-devel@xxxxxxxxx, shrike-list@xxxxxxxxxx
Subject:
[dovecot] Three
*very* strange
bugs
Date:
15 Apr 2003
02:43:19 -1000
* Go here if you want to test dovecot for RH9:
https://bugzilla.fedora.us/show_bug.cgi?id=160
* If somebody has a different IMAP server than dovecot, could you please
test how Evolution reacts to reading this message?
Bug #1 dovecot and #2 evolution-1.2.3
=====================================
I am using dovecot-0.99.9-test3 on RH9, reading mail with
evolution-1.2.2-5 on RH9. Whenever I attempt to view this one
particular spam message, evolution pops up an error like:
Error while 'Retrieving message 4':
Server unexpectedly disconnected: No such file or directory
Simultaneously this appears in my /var/log/maillog:
Apr 15 01:44:50 server dovecot: child 20328 (imap) killed with signal 11
If I attempt to keep reading mail, it logs in again to dovecot and works
normally until I attempt to read that spam again. Evolution displays
the error popup again though I don't see another signal 11 in maillog.
After this point I am unable to log back into dovecot without restarting
the daemon.
Here's the strange part...
I browsed the same IMAP folder from KMail, and kmail has no problem
reading that spam message. dovecot's [imap] process does not
segmentation fault.
Does this mean an evolution bug when reading this particular spam
exposed a dovecot segmentation fault?
Bug #3 kernel?
==============
This is an unrelated bug and perhaps not the fault of dovecot. When I
attempted to use strace to get some debugging info on the [imap]
process, this happened:
[root@xxxxxx /]# strace -p 20486
trace: ptrace(PTRACE_SYSCALL, ...): Operation not permitted
detach: ptrace(PTRACE_DETACH, ...): Operation not permitted
[root@xxxxxx /]#
This isn't normal right? After doing this, dovecot stops working and I
need to restart the daemon in order to establish new connections. That
[imap] process becomes unkillable, even kill -9 wont work. Unkillable
process usually means kernel bug, right?
warren 20345 1 7 01:46 ? 00:00:34 [imap]
This is kernel-2.4.20-9 in Red Hat Linux 9. Is dovecot exposing a Red
Hat kernel bug when I try to strace that process, or is strace supposed
to fail, the dovecot daemon ceases to function and [imap] process
becomes completely unkillable? =)
Warren Togami
warren@xxxxxxxxxx
From:
Timo
Sirainen
<tss@xxxxxx>
To:
Warren
Togami
<warren@xxxxxxxxxx>
Cc:
dovecot@xxxxxxxxxxxxx, fedora-devel@xxxxxxxxx, shrike-list@xxxxxxxxxx
Subject:
[dovecot]
Re: Three
*very*
strange bugs
Date:
15 Apr 2003
16:10:17
+0300
On Tue, 2003-04-15 at 15:43, Warren Togami wrote:
> Simultaneously this appears in my /var/log/maillog:
> Apr 15 01:44:50 server dovecot: child 20328 (imap) killed with signal
11
>
> If I attempt to keep reading mail, it logs in again to dovecot and
works
> normally until I attempt to read that spam again. Evolution displays
> the error popup again though I don't see another signal 11 in maillog.
> After this point I am unable to log back into dovecot without
restarting
> the daemon.
OK, thanks, fixed. Dovecot crashed with "FETCH nnn BODY[n.MIME]", so
pretty much any multipart mail crashed with Evolution.
> Here's the strange part...
> I browsed the same IMAP folder from KMail, and kmail has no problem
> reading that spam message. dovecot's [imap] process does not
> segmentation fault.
KMail doesn't fetch MIME headers separately. I think it fetches whole
message at once.
> Bug #3 kernel?
> ==============
> This is an unrelated bug and perhaps not the fault of dovecot. When I
> attempted to use strace to get some debugging info on the [imap]
> process, this happened:
>
> [root@xxxxxx /]# strace -p 20486
> trace: ptrace(PTRACE_SYSCALL, ...): Operation not permitted
> detach: ptrace(PTRACE_DETACH, ...): Operation not permitted
> [root@xxxxxx /]#
I have no problem stracing. I don't think Dovecot does anything that
should prevent it. Or, well, it might be because it's thought of as
setuid process, but root should be able to strace it.
--
Warren Togami Fedora Linux Project
warren@xxxxxxxxxx http://www.fedora.us
GPG 0x54A2ACF1 3rd party packaging community for Red Hat Linux
785A 304B 08C1 F291 F54F 9A68 6BDD FE8E 54A2 ACF1
Attachment:
signature.asc
Description: This is a digitally signed message part
