After an evaluation, GNOME has moved from Bugzilla to GitLab. Learn more about GitLab.
No new issues can be reported in GNOME Bugzilla anymore.
To report an issue in a GNOME project, go to GNOME GitLab.
Do not go to GNOME Gitlab for: Bluefish, Doxygen, GnuCash, GStreamer, java-gnome, LDTP, NetworkManager, Tomboy.
Bug 581720 - "Updating Search Folders for 'On This Computer:/anything (...)" forever
"Updating Search Folders for 'On This Computer:/anything (...)" forever
Status: RESOLVED DUPLICATE of bug 579360
Product: evolution
Classification: Applications
Component: Mailer
2.26.x (obsolete)
Other All
: Normal major
: ---
Assigned To: evolution-mail-maintainers
Evolution QA team
evolution[disk-summary]
Depends on:
Blocks: 543389
 
 
Reported: 2009-05-07 10:20 UTC by Stanislav Brabec
Modified: 2009-05-12 13:46 UTC
See Also:
GNOME target: ---
GNOME version: 2.25/2.26


Description Stanislav Brabec 2009-05-07 10:20:35 UTC 
Please describe the problem:
Nearly every time I start evolution, evolution, it goes into a sttange state displaying "Updating Search Folders for 'On This Computer:/anything (...)" forever.

Steps to reproduce:
1. Start evolution mailer


Actual results:
It goes into a stuck state:

- Displays "Updating Search Folders for 'On This Computer:/anything (...)" in the status line.

- The name of the folder varies

- The rest of the mailer works, except:

- Expunge does not work.

- Moving mails across accounts seems to not work.

- It's impossible to quit.

Expected results:
Finish the update search folders update.

Does this happen every time?
With ~90% probability it happens after each evolution start.

Other information:
evolution-2.26.1.1, volution-data-server-2.26.1.1, openSUSE Factory (aka 11.2 Milestone 1) x86_64.
Comment 1 Srinivasa Ragavan 2009-05-08 04:29:25 UTC 
Stanislav,

Can you attach to gdb, and get 'thread apply all bt' logs?
Comment 2 Stanislav Brabec 2009-05-11 13:44:12 UTC 
Dump while evolution was running and working, but probably dead "Updating Search Folders for 'utx@penguin.cz:/mail/lkml' (...)" was running.

+ Trace 215332

Thread 4 (Thread 0x7ffd4bf75950 (LWP 13814))

  • #0 __lll_lock_wait
    at ../nptl/sysdeps/unix/sysv/linux/x86_64/lowlevellock.S line 130
  • #1 _L_lock_102
    from /lib64/libpthread.so.0
  • #2 __pthread_mutex_lock
    at pthread_mutex_lock.c line 86
  • #3 ??
    from /usr/lib64/libcamel-provider-1.2.so.14
  • #4 ??
    from /usr/lib64/evolution/2.26/components/libevolution-mail.so
  • #5 ??
    from /usr/lib64/evolution/2.26/components/libevolution-mail.so
  • #6 g_thread_pool_thread_proxy
    at gthreadpool.c line 265
  • #7 g_thread_create_proxy
    at gthread.c line 635
  • #8 start_thread
    at pthread_create.c line 297
  • #9 clone
    from /lib64/libc.so.6
  • #10 ??

Thread 3 (Thread 0x7ffd47ecd950 (LWP 13839))

  • #0 __lll_lock_wait
    at ../nptl/sysdeps/unix/sysv/linux/x86_64/lowlevellock.S line 130
  • #1 _L_lock_102
    from /lib64/libpthread.so.0
  • #2 __pthread_mutex_lock
    at pthread_mutex_lock.c line 86
  • #3 camel_db_begin_transaction
    from /usr/lib64/libcamel-1.2.so.14
  • #4 camel_db_delete_uid
    from /usr/lib64/libcamel-1.2.so.14
  • #5 camel_folder_summary_remove
    from /usr/lib64/libcamel-provider-1.2.so.14
  • #6 ??
    from /usr/lib64/libcamel-provider-1.2.so.14
  • #7 ??
    from /usr/lib64/libcamel-provider-1.2.so.14
  • #8 ??
    from /usr/lib64/libcamel-provider-1.2.so.14
  • #9 g_thread_pool_thread_proxy
    at gthreadpool.c line 265
  • #10 g_thread_create_proxy
    at gthread.c line 635
  • #11 start_thread
    at pthread_create.c line 297
  • #12 clone
    from /lib64/libc.so.6
  • #13 ?? 






Comment 3


Srinivasa Ragavan





          2009-05-11 17:31:13 UTC
        



Hmm, this is fixed in stable and would be part of 2.26.2.

I dont remember the bug id. Akhil, which is the bug id for the vfolder hang, which I fixed and you posted the patch?






Comment 4


Akhil Laddha





          2009-05-12 03:28:41 UTC
        



bug 579360 ?






Comment 5


Stanislav Brabec





          2009-05-12 11:33:24 UTC
        



Yes, it looks so - the patch fixed the hang.

However "Updating Search Folders" is still a very slow operation.

Evolution needs 260 seconds of 100% CPU activity to finish its start - 10 seconds from clicking to icon to finishing new mail scanning and 250 seconds for "Updating Search Folders". It scans all folders, even if no change happened there for a long time. Especially scanning of local folders seems to be slow.

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






Comment 6


Srinivasa Ragavan





          2009-05-12 12:29:00 UTC
        



Stanislav, run http://www.gnome.org/~sragavan/evolution-rebuild-summarydb is once. It will speed up a lot. Im still finding some time to make it all automatic through Evolution. 






Comment 7


Stanislav Brabec





          2009-05-12 13:46:22 UTC
        



I just tried evolution-rebuild-summarydb. I see about 2% improvement, "Updating Search Folders" now requires about 245 seconds.