Created attachment 487256 [details] system call trace Description of problem: When I connect to my dovecot imap server, the server crashes with a segmentation violation. That is to say, the imap component of dovecot crashes, the rest keeps running. The client (thunderbird in my case) reports "server has disconnected". Version-Release number of selected component (if applicable): dovecot-2.0.11-1.fc14.i686 The previous version (2.0.9-1) didn't have this problem. How reproducible: 100% Steps to Reproduce: 1.connect to server using an imap client. 2. 3. Actual results: can't read email Expected results: can read email Additional info: Attached is an excerpt from an strace showing relevant parts of the trace. I show the start of the process that crashes (so it can be identified) and the system calls leading up to the crash. I think that should be enough to identify more-or-less where it crashes. My configuration differs only slightly from what the RPM delivers. Instead of using the file auth-system.conf.ext, I use a file with the following content: passdb { driver = passwd-file args = username_format=%u /etc/dovecot/users } userdb { driver = passwd args = username_format=%u /etc/dovecot/users }
What do you have in /var/log/maillog? Did abrt catch this crash? Could you get backtrace from it? It's enough to copy-paste generated backtrace, no need to fill complete bugreport. Thanks PS: Dovecot has "dovecot -n" command used to generate list of configuration changes, which is very useful for bug reporting. But if you don't have any other changes except those you've already pasted, the past is enough.
I can quickly answer the /var/log question. There are two relevant lines: Mar 24 09:42:46 merel dovecot: imap-login: Login: user=<sjoerd>, method=PLAIN, r ip=194.171.31.183, lip=192.168.0.2, mpid=20598, TLS Mar 24 09:42:46 merel dovecot: master: Error: service(imap): child 20598 killed with signal 11 (core dumped) I don't have anything from abrt. The system runs as a server. Since it does have a screen, I could try tonight (5+ hours from now). In order to be able to read email, I downgraded to dovecot-2.0.1-1.fc14.i686, and when I run dovecot -n (same configuration as the problematic version) I get (domain names edited): hostname = host.domain mbox_write_locks = fcntl passdb { args = username_format=%u /etc/dovecot/users driver = passwd-file } postmaster_address = postmaster@domain ssl_cert = </etc/pki/dovecot/certs/dovecot.pem ssl_key = </etc/pki/dovecot/private/dovecot.pem userdb { args = username_format=%u /etc/dovecot/users driver = passwd }
It wasn't easy (abrtd didn't help) but here's a stack trace. At one level it's clear: NULL pointer dereference. process 28700 is executing new program: /usr/libexec/dovecot/imap [Thread debugging using libthread_db enabled] Program received signal SIGSEGV, Segmentation fault. settings_find_key_nth (ctx=0x99e4050, key=0x99c4330 "plugin//etc", n=0xbff9bdac, def_r=0xbff9bda8, link_r=0xbff9bda4) at settings-parser.c:696 696 if (parent_def->type != SET_STRLIST) (gdb) p parent_def $1 = (const struct setting_define *) 0x0 (gdb) bt #0 settings_find_key_nth (ctx=0x99e4050, key=0x99c4330 "plugin//etc", n=0xbff9bdac, def_r=0xbff9bda8, link_r=0xbff9bda4) at settings-parser.c:696 #1 0x004f9ce5 in settings_find_key_nth (ctx=0x99e4050, key=0x99c4318 "plugin//etc/dovecot", n=0xbff9be1c, def_r=0xbff9be18, link_r=0xbff9be14) at settings-parser.c:693 #2 0x004f9ce5 in settings_find_key_nth (ctx=0x99e4050, key=0x99c42f8 "plugin//etc/dovecot/users", n=0xbff9beb4, def_r=0xbff9bebc, link_r=0xbff9beb8) at settings-parser.c:693 #3 0x004f94fd in settings_parse_keyvalue (ctx=0x99e4050, key=0x99c42f8 "plugin//etc/dovecot/users", value=0x99c42f2 "yes") at settings-parser.c:760 #4 0x004fa270 in settings_parse_line (ctx=0x99e4050, line=0x99c42d8 "plugin//etc/dovecot/users=yes") at settings-parser.c:862 #5 0x00dededa in set_line (ctx=0x99cd468, input=0xbff9c100, user_r=0xbff9c04c, error_r=0xbff9c0fc) at mail-storage-service.c:134 #6 user_reply_handle (ctx=0x99cd468, input=0xbff9c100, user_r=0xbff9c04c, error_r=0xbff9c0fc) at mail-storage-service.c:227 #7 mail_storage_service_lookup (ctx=0x99cd468, input=0xbff9c100, user_r=0xbff9c04c, error_r=0xbff9c0fc) at mail-storage-service.c:843 #8 0x00deeaae in mail_storage_service_lookup_next (ctx=0x99cd468, input=0xbff9c100, user_r=0xbff9c0ac, mail_user_r=0xbff9c0a8, error_r=0xbff9c0fc) at mail-storage-service.c:968 #9 0x0805f2e7 in client_create_from_input (input=<value optimized out>, ---Type <return> to continue, or q <return> to quit--- login_client=0x99ce810, fd_in=11, fd_out=11, input_buf=0xbff9c0e0, error_r=0xbff9c0fc) at main.c:202 #10 0x0805f5dd in login_client_connected (client=0x99ce810, username=0x99c409b "sjoerd", extra_fields=0x99c4110) at main.c:267 #11 0x0051606f in master_login_auth_finish (client=0x99ce810, auth_args=<value optimized out>) at master-login.c:206 #12 0x005163c2 in master_login_auth_callback (auth_args=0x99c410c, errormsg=0x0, context=0x99ce810) at master-login.c:374 #13 0x00516d3e in master_login_auth_input_user (auth=0x99cdcd8) at master-login-auth.c:239 #14 master_login_auth_input (auth=0x99cdcd8) at master-login-auth.c:359 #15 0x0052cc72 in io_loop_call_io (io=0x99cea10) at ioloop.c:384 #16 0x0052ded3 in io_loop_handler_run (ioloop=0x99cc390) at ioloop-epoll.c:213 #17 0x0052cbf0 in io_loop_run (ioloop=0x99cc390) at ioloop.c:405 #18 0x005181fb in master_service_run (service=0x99cc2e0, callback=0x805f100 <client_connected>) at master-service.c:478 #19 0x0805fb0d in main (argc=1, argv=0xbff9c4c4) at main.c:375
Looking at the code where it crashes and comparing it to the (working) version 2.0.9 (I downloaded 2.0.9 directly from dovecot.org and 2.0.11 from the source rpm), I notice that the whole section inside settings_find_key_nth() for the case that link==NULL is new. I guess it wasn't tested thoroughly enough. :-) I wonder if changing the if statement where it crashes to if (parent_def == NULL || parent_def->type != SET_STRLIST) return FALSE; might work. In 2.0.9 it would have returned FALSE because link==NULL, so with this change it would do a little bit more work but still return FALSE.
Created attachment 487421 [details] fix for reported problem As I hoped, the fix I described in my previous comment (and attached here) works. I built an RPM based on the 2.0.11 source RPM to which I added my patch.
You are right, settings_find_key_nth(...) can return NULL and there is no check for this.
dovecot-2.0.11-3.fc15 has been submitted as an update for Fedora 15. https://admin.fedoraproject.org/updates/dovecot-2.0.11-3.fc15
dovecot-2.0.11-2.fc14 has been submitted as an update for Fedora 14. https://admin.fedoraproject.org/updates/dovecot-2.0.11-2.fc14
This version (the fc14 one) seems to work. Thanks.
Package dovecot-2.0.11-2.fc14: * should fix your issue, * was pushed to the Fedora 14 testing repository, * should be available at your local mirror within two days. Update it with: # su -c 'yum update --enablerepo=updates-testing dovecot-2.0.11-2.fc14' as soon as you are able to. Please go to the following url: https://admin.fedoraproject.org/updates/dovecot-2.0.11-2.fc14 then log in and leave karma (feedback).
dovecot-2.0.11-2.fc14 has been pushed to the Fedora 14 stable repository. If problems still persist, please make note of it in this bug report.
dovecot-2.0.11-3.fc15 has been pushed to the Fedora 15 stable repository. If problems still persist, please make note of it in this bug report.