Bug 160482 - segfault while using imap-folders
Summary: segfault while using imap-folders
Keywords:
Status: CLOSED WONTFIX
Alias: None
Product: Fedora
Classification: Fedora
Component: cyrus-sasl
Version: 4
Hardware: All
OS: Linux
medium
medium
Target Milestone: ---
Assignee: Steve Conklin
QA Contact: Brian Brock
URL:
Whiteboard:
Depends On:
Blocks:
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:
Clone Of:
Environment:
Last Closed: 2007-11-01 16:58:56 UTC
Type: ---
Embargoed:


Attachments (Terms of Use)
mutt failure strace output (39.08 KB, text/plain)
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     : 1.4.2.1                           Vendor: Red Hat, Inc.
Release     : 2                             Build Date: Mon Mar  7 23:44:48 2005

How reproducible:
Always.

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 1.4.2.1-2, 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/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 ?? ()
(gdb)

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/libsasl2.so.2
#1  0xbfd547cc in ?? ()
#2  0x001208ed in sasl_seterror (conn=0x9bb8b20, flags=Variable "flags" is not
available.
)
    at ../../lib/seterror.c:260
#3  0x00117f32 in sasl_client_start (conn=0x9bb8b20, 
    mechlist=0x9baaa38 "IMAP4rev1 UIDPLUS CHILDREN NAMESPACE
THREAD=ORDEREDSUBJECT THREAD=REFERENCES SORT QUOTA IDLE AUTH=PLAIN ACL ACL2=UNION", 
    prompt_need=0xbfd55d24, clientout=0xbfd55d1c, clientoutlen=0xbfd55d14, 
    mech=0xbfd55d20) at ../../lib/client.c:570
#4  0x080ba339 in imap_auth_sasl (idata=0x9ba6990, 
    method=0x9baaa38 "IMAP4rev1 UIDPLUS CHILDREN NAMESPACE THREAD=ORDEREDSUBJECT
THREAD=REFERENCES SORT QUOTA IDLE AUTH=PLAIN ACL ACL2=UNION")
    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
available.
) 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 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 ?

Thanks.

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.