Note: This is a beta release of Red Hat Bugzilla 5.0. The data contained within is a snapshot of the live data so any changes you make will not be reflected in the production Bugzilla. Also email is disabled so feel free to test any aspect of the site that you want. File any problems you find or give feedback here.
Bug 160482 - segfault while using imap-folders
Summary: segfault while using imap-folders
Alias: None
Product: Fedora
Classification: Fedora
Component: cyrus-sasl
Version: 4
Hardware: All
OS: Linux
Target Milestone: ---
Assignee: Steve Conklin
QA Contact: Brian Brock
Depends On:
TreeView+ depends on / blocked
Reported: 2005-06-15 13:19 UTC by Need Real Name
Modified: 2007-11-30 22:11 UTC (History)
5 users (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Clone Of:
Last Closed: 2007-11-01 16:58:56 UTC

Attachments (Terms of Use)
mutt failure strace output (deleted)
2005-06-17 13:31 UTC, Ed Marshall
no flags Details

Description Need Real Name 2005-06-15 13:19:55 UTC
Description of problem:
Mutt segfaults when trying to access imap-folder.

Version-Release number of selected component (if applicable):
Name        : mutt                         Relocations: (not relocatable)
Version     :                           Vendor: Red Hat, Inc.
Release     : 2                             Build Date: Mon Mar  7 23:44:48 2005

How reproducible:

Steps to Reproduce:
1. mutt -f imap://localhost
2. "Username at localhost: something" [enter] -> Segmentation fault

Actual results:
Segmentation fault

Expected results:
contents of imap folder

Additional info:

If using mutt -f imaps://localhost/ it works, but with imap:// it doesn't.

Comment 1 Albert Strasheim 2005-06-16 00:06:09 UTC
Probably a duplicate of bug 157521.

Comment 2 Need Real Name 2005-06-16 20:34:13 UTC
If cyrus-sasl-plain package is installed, imaps://localhost works. But if it
isn't, then both imaps and imap segfaults.

Problem maybe in sasl libraries?

Comment 3 Bill Nottingham 2005-06-16 20:54:29 UTC
I can't reproduce this, even with cyrus-sasl-plain uninstalled.

Comment 4 Ville Herva 2005-06-16 21:02:00 UTC
Bill, are you testing this on a vanilla FC4 installation? I've two fresh FC4 
installs, both of which show the problem (but not on every mutt invokation, 
perhaps 50% of the time it segfaults.) However, a Fedora Rawhide installation 
(same mutt version, same mutt version, same cyrus-sasl 2.1.20-5). All 
x86 UP. The rawhide box runs 2.6.12-rc4, the FC4's have the FC4 UP kernel. Of 
the two FC4 installs, another has cyrus-sasl-plain, another doesn't. It's just a 
bit random, but it is reproducible.

Comment 5 Albert Strasheim 2005-06-16 21:13:39 UTC
I just tested again and now imap:// and imaps:// works. Strange. So somehow the
bug might be related to the IMAP server. I am running dovecot-0.99.14-4.fc4. I
also upgraded from FC3 -> FC4 (as opposed to a clean install). 

It is possible that I have rebooted or that I have restarted dovecot since
reporting this problem.

I noticed some changes in /etc/doveconf.conf between FC3 and FC4, specifically
these lines changed (FC4 version shown below):

ssl_cert_file = /etc/pki/dovecot/dovecot.pem
ssl_key_file = /etc/pki/dovecot/private/dovecot.pem

Comment 6 Ed Marshall 2005-06-17 13:21:25 UTC
I'm seeing this same problem, but it's intermittant. I'm talking to a
courier-imap server, running mutt on a machine that was upgraded from FC3 to FC4
last week. The first few times I run it in the morning, it segfaults. When I
tried running it with strace, it worked, and has worked since then. I suspect
tomorrow morning, I'll have the same problem the first couple of times I run
mutt. Restarting courier has no effect. Yay heisenbugs. ;-)

Comment 7 Ed Marshall 2005-06-17 13:31:05 UTC
Created attachment 115609 [details]
mutt failure strace output

Here's the strace output of a failed mutt startup. Also, here's the gdb
traceback; not very useful, but anyway:

SSL connection using TLSv1/SSLv3 (AES256-SHA)
Program received signal SIGSEGV, Segmentation fault.
0x0028f9e3 in ?? () from /usr/lib/
(gdb) where
#0  0x0028f9e3 in ?? () from /usr/lib/
#1  0xbfa0ce3c in ?? ()
#2  0x0029e8ed in sasl_seterror () from /usr/lib/
#3  0x00295f32 in sasl_client_start () from /usr/lib/
#4  0x080ba339 in ?? ()
#5  0x0a052b20 in ?? ()
#6  0x0a044a38 in ?? ()
#7  0xbfa0e394 in ?? ()
#8  0xbfa0e38c in ?? ()
#9  0xbfa0e384 in ?? ()
#10 0xbfa0e390 in ?? ()
#11 0x00000000 in ?? ()

Comment 8 Bill Nottingham 2005-06-17 16:08:56 UTC
Hm, that backtrace might be more useful with the mutt and cyrus-sasl debuginfo
packages installed.

Comment 9 Ed Marshall 2005-06-17 16:22:32 UTC
Absolutely right. Let's try that again:

#0  0x001119e3 in ?? () from /usr/lib/
#1  0xbfd547cc in ?? ()
#2  0x001208ed in sasl_seterror (conn=0x9bb8b20, flags=Variable "flags" is not
    at ../../lib/seterror.c:260
#3  0x00117f32 in sasl_client_start (conn=0x9bb8b20, 
    mechlist=0x9baaa38 "IMAP4rev1 UIDPLUS CHILDREN NAMESPACE
    prompt_need=0xbfd55d24, clientout=0xbfd55d1c, clientoutlen=0xbfd55d14, 
    mech=0xbfd55d20) at ../../lib/client.c:570
#4  0x080ba339 in imap_auth_sasl (idata=0x9ba6990, 
    at auth_sasl.c:72
#5  0x080b9a99 in imap_authenticate (idata=0x9ba6990) at auth.c:96
#6  0x080b4f27 in imap_open_connection (idata=0x9ba6990) at imap.c:416
#7  0x080b6036 in imap_conn_find (account=0xbfd57204, flags=Variable "flags" is
not available.
) at imap.c:356
#8  0x080b661d in imap_open_mailbox (ctx=0x9ba79e8) at imap.c:521
#9  0x0807f33d in mx_open_mailbox (
    path=0xbfd57a94 "imap://esm@localhost/INBOX", flags=Variable "flags" is not
) at mx.c:694
#10 0x08075e4e in main (argc=1, argv=0xbfd57c94) at main.c:839
#11 0x00177de6 in __libc_start_main () from /lib/
#12 0x0804c511 in _start ()

Comment 10 Bill Nottingham 2005-06-17 16:26:32 UTC
Assigning to cyrus-sasl for now.

Comment 11 Mark Mielke 2005-07-25 20:19:29 UTC
I get the same behaviour when using cyrus-imapd as a server. The problem comes
and goes. Sometimes if I execute mutt multiple times in a row, it eventually
works. Sometimes it doesn't work at all until the next day. (I had it stop
working for 3 or 4 days, and then suddenly start working again every time)

The stack trace looks consistent with the stack trace that I've seen.

Comment 12 Christian Iseli 2007-01-22 11:02:36 UTC
This report targets the FC3 or FC4 products, which have now been EOL'd.

Could you please check that it still applies to a current Fedora release, and
either update the target product or close it ?


Comment 13 Steve Conklin 2007-11-01 16:58:56 UTC
These products have been moved to end of life, please use a later release.

Note You need to log in before you can comment on or make changes to this bug.