Bug 136075 - IMAP stops working.
IMAP stops working.
Status: CLOSED DUPLICATE of bug 135942
Product: Fedora
Classification: Fedora
Component: evolution (Show other bugs)
rawhide
All Linux
medium Severity high
: ---
: ---
Assigned To: Dave Malcolm
:
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2004-10-17 12:26 EDT by David Woodhouse
Modified: 2007-11-30 17:10 EST (History)
0 users

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2006-02-21 14:06:23 EST
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)
Output with CAMEL_VERBOSE_DEBUG=1 (233.47 KB, text/plain)
2004-10-17 12:27 EDT, David Woodhouse
no flags Details

  None (edit)
Description David Woodhouse 2004-10-17 12:26:47 EDT
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 12:27:42 EDT
Created attachment 105351 [details]
Output with CAMEL_VERBOSE_DEBUG=1
Comment 2 David Woodhouse 2004-10-17 12:50:55 EDT
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 12:56:40 EDT
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@pentafluge.infradead.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 14:44:44 EDT
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 14:06:23 EST
Changed to 'CLOSED' state since 'RESOLVED' has been deprecated.

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