Bug 136075

Summary:

IMAP stops working.

Product:

[Fedora] Fedora

Reporter:

David Woodhouse <dwmw2>

Component:

evolution

Assignee:

Dave Malcolm <dmalcolm>

Status:

CLOSED DUPLICATE

QA Contact:

Severity:

high

Docs Contact:

Priority:

medium

Version:

rawhide

Target Milestone:

---

Target Release:

---

Hardware:

All

OS:

Linux

Whiteboard:

Fixed In Version:

Doc Type:

Bug Fix

Doc Text:

Story Points:

---

Clone Of:

Environment:

Last Closed:

2006-02-21 19:06:23 UTC

Type:

---

Regression:

---

Mount Type:

---

Documentation:

---

CRM:

Verified Versions:

Category:

---

oVirt Team:

---

RHEL 7.3 requirements from Atomic Host:

Cloudforms Team:

---

Target Upstream Version:

Embargoed:

Attachments:

Description	Flags
Output with CAMEL_VERBOSE_DEBUG=1	none

Description David Woodhouse 2004-10-17 16:26:47 UTC

Description of problem:
After connecting to its two configured IMAP servers issuing STATUS on
all folders (even the ones marked inactive), Evolution stops working.
I cannot change folders or view mail in the folder which I did manage
to select. There's no IMAP traffic at all -- it doesn't even manage to
log out from account A if I ask it to go offline.


Version-Release number of selected component (if applicable):
2.0.2-1

I'm attaching a full log showing what Evolution does with
CAMEL_VERBOSE_DEBUG in the five minutes it takes to start up (this is
a stock evo without my patch to check for mail only in active folders).

Note that although it manages to display the inbox of server A, it
doesn't manage to display the message UID 11187 from that mailbox,
which it does fetch from the server (A00547). The preview pane is blank.

It looks like account A is becoming 'stuck' somehow as soon as
Evolution starts issuing commands on account B.

Comment 1 David Woodhouse 2004-10-17 16:27:42 UTC

Created attachment 105351 [details]
Output with CAMEL_VERBOSE_DEBUG=1

Comment 2 David Woodhouse 2004-10-17 16:50:55 UTC

Next time round, it seemed happy changing folders and viewing mail in
server A until it had finished checking all folders in server B.
Here's a backtrace when it stops working again...

Program received signal SIGINT, Interrupt.
[Switching to Thread 810645280 (LWP 12999)]
0x0ff45200 in poll () from /lib/tls/libc.so.6
(gdb) thread apply all bt

Thread 7 (Thread 883107040 (LWP 13017)):
#0  0x0fc4901c in pthread_cond_wait@@GLIBC_2.3.2 ()
   from /lib/tls/libpthread.so.0
#1  0x0017d510 in e_msgport_wait (mp=0x101d4b90) at e-msgport.c:511
#2  0x0017dddc in thread_dispatch (din=0x4) at e-msgport.c:874
#3  0x0fc45998 in start_thread () from /lib/tls/libpthread.so.0
#4  0x0ff4ff08 in clone () from /lib/tls/libc.so.6

Thread 6 (Thread 872621280 (LWP 13016)):
#0  0x0ff47df8 in ___newselect_nocancel () from /lib/tls/libc.so.6
#1  0x309895b4 in camel_read (fd=47, buf=0x107d6210 "\n", n=4096)
    at camel-file-utils.c:419
#2  0x309d9e04 in stream_read (stream=0x105d0c38, buffer=0x107d6210 "\n",
    n=4096) at camel-stream-fs.c:223
#3  0x309db4f8 in camel_stream_read (stream=0x105d0c38,
    buffer=0x107d6210 "\n", n=4096) at camel-stream.c:97
#4  0x309b01a8 in folder_read (s=0x105d0c38) at camel-mime-parser.c:974
#5  0x309b1028 in folder_scan_step (s=0x1000, databuffer=0x0,
    datalength=0x105d0c38) at camel-mime-parser.c:1334
#6  0x309b1924 in camel_mime_parser_step (parser=0x1,
databuffer=0x34031b20,
    datalength=0x0) at camel-mime-parser.c:733
#7  0x309b328c in construct_from_parser (mime_part=0x105d0c38,
mp=0x107d6210)
---Type <return> to continue, or q <return> to quit---
    at camel-mime-part.c:788
#8  0x309ae5d0 in construct_from_parser (dw=0x1, mp=0x105c90f8)
    at camel-mime-message.c:461
#9  0x309b3444 in camel_mime_part_construct_from_parser
(mime_part=0x107d6210,
    mp=0x1000) at camel-mime-part.c:841
#10 0x309b34c8 in construct_from_stream (dw=0x105d0c38, s=0x107d6210)
    at camel-mime-part.c:857
#11 0x309839b0 in camel_data_wrapper_construct_from_stream (
    data_wrapper=0x105c90f8, stream=0x107d6210) at
camel-data-wrapper.c:265
#12 0x0e19e720 in get_message_simple (imap_folder=0x1, uid=0x34031b20 "",
    stream=0x105c90f8, ex=0x1000) at camel-imap-folder.c:1933
#13 0x0e1a0e2c in imap_get_message (folder=0x0, uid=0x0, ex=0x107d6210)
    at camel-imap-folder.c:1981
#14 0x3099a218 in camel_folder_get_message (folder=0x105c90f8,
    uid=0x107d6210 "\n", ex=0x105d0c38) at camel-folder.c:1101
#15 0x0e434c98 in get_message_get (mm=0x105d0c38) at mail-ops.c:1709
#16 0x0e42f7ec in mail_msg_received (e=0x1, msg=0x34031b20, data=0x0)
    at mail-mt.c:556
#17 0x0017dd70 in thread_dispatch (din=0x1) at e-msgport.c:826
#18 0x0fc45998 in start_thread () from /lib/tls/libpthread.so.0
#19 0x0ff4ff08 in clone () from /lib/tls/libc.so.6

Thread 5 (Thread 861926624 (LWP 13015)):
---Type <return> to continue, or q <return> to quit---
#0  0x0fc4901c in pthread_cond_wait@@GLIBC_2.3.2 ()
   from /lib/tls/libpthread.so.0
#1  0x0017d510 in e_msgport_wait (mp=0x101d4dd0) at e-msgport.c:511
#2  0x0017dddc in thread_dispatch (din=0x4) at e-msgport.c:874
#3  0x0fc45998 in start_thread () from /lib/tls/libpthread.so.0
#4  0x0ff4ff08 in clone () from /lib/tls/libc.so.6

Thread 4 (Thread 849675488 (LWP 13010)):
#0  0x0fc4901c in pthread_cond_wait@@GLIBC_2.3.2 ()
   from /lib/tls/libpthread.so.0
#1  0x0017d510 in e_msgport_wait (mp=0x101d4dd0) at e-msgport.c:511
#2  0x0017dddc in thread_dispatch (din=0x4) at e-msgport.c:874
#3  0x0fc45998 in start_thread () from /lib/tls/libpthread.so.0
#4  0x0ff4ff08 in clone () from /lib/tls/libc.so.6

Thread 3 (Thread 839189728 (LWP 13009)):
#0  0x0fc4901c in pthread_cond_wait@@GLIBC_2.3.2 ()
   from /lib/tls/libpthread.so.0
#1  0x0017d510 in e_msgport_wait (mp=0x101d4dd0) at e-msgport.c:511
#2  0x0017dddc in thread_dispatch (din=0x4) at e-msgport.c:874
#3  0x0fc45998 in start_thread () from /lib/tls/libpthread.so.0
#4  0x0ff4ff08 in clone () from /lib/tls/libc.so.6

---Type <return> to continue, or q <return> to quit---
Thread 2 (Thread 828703968 (LWP 13007)):
#0  0x0fc4901c in pthread_cond_wait@@GLIBC_2.3.2 ()
   from /lib/tls/libpthread.so.0
#1  0x0017d510 in e_msgport_wait (mp=0x101d4dd0) at e-msgport.c:511
 start_thread () from /lib/tls/libpthread.so.0
#4  0x0ff4ff08 in clone () from /lib/tls/libc.so.6

Thread 1 (Thread 810645280 (LWP 12999)):
#0  0x0ff45200 in poll () from /lib/tls/libc.so.6
#1  0x0ff451e8 in poll () from /lib/tls/libc.so.6
#2  0x0f81f704 in g_main_loop_run () from /usr/lib/libglib-2.0.so.0
#3  0x0ed16b6c in bonobo_main () from /usr/lib/libbonobo-2.so.0
#4  0x1001b00c in main (argc=260632928, argv=0x10186868) at main.c:585
(gdb)

Comment 3 David Woodhouse 2004-10-17 16:56:40 UTC

The thread which appears stuck is trying to read from fd 47, which
seems to be a local cache file:

shinybook /home/dwmw2 $ readlink /proc/13016/fd/47
/home/dwmw2/.evolution/mail/imap/dwmw2.org/folders/lists/subfolders/exim/19625.

I wonder if this is related to the new kernel and O_NONBLOCK on
regular files?

Comment 4 David Woodhouse 2004-10-17 18:44:44 UTC

Works fine on older kernels. Marking as duplicate of bug 135942

*** This bug has been marked as a duplicate of 135942 ***

Comment 5 Red Hat Bugzilla 2006-02-21 19:06:23 UTC

Changed to 'CLOSED' state since 'RESOLVED' has been deprecated.