Bug 160482 - segfault while using imap-folders
segfault while using imap-folders
Product: Fedora
Classification: Fedora
Component: cyrus-sasl (Show other bugs)
All Linux
medium Severity medium
: ---
: ---
Assigned To: Steve Conklin
Brian Brock
Depends On:
  Show dependency treegraph
Reported: 2005-06-15 09:19 EDT by Need Real Name
Modified: 2007-11-30 17:11 EST (History)
5 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Last Closed: 2007-11-01 12:58:56 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---

Attachments (Terms of Use)
mutt failure strace output (39.08 KB, text/plain)
2005-06-17 09:31 EDT, Ed Marshall
no flags Details

  None (edit)
Description Need Real Name 2005-06-15 09:19:55 EDT
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-15 20:06:09 EDT
Probably a duplicate of bug 157521.
Comment 2 Need Real Name 2005-06-16 16:34:13 EDT
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 16:54:29 EDT
I can't reproduce this, even with cyrus-sasl-plain uninstalled.
Comment 4 Ville Herva 2005-06-16 17:02:00 EDT
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 17:13:39 EDT
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 09:21:25 EDT
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 09:31:05 EDT
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/libsasl2.so.2
(gdb) where
#0  0x0028f9e3 in ?? () from /usr/lib/libsasl2.so.2
#1  0xbfa0ce3c in ?? ()
#2  0x0029e8ed in sasl_seterror () from /usr/lib/libsasl2.so.2
#3  0x00295f32 in sasl_client_start () from /usr/lib/libsasl2.so.2
#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 12:08:56 EDT
Hm, that backtrace might be more useful with the mutt and cyrus-sasl debuginfo
packages installed.
Comment 9 Ed Marshall 2005-06-17 12:22:32 EDT
Absolutely right. Let's try that again:

#0  0x001119e3 in ?? () from /usr/lib/libsasl2.so.2
#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/libc.so.6
#12 0x0804c511 in _start ()
Comment 10 Bill Nottingham 2005-06-17 12:26:32 EDT
Assigning to cyrus-sasl for now.
Comment 11 Mark Mielke 2005-07-25 16:19:29 EDT
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 06:02:36 EST
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 12:58:56 EDT
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.