Re: [Evolution] Accessing IMAP folder puts Evo into endless loop
On 23 Jun 2001 21:52:57 -0600, Dan Hensley wrote: > Hi, > I just got back after about 6 weeks of traveling and updated > Evolution from CVS. When I try to access my IMAP folder, Evo just goes > into full CPU usage and never comes back. > Also, I find the progress bar for IMAP folders to be extremely > annoying. They always appear right over the top of the password entry > dialog, usually when I'm about halfway through typing in my password. I > have to switch focus and start over. Would it be possible to display > messages like this at the bottom of the main window, or anywhere else > that's not a separate window? We all hate how it currently works, we will be working to move it to a much nicer place in the (hopefully) near future. Jeff > > Dan > > > > ___ > evolution maillist - [EMAIL PROTECTED] > http://lists.ximian.com/mailman/listinfo/evolution ___ evolution maillist - [EMAIL PROTECTED] http://lists.ximian.com/mailman/listinfo/evolution
Re: [Evolution] Accessing IMAP folder puts Evo into endless loop
> Also, I find the progress bar for IMAP folders to be extremely > annoying. I wrote new interfaces in the shell so that we can display updates in the bottom status bar. The mailer will be changed to use them. -- Ettore ___ evolution maillist - [EMAIL PROTECTED] http://lists.ximian.com/mailman/listinfo/evolution
Re: [Evolution] Accessing IMAP folder puts Evo into endless loop
I sent this out several days ago but still haven't seen a response, and
the problem still exists. When I click on the Inbox of my IMAP folder,
Evolution goes into an endless loop that uses 100% CPU and never comes
back. Here's the last bit out output from evolution-mail, which
probably doesn't help much. I doctored it up a bit to protect my
privacy.
sending : A00010 UID FETCH 5128 BODY.PEEK[HEADER]
received: * 11 FETCH (UID 5128 BODY[HEADER] {989}
received: )
received: A00010 OK UID FETCH completed
sending : A00011 UID FETCH 5162 BODY.PEEK[HEADER]
received: * 12 FETCH (UID 5162 BODY[HEADER] {703}
received: )
received: A00011 OK UID FETCH completed
got folder 'imap:[EMAIL PROTECTED]/INBOX' = 0x81f8ab8
folder name is 'IMAPv4 server mail.xxx.com'
Dan
On 23 Jun 2001 21:52:57 -0600, Dan Hensley wrote:
> Hi,
> I just got back after about 6 weeks of traveling and updated
> Evolution from CVS. When I try to access my IMAP folder, Evo just goes
> into full CPU usage and never comes back.
> Also, I find the progress bar for IMAP folders to be extremely
> annoying. They always appear right over the top of the password entry
> dialog, usually when I'm about halfway through typing in my password. I
> have to switch focus and start over. Would it be possible to display
> messages like this at the bottom of the main window, or anywhere else
> that's not a separate window?
>
> Dan
>
>
>
> ___
> evolution maillist - [EMAIL PROTECTED]
> http://lists.ximian.com/mailman/listinfo/evolution
___
evolution maillist - [EMAIL PROTECTED]
http://lists.ximian.com/mailman/listinfo/evolution
Re: [Evolution] Accessing IMAP folder puts Evo into endless loop
Hi Dan, On 26 Jun 2001 22:36:50 -0600, Dan Hensley wrote: > I sent this out several days ago but still haven't seen a response, and > the problem still exists. When I click on the Inbox of my IMAP folder, > Evolution goes into an endless loop that uses 100% CPU and never comes > back. Here's the last bit out output from evolution-mail, which > probably doesn't help much. I doctored it up a bit to protect my > privacy. > Can you please: 1) Open up 2 terminals 2) Run 'gdb evolution-mail' in one terminal and 'run' it 3) Wait five seconds 4) Run 'evolution' in the other terminal 5) Cause the infinite loop 6) Press ^C in the gdb 7) Get a backtrace with 'bt' ? That would be helpful. Thanks, Peter ___ evolution maillist - [EMAIL PROTECTED] http://lists.ximian.com/mailman/listinfo/evolution
Re: [Evolution] Accessing IMAP folder puts Evo into endless loop
Ok, here is what I get. To reproduce for me is extremely easy and 100% repeatable: 1. Click on IMAP folder root 2. Enter password 3. Click on Inbox Here's the last bit of output and a backtrace when I do this: utf8_to_gtk: Body or subject contains => Body or subject contains utf8_to_gtk: Body contains => Body contains utf8_to_gtk: Subject contains => Subject contains utf8_to_gtk: Body does not contain => Body does not contain utf8_to_gtk: Subject does not contain => Subject does not contain utf8_to_gtk: Sender contains => Sender contains utf8_to_gtk: Advanced... => Advanced... utf8_to_gtk: Show All => Show All utf8_to_gtk: Save As... => Save As... utf8_to_gtk: Store search as vFolder => Store search as vFolder utf8_to_gtk: Edit... => Edit... sending : A6 SELECT "INBOX" Bonobo-CRITICAL **: file bonobo-ui-component.c: line 829 (impl_xml_rm): assertion `container != CORBA_OBJECT_NIL' failed. Bonobo-CRITICAL **: file bonobo-ui-component.c: line 829 (impl_xml_rm): assertion `container != CORBA_OBJECT_NIL' failed. received: * NO Trying to get mailbox lock from process 13442 received: * 12 EXISTS received: * NO Mailbox vulnerable - directory must have 1777 protection received: * 0 RECENT received: * OK [UIDVALIDITY 957803161] UID validity status received: * OK [UIDNEXT 5171] Predicted next UID received: * FLAGS (\Answered \Flagged \Deleted \Draft \Seen) received: * OK [PERMANENTFLAGS (\* \Answered \Flagged \Deleted \Draft \Seen)] Permanent flags received: A6 OK [READ-WRITE] SELECT completed sending : A7 UID FETCH 1:5162 (FLAGS) received: * 1 FETCH (UID 2263 FLAGS (\Seen \Answered)) received: * 2 FETCH (UID 3542 FLAGS (\Seen)) received: * 3 FETCH (UID 3616 FLAGS (\Seen \Answered)) received: * 4 FETCH (UID 4295 FLAGS (\Seen \Answered)) received: * 5 FETCH (UID 4307 FLAGS (\Seen)) received: * 6 FETCH (UID 4842 FLAGS (\Seen)) received: * 7 FETCH (UID 4870 FLAGS (\Seen \Answered)) received: * 8 FETCH (UID 4871 FLAGS (\Seen \Answered)) received: * 9 FETCH (UID 4877 FLAGS (\Seen \Answered)) received: * 10 FETCH (UID 5119 FLAGS (\Seen)) received: * 11 FETCH (UID 5128 FLAGS (\Seen)) received: A7 OK UID FETCH completed got folder 'imap:[EMAIL PROTECTED]/INBOX' = 0x8215d18 Received Interrupt in LWP 6359 while waiting for SIGSTOP. Received Interrupt in LWP 6312 while waiting for SIGSTOP. Program received signal SIGINT, Interrupt. [Switching to Thread 3076 (LWP 6361)] 0x40a53362 in sigsuspend () from /lib/libc.so.6 (gdb) bt #0 0x40a53362 in sigsuspend () from /lib/libc.so.6 #1 0x406d7bc0 in __pthread_wait_for_restart_signal (self=0xbf3ffc00) at pthread.c:934 #2 0x406d3e8c in pthread_cond_wait (cond=0x811b588, mutex=0x811b568) at restart.h:34 #3 0x40069527 in e_msgport_wait (mp=0x811b540) at e-msgport.c:193 #4 0x40069c9f in thread_dispatch (din=0x811b4f0) at e-msgport.c:514 #5 0x406d4f54 in pthread_start_thread_event (arg=0xbf3ffc00) at manager.c:262 I don't know if this backtrace helps. Do I need to get the other threads as well? Dan On 27 Jun 2001 01:13:42 -0400, Peter Williams wrote: > Hi Dan, > > On 26 Jun 2001 22:36:50 -0600, Dan Hensley wrote: > > I sent this out several days ago but still haven't seen a response, and > > the problem still exists. When I click on the Inbox of my IMAP folder, > > Evolution goes into an endless loop that uses 100% CPU and never comes > > back. Here's the last bit out output from evolution-mail, which > > probably doesn't help much. I doctored it up a bit to protect my > > privacy. > > > > Can you please: > > 1) Open up 2 terminals > 2) Run 'gdb evolution-mail' in one terminal and 'run' it > 3) Wait five seconds > 4) Run 'evolution' in the other terminal > 5) Cause the infinite loop > 6) Press ^C in the gdb > 7) Get a backtrace with 'bt' > > ? That would be helpful. > > Thanks, > Peter > > ___ evolution maillist - [EMAIL PROTECTED] http://lists.ximian.com/mailman/listinfo/evolution
Re: [Evolution] Accessing IMAP folder puts Evo into endless loop
Hi Dan, On 27 Jun 2001 09:26:52 -0600, Dan Hensley wrote: > > I don't know if this backtrace helps. Do I need to get the other > threads as well? > > Dan Right, yes, the other threads. Can you do this? Thanks, Peter -- Peter Williams [EMAIL PROTECTED] / [EMAIL PROTECTED] "Why should I have to change my name? He's the one who sucks!" -- Michael Bolton ___ evolution maillist - [EMAIL PROTECTED] http://lists.ximian.com/mailman/listinfo/evolution
Re: [Evolution] Accessing IMAP folder puts Evo into endless loop
We'll need the bt's for the other threads as well Jeff On 27 Jun 2001 09:26:52 -0600, Dan Hensley wrote: > Ok, here is what I get. To reproduce for me is extremely easy and 100% > repeatable: > 1. Click on IMAP folder root > 2. Enter password > 3. Click on Inbox > > Here's the last bit of output and a backtrace when I do this: > > > utf8_to_gtk: Body or subject contains => Body or subject contains > utf8_to_gtk: Body contains => Body contains > utf8_to_gtk: Subject contains => Subject contains > utf8_to_gtk: Body does not contain => Body does not contain > utf8_to_gtk: Subject does not contain => Subject does not contain > utf8_to_gtk: Sender contains => Sender contains > utf8_to_gtk: Advanced... => Advanced... > utf8_to_gtk: Show All => Show All > utf8_to_gtk: Save As... => Save As... > utf8_to_gtk: Store search as vFolder => Store search as vFolder > utf8_to_gtk: Edit... => Edit... > sending : A6 SELECT "INBOX" > > Bonobo-CRITICAL **: file bonobo-ui-component.c: line 829 (impl_xml_rm): > assertion `container != CORBA_OBJECT_NIL' failed. > > Bonobo-CRITICAL **: file bonobo-ui-component.c: line 829 (impl_xml_rm): > assertion `container != CORBA_OBJECT_NIL' failed. > received: * NO Trying to get mailbox lock from process 13442 > received: * 12 EXISTS > received: * NO Mailbox vulnerable - directory must have 1777 protection > received: * 0 RECENT > received: * OK [UIDVALIDITY 957803161] UID validity status > received: * OK [UIDNEXT 5171] Predicted next UID > received: * FLAGS (\Answered \Flagged \Deleted \Draft \Seen) > received: * OK [PERMANENTFLAGS (\* \Answered \Flagged \Deleted \Draft > \Seen)] Permanent flags > received: A6 OK [READ-WRITE] SELECT completed > sending : A7 UID FETCH 1:5162 (FLAGS) > received: * 1 FETCH (UID 2263 FLAGS (\Seen \Answered)) > received: * 2 FETCH (UID 3542 FLAGS (\Seen)) > received: * 3 FETCH (UID 3616 FLAGS (\Seen \Answered)) > received: * 4 FETCH (UID 4295 FLAGS (\Seen \Answered)) > received: * 5 FETCH (UID 4307 FLAGS (\Seen)) > received: * 6 FETCH (UID 4842 FLAGS (\Seen)) > received: * 7 FETCH (UID 4870 FLAGS (\Seen \Answered)) > received: * 8 FETCH (UID 4871 FLAGS (\Seen \Answered)) > received: * 9 FETCH (UID 4877 FLAGS (\Seen \Answered)) > received: * 10 FETCH (UID 5119 FLAGS (\Seen)) > received: * 11 FETCH (UID 5128 FLAGS (\Seen)) > received: A7 OK UID FETCH completed > got folder 'imap:[EMAIL PROTECTED]/INBOX' = 0x8215d18 > Received Interrupt in LWP 6359 while waiting for SIGSTOP. > Received Interrupt in LWP 6312 while waiting for SIGSTOP. > > Program received signal SIGINT, Interrupt. > [Switching to Thread 3076 (LWP 6361)] > 0x40a53362 in sigsuspend () from /lib/libc.so.6 > (gdb) bt > #0 0x40a53362 in sigsuspend () from /lib/libc.so.6 > #1 0x406d7bc0 in __pthread_wait_for_restart_signal (self=0xbf3ffc00) > at pthread.c:934 > #2 0x406d3e8c in pthread_cond_wait (cond=0x811b588, mutex=0x811b568) > at restart.h:34 > #3 0x40069527 in e_msgport_wait (mp=0x811b540) at e-msgport.c:193 > #4 0x40069c9f in thread_dispatch (din=0x811b4f0) at e-msgport.c:514 > #5 0x406d4f54 in pthread_start_thread_event (arg=0xbf3ffc00) at > manager.c:262 > > > I don't know if this backtrace helps. Do I need to get the other > threads as well? > > Dan > > > > > On 27 Jun 2001 01:13:42 -0400, Peter Williams wrote: > > Hi Dan, > > > > On 26 Jun 2001 22:36:50 -0600, Dan Hensley wrote: > > > I sent this out several days ago but still haven't seen a response, and > > > the problem still exists. When I click on the Inbox of my IMAP folder, > > > Evolution goes into an endless loop that uses 100% CPU and never comes > > > back. Here's the last bit out output from evolution-mail, which > > > probably doesn't help much. I doctored it up a bit to protect my > > > privacy. > > > > > > > Can you please: > > > > 1) Open up 2 terminals > > 2) Run 'gdb evolution-mail' in one terminal and 'run' it > > 3) Wait five seconds > > 4) Run 'evolution' in the other terminal > > 5) Cause the infinite loop > > 6) Press ^C in the gdb > > 7) Get a backtrace with 'bt' > > > > ? That would be helpful. > > > > Thanks, > > Peter > > > > > > > > ___ > evolution maillist - [EMAIL PROTECTED] > http://lists.ximian.com/mailman/listinfo/evolution ___ evolution maillist - [EMAIL PROTECTED] http://lists.ximian.com/mailman/listinfo/evolution
Re: [Evolution] Accessing IMAP folder puts Evo into endless loop
On 27 Jun 2001 11:46:57 -0400, Peter Williams wrote: > Hi Dan, > > On 27 Jun 2001 09:26:52 -0600, Dan Hensley wrote: > > > > I don't know if this backtrace helps. Do I need to get the other > > threads as well? > > > > Dan > > Right, yes, the other threads. Can you do this? Here you go. Let me know if you need anything else... utf8_to_gtk: Body or subject contains => Body or subject contains utf8_to_gtk: Body contains => Body contains utf8_to_gtk: Subject contains => Subject contains utf8_to_gtk: Body does not contain => Body does not contain utf8_to_gtk: Subject does not contain => Subject does not contain utf8_to_gtk: Sender contains => Sender contains utf8_to_gtk: Advanced... => Advanced... utf8_to_gtk: Show All => Show All utf8_to_gtk: Save As... => Save As... utf8_to_gtk: Store search as vFolder => Store search as vFolder utf8_to_gtk: Edit... => Edit... sending : A6 SELECT "INBOX" Bonobo-CRITICAL **: file bonobo-ui-component.c: line 829 (impl_xml_rm): assertion `container != CORBA_OBJECT_NIL' failed. Bonobo-CRITICAL **: file bonobo-ui-component.c: line 829 (impl_xml_rm): assertion `container != CORBA_OBJECT_NIL' failed. received: * 12 EXISTS received: * NO Mailbox vulnerable - directory must have 1777 protection received: * 0 RECENT received: * OK [UIDVALIDITY 957803161] UID validity status received: * OK [UIDNEXT 5171] Predicted next UID received: * FLAGS (\Answered \Flagged \Deleted \Draft \Seen) received: * OK [PERMANENTFLAGS (\* \Answered \Flagged \Deleted \Draft \Seen)] Permanent flags received: A6 OK [READ-WRITE] SELECT completed sending : A7 UID FETCH 1:5162 (FLAGS) received: * 1 FETCH (UID 2263 FLAGS (\Seen \Answered)) received: * 2 FETCH (UID 3542 FLAGS (\Seen)) received: * 3 FETCH (UID 3616 FLAGS (\Seen \Answered)) received: * 4 FETCH (UID 4295 FLAGS (\Seen \Answered)) received: * 5 FETCH (UID 4307 FLAGS (\Seen)) received: * 6 FETCH (UID 4842 FLAGS (\Seen)) received: * 7 FETCH (UID 4870 FLAGS (\Seen \Answered)) received: * 8 FETCH (UID 4871 FLAGS (\Seen \Answered)) received: * 9 FETCH (UID 4877 FLAGS (\Seen \Answered)) received: * 10 FETCH (UID 5119 FLAGS (\Seen)) received: * 11 FETCH (UID 5128 FLAGS (\Seen)) received: A7 OK UID FETCH completed got folder 'imap:[EMAIL PROTECTED]/INBOX' = 0x821b038 Received Interrupt in LWP 6726 while waiting for SIGSTOP. Received Interrupt in LWP 4479 while waiting for SIGSTOP. Program received signal SIGINT, Interrupt. [Switching to Thread 3076 (LWP 7024)] 0x40a53362 in sigsuspend () from /lib/libc.so.6 (gdb) bt #0 0x40a53362 in sigsuspend () from /lib/libc.so.6 #1 0x406d7bc0 in __pthread_wait_for_restart_signal (self=0xbf3ffc00) at pthread.c:934 #2 0x406d3e8c in pthread_cond_wait (cond=0x811b588, mutex=0x811b568) at restart.h:34 #3 0x40069527 in e_msgport_wait (mp=0x811b540) at e-msgport.c:193 #4 0x40069c9f in thread_dispatch (din=0x811b4f0) at e-msgport.c:514 #5 0x406d4f54 in pthread_start_thread_event (arg=0xbf3ffc00) at manager.c:262 (gdb) thread 1 [Switching to thread 1 (Thread 1024 (LWP 4479))]#0 0x40b055ee in select () from /lib/libc.so.6 (gdb) bt #0 0x40b055ee in select () from /lib/libc.so.6 #1 0x409974fc in __DTOR_END__ () from /usr/local/lib/libIIOP.so.0 #2 0x4098f460 in giop_main_next_message_2 (blocking=1, monitor=0x811f4e8) at connection.c:1174 #3 0x40990a8c in giop_recv_reply_buffer_use_multiple_2 ( request_cnx=0x811f4e8, request_ids=0xb238, block_for_reply=1) at giop-msg-buffer.c:1013 #4 0x40990bb3 in giop_recv_reply_buffer_use_2 (request_cnx=0x811f4e8, request_id=3221222016, block_for_reply=1) at giop-msg-buffer.c:1062 #5 0x407ef442 in GNOME_Evolution_StorageListener_notifyFolderUpdated ( _obj=0x8130588, path=0x82103c0 "/INBOX", display_name=0x822d800 "INBOX (1)", highlighted=1 '\001', ev=0xb2e0) at Evolution-stubs.c:5942 #6 0x407f9e1d in evolution_storage_update_folder ( evolution_storage=0x812fe50, path=0x82103c0 "/INBOX", display_name=0x822d800 "INBOX (1)", highlighted=1) at evolution-storage.c:825 #7 0x407f9f7e in evolution_storage_update_folder_by_uri ( evolution_storage=0x812fe50, physical_uri=0x822d7c8 "imap:[EMAIL PROTECTED]/INBOX", display_name=0x822d800 "INBOX (1)", highlighted=1) at evolution-storage.c:873 #8 0x0806c1f8 in update_unread_count_main (object=0x821b038, event_data=0x0, user_data=0x8210b80) at folder-browser.c:208 ---Type to continue, or q to quit--- #9 0x0806cff1 in got_folder ( uri=0x8219f28 "imap:[EMAIL PROTECTED]/INBOX", folder=0x821b038, data=0x8210b80) at folder-browser.c:671 #10 0x080887ce in get_folder_got (mm=0x8219eb8) at mail-ops.c:1243 #11 0x08085350 in mail_msgport_replied (source=0x811b438, cond=G_IO_IN, d=0x811b3e0) at mail-mt.c:266 #12 0x40592bd4 in g_io_unix_dispatch (source_data=0x811b450, current_time=0xb490, user_data=0x811b3e0) at giounix.c:137 #13 0x40594390 in g_main_dispatch (dispatch_time=0xb490) at gmain.c:656 #14 0x4059496f in g_
Re: [Evolution] Accessing IMAP folder puts Evo into endless loop
Hi Dan, On 27 Jun 2001 10:01:51 -0600, Dan Hensley wrote: > Here you go. Let me know if you need anything else... > Aha. Somehow evolution-mail is getting stuck while trying to communicate with the shell. Usually this means either the shell is crashing or it is locking somewhere. It'd be obvious if it were crashing so I guess the shell is the actual culprit. If you don't mind getting /another/ backtrace, one from the evolution executable would be helpful... Thanks, Peter -- Peter Williams [EMAIL PROTECTED] / [EMAIL PROTECTED] "Why should I have to change my name? He's the one who sucks!" -- Michael Bolton ___ evolution maillist - [EMAIL PROTECTED] http://lists.ximian.com/mailman/listinfo/evolution
Re: [Evolution] Accessing IMAP folder puts Evo into endless loop
On 27 Jun 2001 12:49:11 -0400, Peter Williams wrote: > Hi Dan, > > On 27 Jun 2001 10:01:51 -0600, Dan Hensley wrote: > > Here you go. Let me know if you need anything else... > > > > Aha. Somehow evolution-mail is getting stuck while trying to communicate > with the shell. Usually this means either the shell is crashing or it is > locking somewhere. It'd be obvious if it were crashing so I guess the > shell is the actual culprit. If you don't mind getting /another/ > backtrace, one from the evolution executable would be helpful... Well that was interesting. It looks like the shell _is_ crashing. Here's a backtrace from evolution: utf8_to_gtk: INBOX (1) => INBOX (1) utf8_to_gtk: INBOX (1) => INBOX (1) Program received signal SIGSEGV, Segmentation fault. [Switching to Thread 1024 (LWP 19225)] 0x408f52cc in free () from /lib/libc.so.6 (gdb) (gdb) (gdb) (gdb) bt #0 0x408f52cc in free () from /lib/libc.so.6 #1 0x40575621 in g_free (mem=0x31) at gmem.c:411 #2 0x4010546d in e_shortcut_model_real_update_item (shortcut_model=0x80f0340, group_num=1, item_num=4, item_url=0x80f27e8 "evolution:/XXX/INBOX", item_name=0x81600d0 "INBOX (2)") at e-shortcut-model.c:458 #3 0x40105624 in e_shortcut_model_marshal2 (object=0x80f0340, func=0x401052f0 , func_data=0x0, args=0xbfffe0d0) at e-shortcut-model.c:504 #4 0x404bfb32 in gtk_signal_real_emit (object=0x80f0340, signal_id=154, params=0xbfffe0d0) at gtksignal.c:1440 #5 0x404bdae0 in gtk_signal_emit (object=0x80f0340, signal_id=154) at gtksignal.c:552 #6 0x401055cc in e_shortcut_model_update_item (shortcut_model=0x80f0340, group_num=1, item_num=4, item_url=0x80f27e8 "evolution:/XXX/INBOX", item_name=0x81600d0 "INBOX (2)") at e-shortcut-model.c:477 #7 0x0806890c in shortcuts_update_shortcut_cb (shortcuts=0x80d38a0, group_num=1, item_num=4, data=0x80f0340) at e-shortcuts-view-model.c:238 #8 0x4048dcdb in gtk_marshal_NONE__INT_INT (object=0x80d38a0, func=0x8068850 , func_data=0x80f0340, args=0xbfffe4e0) at gtkmarshal.c:284 #9 0x404c0946 in gtk_handlers_run (handlers=0x808b148, signal=0xbfffe480, ---Type to continue, or q to quit--- object=0x80d38a0, params=0xbfffe4e0, after=0) at gtksignal.c:1917 #10 0x404bfca6 in gtk_signal_real_emit (object=0x80d38a0, signal_id=121, params=0xbfffe4e0) at gtksignal.c:1477 #11 0x404bdae0 in gtk_signal_emit (object=0x80d38a0, signal_id=121) at gtksignal.c:552 #12 0x0806aee9 in e_shortcuts_update_shortcut_by_uri (shortcuts=0x80d38a0, uri=0x81bf828 "evolution:/XXX/INBOX") at e-shortcuts.c:838 #13 0x08063a8d in updated_folder_cb (storage_set=0x80cd508, path=0x814b198 "/XXX/INBOX", data=0x80f2fd8) at e-shell-view.c:1116 #14 0x4048dbf8 in gtk_marshal_NONE__POINTER (object=0x80cd508, func=0x8063a40 , func_data=0x80f2fd8, args=0xbfffe8d0) at gtkmarshal.c:193 #15 0x404c0946 in gtk_handlers_run (handlers=0x808b468, signal=0xbfffe870, object=0x80cd508, params=0xbfffe8d0, after=0) at gtksignal.c:1917 #16 0x404bfca6 in gtk_signal_real_emit (object=0x80cd508, signal_id=109, params=0xbfffe8d0) at gtksignal.c:1477 #17 0x404bdae0 in gtk_signal_emit (object=0x80cd508, signal_id=109) at gtksignal.c:552 #18 0x0806ee5f in storage_updated_folder_cb (storage=0x80f43d0, path=0x8180180 "/INBOX", data=0x80cd508) at e-storage-set.c:193 #19 0x4048dbf8 in gtk_marshal_NONE__POINTER (object=0x80f43d0, func=0x806ee00 , func_data=0x80cd508, ---Type to continue, or q to quit--- args=0xbfffec90) at gtkmarshal.c:193 #20 0x404c0946 in gtk_handlers_run (handlers=0x808b868, signal=0xbfffec30, object=0x80f43d0, params=0xbfffec90, after=0) at gtksignal.c:1917 #21 0x404bfca6 in gtk_signal_real_emit (object=0x80f43d0, signal_id=112, params=0xbfffec90) at gtksignal.c:1477 #22 0x404bdae0 in gtk_signal_emit (object=0x80f43d0, signal_id=112) at gtksignal.c:552 #23 0x080701cd in folder_changed_cb (folder=0x81b3cd8, data=0x80f43d0) at e-storage.c:106 #24 0x4048dd21 in gtk_marshal_NONE__NONE (object=0x81b3cd8, func=0x80700f0 , func_data=0x80f43d0, args=0xb050) at gtkmarshal.c:312 #25 0x404c0946 in gtk_handlers_run (handlers=0x81bca60, signal=0xbfffeff0, object=0x81b3cd8, params=0xb050, after=0) at gtksignal.c:1917 #26 0x404bfca6 in gtk_signal_real_emit (object=0x81b3cd8, signal_id=97, params=0xb050) at gtksignal.c:1477 #27 0x404bdae0 in gtk_signal_emit (object=0x81b3cd8, signal_id=97) at gtksignal.c:552 #28 0x080566ab in impl_StorageListener_update_folder (servant=0x80f4540, path=0x81c03f4 "/INBOX", display_name=0x81c0400 "INBOX (2)", highlighted=1 '\001', ev=0xb390) at e-corba-storage.c:151 #29 0x40025fcd in _ORBIT_skel_GNOME_Evolution_StorageListener_notifyFolderUpdated (_ORBIT_servant=0x80f4540, _ORBIT_recv_buffer=0x80c6548, ev=0xb390, ---Type to continue, or q to quit--- _impl_notifyFolderUpdated=0x8056650 ) at Evolution-skels.c:35
