Debian Bug report logs - #292663
mutt blocks at recv after gnutls handshake

Toggle useless messages

Message #5 received at submit@bugs.debian.org (full text, mbox, reply):

From: Miciah Dashiel Butler Masters <miciah@myrealbox.com>

To: submit@bugs.debian.org

Subject: Mutt freezes, indefinite sleep after calling recv

Date: Mon, 22 Nov 2004 08:14:05 +0000

Package: mutt
Version: 1.5.6-20040907+1

I use Mutt with the IMAPS server at mail.myrealbox.com.  Twice today,
Mutt has frozen. Both times, it had been idle, presumably polling
the mail server.  The second time, I tried attaching to it with GDB:

% gdb -p 22641
GNU gdb 6.0-debian
Copyright 2003 Free Software Foundation, Inc.
GDB is free software, covered by the GNU General Public License, and you
are
welcome to change it and/or distribute copies of it under certain
conditions.
Type "show copying" to see the conditions.
There is absolutely no warranty for GDB.  Type "show warranty" for
details.
This GDB was configured as "i386-linux".
Attaching to process 22641
Reading symbols from /usr/bin/mutt...(no debugging symbols
found)...done.
Reading symbols from /usr/lib/libncursesw.so.5...(no debugging symbols
found)...done.
Loaded symbols for /usr/lib/libncursesw.so.5
Reading symbols from /usr/lib/libsasl2.so.2...(no debugging symbols
found)...done.
Loaded symbols for /usr/lib/libsasl2.so.2
Reading symbols from /usr/lib/libgnutls.so.11...(no debugging symbols
found)...done.
Loaded symbols for /usr/lib/libgnutls.so.11
Reading symbols from /usr/lib/libidn.so.11...(no debugging symbols
found)...done.
Loaded symbols for /usr/lib/libidn.so.11
Reading symbols from /usr/lib/libdb-4.2.so...(no debugging symbols
found)...done.
Loaded symbols for /usr/lib/libdb-4.2.so
Reading symbols from /lib/tls/libc.so.6...(no debugging symbols
found)...done.
Loaded symbols for /lib/tls/libc.so.6
Reading symbols from /lib/tls/libdl.so.2...(no debugging symbols
found)...done.
Loaded symbols for /lib/tls/libdl.so.2
Reading symbols from /lib/tls/libresolv.so.2...(no debugging symbols
found)...done.
Loaded symbols for /lib/tls/libresolv.so.2
Reading symbols from /usr/lib/libtasn1.so.2...(no debugging symbols
found)...done.
Loaded symbols for /usr/lib/libtasn1.so.2
Reading symbols from /usr/lib/libgcrypt.so.11...(no debugging symbols
found)...done.
Loaded symbols for /usr/lib/libgcrypt.so.11
Reading symbols from /usr/lib/libgpg-error.so.0...(no debugging symbols
found)...done.
Loaded symbols for /usr/lib/libgpg-error.so.0
Reading symbols from /usr/lib/libz.so.1...(no debugging symbols
found)...done.
Loaded symbols for /usr/lib/libz.so.1
Reading symbols from /lib/ld-linux.so.2...(no debugging symbols
found)...done.
Loaded symbols for /lib/ld-linux.so.2
Reading symbols from /lib/tls/libnsl.so.1...(no debugging symbols
found)...done.
Loaded symbols for /lib/tls/libnsl.so.1
Reading symbols from /lib/tls/libnss_compat.so.2...(no debugging symbols
found)...done.
Loaded symbols for /lib/tls/libnss_compat.so.2
Reading symbols from /lib/tls/libnss_nis.so.2...(no debugging symbols
found)...done.
Loaded symbols for /lib/tls/libnss_nis.so.2
Reading symbols from /lib/tls/libnss_files.so.2...(no debugging symbols
found)...done.
Loaded symbols for /lib/tls/libnss_files.so.2
Reading symbols from /usr/lib/gconv/ISO8859-1.so...(no debugging symbols
found)...done.
Loaded symbols for /usr/lib/gconv/ISO8859-1.so
Reading symbols from /lib/tls/libnss_dns.so.2...(no debugging symbols
found)...done.
Loaded symbols for /lib/tls/libnss_dns.so.2
Reading symbols from /usr/lib/sasl2/libsasldb.so.2...(no debugging
symbols found)...done.
Loaded symbols for /usr/lib/sasl2/libsasldb.so.2
0x402c7bfc in recv () from /lib/tls/libc.so.6
(gdb) bt
#0  0x402c7bfc in recv () from /lib/tls/libc.so.6
#1  0x40094795 in _gnutls_handshake_buffer_clear () from
/usr/lib/libgnutls.so.11
#2  0x400933c5 in _gnutls_io_read_buffered () from
/usr/lib/libgnutls.so.11
#3  0x40090e96 in _gnutls_recv_int () from /usr/lib/libgnutls.so.11
#4  0x4009199f in gnutls_record_recv () from /usr/lib/libgnutls.so.11
#5  0x080b063e in ?? ()
#6  0x08241a90 in ?? ()
#7  0x0822041c in ?? ()
#8  0x00000400 in ?? ()

I tried continuing and ctrl-c'ing a couple of times. The first time
(I believe) I got a 'Mailbox unchanged' message to appear in Mutt's
status bar. Eventually, after I had left it continuing
for a few minutes, it '[c]aught signal 15' and exited.

Should it happen again, what might I do to gain some more useful
information?

Much love!

-- 
Miciah Masters <miciah@myrealbox.com> / <mdm0304@mail.ecu.edu>

Message #10 received at 282451@bugs.debian.org (full text, mbox, reply):

From: Thomas Glanzmann <sithglan@stud.uni-erlangen.de>

To: Miciah Dashiel Butler Masters <miciah@myrealbox.com>

Cc: 282451@bugs.debian.org

Subject: Re: Mutt freezes, indefinite sleep after calling recv

Date: Tue, 23 Nov 2004 02:55:41 +0100

Hello,
I just received a bugreport from another user which has the exactly same
symptoms with a Lotus Notes IMAP Server. It seems to be hcache related.
Could you please try to build 1.5.6-20040907+1 yourself once using
hcache and once without and try to access the IMAP server?

I am waiting for the moment for information from another user to track
this issue down. I will forward his eMails, if he allows me to.

http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=282451

Honestly,
	Thomas

Message #15 received at 282451@bugs.debian.org (full text, mbox, reply):

From: Adeodato Simó <asp16@alu.ua.es>

To: Miciah Dashiel Butler Masters <miciah@myrealbox.com>, 282451@bugs.debian.org

Subject: Re: Bug#282451: Mutt freezes, indefinite sleep after calling recv

Date: Mon, 29 Nov 2004 23:16:16 +0100

* Miciah Dashiel Butler Masters [Mon, 22 Nov 2004 08:14:05 +0000]:
> Package: mutt
> Version: 1.5.6-20040907+1

> I use Mutt with the IMAPS server at mail.myrealbox.com.  Twice today,
> Mutt has frozen. Both times, it had been idle, presumably polling
> the mail server.  The second time, I tried attaching to it with GDB:

  if this is still happening with -2, please tell and I'll provide you a
  package with version #25 of the hcache patch to see if that fixes your
  problem.

  thanks,

-- 
Adeodato Simó
    EM: asp16 [ykwim] alu.ua.es | PK: DA6AE621
    Listening to: Miguel Bosé - 03 Miguel Bosé - Si tú no vuelves
 
The surest way to corrupt a youth is to instruct him to hold in higher
esteem those who think alike than those who think differently.
                -- F. Nietzsche

Message #22 received at 282451@bugs.debian.org (full text, mbox, reply):

From: Maciej Kalisiak <mac@cs.toronto.edu>

To: Debian Bug Tracking System <282451@bugs.debian.org>

Subject: mutt: same problem, but everytime on IMAP+TLS connect attempt

Date: Thu, 20 Jan 2005 20:14:57 -0500

Package: mutt
Version: 1.5.6-20040907+2
Followup-For: Bug #282451

I am experiencing the same bug, but for me it is very persistent.  Basically
every time I try to connect to imaps:// mailbox, mutt hangs right after I've
entered my remote username and password for TLS.  gdb has shown the same stack
as reported earlier in this bug report.  I'm trying to connect to a Debian
system running an imap server with "uw-imapd-ssl" (stable distro).  I'm
willing to test out any patches you may have, or try other workarounds, to
further diagnose this problem.

-- System Information:
Debian Release: testing/unstable
  APT prefers unstable
  APT policy: (500, 'unstable')
Architecture: i386 (i686)
Kernel: Linux 2.4.24-1-686
Locale: LANG=C, LC_CTYPE=C (charmap=ANSI_X3.4-1968)

Versions of packages mutt depends on:
ii  libc6                       2.3.2.ds1-16 GNU C Library: Shared libraries an
ii  libdb4.2                    4.2.52-9     Berkeley v4.2 Database Libraries [
ii  libgnutls11                 1.0.16-13    GNU TLS library - runtime library
ii  libidn11                    0.5.2-3      GNU libidn library, implementation
ii  libncursesw5                5.4-4        Shared libraries for terminal hand
ii  libsasl2                    2.1.19-1.5   Authentication abstraction library
ii  postfix [mail-transport-age 2.0.7-3      A high-performance mail transport 

-- no debconf information

Message #27 received at 282451@bugs.debian.org (full text, mbox, reply):

From: Adeodato Simó <asp16@alu.ua.es>

To: mac@dgp.toronto.edu, 282451@bugs.debian.org

Subject: Re: Bug#282451: mutt: same problem, but everytime on IMAP+TLS connect attempt

Date: Fri, 21 Jan 2005 02:38:43 +0100

* Maciej Kalisiak [Thu, 20 Jan 2005 20:14:57 -0500]:

> willing to test out any patches you may have, or try other workarounds, to
> further diagnose this problem.

  Uhm, I read in the bug log that the first proposed fix was version #25
  of the header cache patch. Please compile this package:

    http://the-swirl.org/~adeodato/tmp/2005/01/15/mutt

  If that doesn't solve, please report and we'll investigate. If you
  can't compile, just say so and I'll provide a compiled package
  tomorrow.

  Thanks.

-- 
Adeodato Simó
    EM: asp16 [ykwim] alu.ua.es | PK: DA6AE621
 
He has never been known to use a word that might send a reader to the
dictionary.
                -- William Faulkner (about Ernest Hemingway)

Message #32 received at 282451@bugs.debian.org (full text, mbox, reply):

From: Maciej Kalisiak <mac@dgp.toronto.edu>

To: 282451@bugs.debian.org, Adeodato Sim? <asp16@alu.ua.es>

Subject: Re: Bug#282451: mutt: same problem, but everytime on IMAP+TLS connect attempt

Date: Thu, 20 Jan 2005 20:57:02 -0500

On Fri, Jan 21, 2005 at 02:38:43AM +0100, Adeodato Sim? wrote:
>   Uhm, I read in the bug log that the first proposed fix was version #25
>   of the header cache patch. Please compile this package:
> 
>     http://the-swirl.org/~adeodato/tmp/2005/01/15/mutt
> 
>   If that doesn't solve, please report and we'll investigate. If you
>   can't compile, just say so and I'll provide a compiled package
>   tomorrow.

I will try it out, but I don't know where to get said patch... is there
some repository for them, or is it already there if I do "apt-get source
mutt"?  There is a header-cache.diff patch in there, but I am not sure how to
assess its version #.

Is the diff tarball at the above URL any different from what I would get if I
just do "apt-get source mutt; debian/rules unpack"?  Which one should I use
(the one at the URL has "+1~pre1" suffix instead of "+2")

-- 
I plan on living forever. So far, so good.

Message #37 received at 282451@bugs.debian.org (full text, mbox, reply):

From: Adeodato Simó <asp16@alu.ua.es>

To: Maciej Kalisiak <mac@dgp.toronto.edu>, 282451@bugs.debian.org

Subject: Re: Bug#282451: mutt: same problem, but everytime on IMAP+TLS connect attempt

Date: Fri, 21 Jan 2005 03:04:39 +0100

* Maciej Kalisiak [Thu, 20 Jan 2005 20:57:02 -0500]:

> I will try it out, but I don't know where to get said patch... is there
> some repository for them, or is it already there if I do "apt-get source
> mutt"?  There is a header-cache.diff patch in there, but I am not sure how to
> assess its version #.

  The source package in the url above included it.

> Is the diff tarball at the above URL any different from what I would get if I
> just do "apt-get source mutt; debian/rules unpack"?  Which one should I use
> (the one at the URL has "+1~pre1" suffix instead of "+2")

  It is an in-progress version of the next upload to Debian, so yes,
  it's different and _newer_ to what apt-get source mutt would give you.

  Anyway, I've compiled the package and put it there, you can use that
  and check.

  Thanks.

-- 
Adeodato Simó
    EM: asp16 [ykwim] alu.ua.es | PK: DA6AE621
 
A hacker does for love what other would not do for money.

Message #42 received at 282451@bugs.debian.org (full text, mbox, reply):

From: Maciej Kalisiak <mac@dgp.toronto.edu>

To: 282451@bugs.debian.org, Adeodato Sim? <asp16@alu.ua.es>

Subject: Re: Bug#282451: mutt: same problem, but everytime on IMAP+TLS connect attempt

Date: Thu, 20 Jan 2005 21:14:24 -0500

On Fri, Jan 21, 2005 at 03:04:39AM +0100, Adeodato Sim? wrote:
>   Anyway, I've compiled the package and put it there, you can use that
>   and check.

OK, thanks.

I installed the new .deb and tried connecting to the imaps:// server.
Unfortunately I must report that the problem persists.  Attaching to the
process with gdb and displaying the stack shows the same situation, with mutt
stuck on the recv() call.

-- 
"The release of atomic energy has not created a new problem. It has merely
 made more urgent the necessity of solving an existing one." -- Albert
 Einstein

Message #47 received at 282451@bugs.debian.org (full text, mbox, reply):

From: Thomas Glanzmann <sithglan@stud.uni-erlangen.de>

To: Maciej Kalisiak <mac@dgp.toronto.edu>

Cc: 282451@bugs.debian.org

Subject: Re: Bug#282451: mutt: same problem, but everytime on IMAP+TLS connect attempt

Date: Fri, 21 Jan 2005 10:23:05 +0100

Hello,
could you please send me an useful backtrace?

apt-get install libc6-dbg

LD_LIBRARY_PATH=/usr/lib/debug mutt

gdb /usr/bin/mutt
attach pid

reproduce the problem and type backtrace. :-)

Hopefully we get the name of the calling function.

Does this happen also with an empty mailbox?

	Thomas

Message #52 received at 282451@bugs.debian.org (full text, mbox, reply):

From: Maciej Kalisiak <mac@dgp.toronto.edu>

To: Thomas Glanzmann <sithglan@stud.uni-erlangen.de>

Cc: 282451@bugs.debian.org

Subject: Re: Bug#282451: mutt: same problem, but everytime on IMAP+TLS connect attempt

Date: Fri, 21 Jan 2005 04:45:18 -0500

On Fri, Jan 21, 2005 at 10:23:05AM +0100, Thomas Glanzmann wrote:
> could you please send me an useful backtrace?
> 
> apt-get install libc6-dbg
> 
> LD_LIBRARY_PATH=/usr/lib/debug mutt
> 
> gdb /usr/bin/mutt
> attach pid
> 
> reproduce the problem and type backtrace. :-)

Here is what I get:

(gdb) backtrace
#0  0x402cc276 in recv () from /usr/lib/debug/libc.so.6
#1  0x4009c7d5 in _gnutls_handshake_buffer_clear ()
   from /usr/lib/libgnutls.so.11
#2  0x4009b405 in _gnutls_io_read_buffered () from /usr/lib/libgnutls.so.11
#3  0x40098ed6 in _gnutls_recv_int () from /usr/lib/libgnutls.so.11
#4  0x400999df in gnutls_record_recv () from /usr/lib/libgnutls.so.11
#5  0x080b085e in free ()
#6  0x080c25f4 in free ()
#7  0x080c26f2 in free ()
#8  0x080c7a28 in free ()
#9  0x080c8d78 in free ()
#10 0x080c9058 in free ()
#11 0x080c9544 in free ()
#12 0x08085989 in free ()
#13 0x0806428f in free ()
#14 0x0807c160 in free ()
#15 0x40209dc6 in __libc_start_main (main=0x807b600 <free+193832>, argc=1,
    ubp_av=0x8154f30, init=0x80cf820 <free+538440>,
    fini=0x80cf880 <free+538536>, rtld_fini=0x1ff, stack_end=0x400eb820)
    at ../sysdeps/generic/libc-start.c:242

> Does this happen also with an empty mailbox?

Yes.

-- 
"A man who dares to waste one hour of time has not discovered the value of
 life." -- Charles Robert Darwin

Message #57 received at 282451@bugs.debian.org (full text, mbox, reply):

From: Adeodato Simó <asp16@alu.ua.es>

To: mac@dgp.toronto.edu, 282451@bugs.debian.org

Subject: Re: Bug#282451: mutt: same problem, but everytime on IMAP+TLS connect attempt

Date: Fri, 21 Jan 2005 23:18:48 +0100

* Maciej Kalisiak [Thu, 20 Jan 2005 21:14:24 -0500]:

> I installed the new .deb and tried connecting to the imaps:// server.
> Unfortunately I must report that the problem persists.  Attaching to the
> process with gdb and displaying the stack shows the same situation, with mutt
> stuck on the recv() call.

  OK. Then, let's try another thing. The original report seemed to have
  something to do with the header cache. Could you try this package?

    http://the-swirl.org/~adeodato/tmp/2005/01/21/mutt-nohcache

  Thanks.

-- 
Adeodato Simó
    EM: asp16 [ykwim] alu.ua.es | PK: DA6AE621
    Listening to: Miguel Bosé - Sevilla
 
One way to make your old car run better is to look up the price of a new model.

Message #62 received at 282451@bugs.debian.org (full text, mbox, reply):

From: Maciej Kalisiak <mac@dgp.toronto.edu>

To: 282451@bugs.debian.org, Adeodato Sim? <asp16@alu.ua.es>

Subject: Re: Bug#282451: mutt: same problem, but everytime on IMAP+TLS connect attempt

Date: Sat, 22 Jan 2005 13:22:02 -0500

On Fri, Jan 21, 2005 at 11:18:48PM +0100, Adeodato Sim? wrote:
>   OK. Then, let's try another thing. The original report seemed to have
>   something to do with the header cache. Could you try this package?
> 
>     http://the-swirl.org/~adeodato/tmp/2005/01/21/mutt-nohcache

No change.  The backtrace is the same.  I did some more poking around.  Giving
the wrong password works as it should, with mutt saying the password was
incorrect, and resuming normal menu operation.

I also did a "strace -f -F -ff -o strace_out mutt" and here's the sequence of
events on the main mutt thread, starting with me finishing to enter password:

read(0, "*", 1)                         = 1
rt_sigaction(SIGINT, {0x80a5bd0, [], SA_RESTORER|SA_RESTART, 0x40147678},
NULL, 8) = 0
rt_sigaction(SIGINT, {0x80a5bd0, [], SA_RESTORER, 0x40147678}, NULL, 8) = 0
read(0, "*", 1)                         = 1
rt_sigaction(SIGINT, {0x80a5bd0, [], SA_RESTORER|SA_RESTART, 0x40147678},
NULL, 8) = 0
rt_sigaction(SIGINT, {0x80a5bd0, [], SA_RESTORER, 0x40147678}, NULL, 8) = 0
read(0, "*", 1)                         = 1
rt_sigaction(SIGINT, {0x80a5bd0, [], SA_RESTORER|SA_RESTART, 0x40147678},
NULL, 8) = 0
rt_sigaction(SIGINT, {0x80a5bd0, [], SA_RESTORER, 0x40147678}, NULL, 8) = 0
read(0, "\r", 1)                        = 1
rt_sigaction(SIGINT, {0x80a5bd0, [], SA_RESTORER|SA_RESTART, 0x40147678},
NULL, 8) = 0
write(1, "\r\33[37m\33[40mLogging in...\33[K\33[m\17\33"..., 49) = 49
  gettimeofday({1106417266, 484524}, NULL) = 0
  getrusage(RUSAGE_SELF, {ru_utime={0, 70000}, ru_stime={0, 10000}, ...}) = 0
  time(NULL)                              = 1106417266
  times({tms_utime=7, tms_stime=1, tms_cutime=1, tms_cstime=0}) = 9006147
  gettimeofday({1106417266, 484764}, NULL) = 0
  getrusage(RUSAGE_SELF, {ru_utime={0, 70000}, ru_stime={0, 10000}, ...}) = 0
  time(NULL)                              = 1106417266
  times({tms_utime=7, tms_stime=1, tms_cutime=1, tms_cstime=0}) = 9006147
send(4, "\27\3\1\0\330\220VUN\2653\2416!\247I\225\311\16r\316G\370"..., 221, 0) = 221
recv(4, "\27\3\1\0\270", 5, 0)          = 5
recv(4, "\251\3153\363T\247t\256\235\3252\2Xb\207\252\37\273\221"..., 183, 0) = 183
recv(4, "\226", 1, MSG_PEEK)            = 1
  gettimeofday({1106417266, 578025}, NULL) = 0
  getrusage(RUSAGE_SELF, {ru_utime={0, 70000}, ru_stime={0, 10000}, ...}) = 0
  time(NULL)                              = 1106417266
  times({tms_utime=7, tms_stime=1, tms_cutime=1, tms_cstime=0}) = 9006156
  gettimeofday({1106417266, 578375}, NULL) = 0
  getrusage(RUSAGE_SELF, {ru_utime={0, 80000}, ru_stime={0, 10000}, ...}) = 0
  time(NULL)                              = 1106417266
  times({tms_utime=8, tms_stime=1, tms_cutime=1, tms_cstime=0}) = 9006157
recv(4, "\226", 1, 0)                   = 1
  time(NULL)                              = 1106417266
  gettimeofday({1106417266, 578597}, NULL) = 0
  getrusage(RUSAGE_SELF, {ru_utime={0, 80000}, ru_stime={0, 10000}, ...}) = 0
  time(NULL)                              = 1106417266
  times({tms_utime=8, tms_stime=1, tms_cutime=1, tms_cstime=0}) = 9006157
  gettimeofday({1106417266, 578718}, NULL) = 0
  getrusage(RUSAGE_SELF, {ru_utime={0, 80000}, ru_stime={0, 10000}, ...}) = 0
  time(NULL)                              = 1106417266
  times({tms_utime=8, tms_stime=1, tms_cutime=1, tms_cstime=0}) = 9006157
send(4, "\27\3\1\0`\'\240`cH\3108\20\35\301\367\351\344\274\335"..., 101, 0) = 101
recv(4,

and this is where it hangs.  I've indented the non-interesting calls.  Seems
mutt sends the encrypted password, receives a response over a number of
recv()s, and then gets no response to its very next send()... not as helpful
as it could be, but perhaps it will be of use.

-- 
"If it weren't for lack of context, there would be no news." --Scott Adams
Maciej Kalisiak       mac "at" dgp.toronto.edu       www.dgp.toronto.edu/~mac

Message #67 received at 282451@bugs.debian.org (full text, mbox, reply):

From: Adeodato Simó <asp16@alu.ua.es>

To: 282451@bugs.debian.org

Cc: control@bugs.debian.org

Subject: There are two bugs here, cloning

Date: Fri, 28 Jan 2005 18:11:34 +0100

clone 282451 -1
retitle -1 mutt blocks at recv after gnutls handshake
tag 282451 pending
thanks bot

  There are two separate in #282451. The first one, reported by Miciah
  Dashiel, is hcache related and will be solved in the next upload.

  The second one, reported by Maciej Kalisiak, is a different problem.

-- 
Adeodato Simó
    EM: asp16 [ykwim] alu.ua.es | PK: DA6AE621
 
You've come to the right place.  At debian-devel we are always willing
to argue over the meanings of words.
                -- seen on debian-devel@l.d.o

Message #76 received at 292663@bugs.debian.org (full text, mbox, reply):

From: Adeodato Simó <asp16@alu.ua.es>

To: Maciej Kalisiak <mac@dgp.toronto.edu>, 292663@bugs.debian.org

Cc: control@bugs.debian.org

Subject: Re: Bug#282451: mutt: same problem, but everytime on IMAP+TLS connect attempt

Date: Mon, 19 Sep 2005 01:56:42 +0200

tag 292663 moreinfo
thanks

* Maciej Kalisiak [Sat, 22 Jan 2005 13:22:02 -0500]:

> On Fri, Jan 21, 2005 at 11:18:48PM +0100, Adeodato Sim? wrote:
> >   OK. Then, let's try another thing. The original report seemed to have
> >   something to do with the header cache. Could you try this package?

> >     http://the-swirl.org/~adeodato/tmp/2005/01/21/mutt-nohcache

> No change.  The backtrace is the same.  I did some more poking around.  Giving
> the wrong password works as it should, with mutt saying the password was
> incorrect, and resuming normal menu operation.

Hi,

  does this still happen with recent versions of mutt? Can you try with
  this one?:

    http://people.debian.org/~adeodato/tmp/2005-09-19/mutt-1.5.11-pre/mutt_1.5.11-1~pre1_i386.deb

  Thanks,

-- 
Adeodato Simó
    EM: asp16 [ykwim] alu.ua.es | PK: DA6AE621
 
A lie can go round the world before the truth has got its boots on.
                -- Terry Pratchett

Message #81 received at 292663@bugs.debian.org (full text, mbox, reply):

From: Christoph Berg <myon@debian.org>

To: Maciej Kalisiak <mac@dgp.toronto.edu>

Cc: 292663@bugs.debian.org

Subject: Re: mutt: same problem, but everytime on IMAP+TLS connect attempt

Date: Tue, 13 Feb 2007 18:16:45 +0100

[Message part 1 (text/plain, inline)]

Hi Maciej,

sorry for the late followup - can you still reproduce the behavior
reported in #292663?

Re: Maciej Kalisiak 2005-01-22 <20050122182202.GA17511@khazad-dum>
> >   OK. Then, let's try another thing. The original report seemed to have
> >   something to do with the header cache. Could you try this package?
> > 
> >     http://the-swirl.org/~adeodato/tmp/2005/01/21/mutt-nohcache
> 
> No change.  The backtrace is the same.  I did some more poking around.  Giving
> the wrong password works as it should, with mutt saying the password was
> incorrect, and resuming normal menu operation.
> 
> I also did a "strace -f -F -ff -o strace_out mutt" and here's the sequence of
> events on the main mutt thread, starting with me finishing to enter password:
[...]
> and this is where it hangs.  I've indented the non-interesting calls.  Seems
> mutt sends the encrypted password, receives a response over a number of
> recv()s, and then gets no response to its very next send()... not as helpful
> as it could be, but perhaps it will be of use.

Christoph
-- 
cb@df7cb.de | http://www.df7cb.de/

[signature.asc (application/pgp-signature, inline)]

Message #86 received at 292663@bugs.debian.org (full text, mbox, reply):

From: "Maciej Kalisiak" <mac@dgp.toronto.edu>

To: "Christoph Berg" <myon@debian.org>, "Maciej Kalisiak" <mac@dgp.toronto.edu>, 292663@bugs.debian.org

Subject: Re: mutt: same problem, but everytime on IMAP+TLS connect attempt

Date: Tue, 13 Feb 2007 12:28:19 -0500

It's been ages since I've encountered that issue... even if it still
existed I doubt I'd be able to reproduce it now... :)

On 2/13/07, Christoph Berg <myon@debian.org> wrote:
> Hi Maciej,
>
> sorry for the late followup - can you still reproduce the behavior
> reported in #292663?
>
> Re: Maciej Kalisiak 2005-01-22 <20050122182202.GA17511@khazad-dum>
> > >   OK. Then, let's try another thing. The original report seemed to have
> > >   something to do with the header cache. Could you try this package?
> > >
> > >     http://the-swirl.org/~adeodato/tmp/2005/01/21/mutt-nohcache
> >
> > No change.  The backtrace is the same.  I did some more poking around.  Giving
> > the wrong password works as it should, with mutt saying the password was
> > incorrect, and resuming normal menu operation.
> >
> > I also did a "strace -f -F -ff -o strace_out mutt" and here's the sequence of
> > events on the main mutt thread, starting with me finishing to enter password:
> [...]
> > and this is where it hangs.  I've indented the non-interesting calls.  Seems
> > mutt sends the encrypted password, receives a response over a number of
> > recv()s, and then gets no response to its very next send()... not as helpful
> > as it could be, but perhaps it will be of use.
>
> Christoph
> --
> cb@df7cb.de | http://www.df7cb.de/
>
> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG v1.4.5 (GNU/Linux)
>
> iD8DBQFF0fJ9xa93SlhRC1oRApaiAJ4tR3SgxxZVf5Sf5XqG6mDf+AT5iACgstPU
> orymrniDJmQPTYKhgA4D/7E=
> =geIj
> -----END PGP SIGNATURE-----
>
>


-- 
Maciej Kalisiak
mac [at] dgp.toronto.edu
http://www.dgp.toronto.edu/~mac

Message #91 received at 292663-done@bugs.debian.org (full text, mbox, reply):

From: Christoph Berg <myon@debian.org>

To: Maciej Kalisiak <mac@dgp.toronto.edu>

Cc: 292663-done@bugs.debian.org

Subject: Re: mutt: same problem, but everytime on IMAP+TLS connect attempt

Date: Wed, 14 Feb 2007 13:06:45 +0100

[Message part 1 (text/plain, inline)]

Re: Maciej Kalisiak 2007-02-13 <78e6ba310702130928n7a09d0b3h2812ef9c306b3f62@mail.gmail.com>
> It's been ages since I've encountered that issue... even if it still
> existed I doubt I'd be able to reproduce it now... :)

Hi,

thanks for the reply. Let's close the bug for now and hope it doesn't
pop up again...

Christoph
-- 
cb@df7cb.de | http://www.df7cb.de/

[signature.asc (application/pgp-signature, inline)]

Message #92 received at 292663-done@bugs.debian.org (full text, mbox, reply):

From: "Maciej Kalisiak" <mac@dgp.toronto.edu>

To: "Christoph Berg" <myon@debian.org>, "Maciej Kalisiak" <mac@dgp.toronto.edu>, 292663-done@bugs.debian.org

Subject: Re: mutt: same problem, but everytime on IMAP+TLS connect attempt

Date: Wed, 14 Feb 2007 10:29:43 -0500

agreed.

On 2/14/07, Christoph Berg <myon@debian.org> wrote:
> Re: Maciej Kalisiak 2007-02-13 <78e6ba310702130928n7a09d0b3h2812ef9c306b3f62@mail.gmail.com>
> > It's been ages since I've encountered that issue... even if it still
> > existed I doubt I'd be able to reproduce it now... :)
>
> Hi,
>
> thanks for the reply. Let's close the bug for now and hope it doesn't
> pop up again...
>
> Christoph
> --
> cb@df7cb.de | http://www.df7cb.de/
>
> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG v1.4.5 (GNU/Linux)
>
> iD8DBQFF0vtVxa93SlhRC1oRAtlVAKDREZCtgLyoilE8z1Iohao5uqrJSwCgiXyM
> gq56wWJGWyXx6vmeoyGPyvU=
> =e0QG
> -----END PGP SIGNATURE-----
>
>


-- 
Maciej Kalisiak
mac [at] dgp.toronto.edu
http://www.dgp.toronto.edu/~mac

Send a report that this bug log contains spam.