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 581090 - Indefinite and Extreme GConf Activity While Closing
Indefinite and Extreme GConf Activity While Closing
Status: RESOLVED DUPLICATE of bug 579360
Product: evolution
Classification: Applications
Component: Mailer
2.26.x (obsolete)
Other Linux
: High critical
: ---
Assigned To: evolution-mail-maintainers
Evolution QA team
evolution[vfolders]
Depends on:
Blocks:
 
 
Reported: 2009-05-02 12:17 UTC by Sam Morris
Modified: 2009-05-05 12:01 UTC
See Also:
GNOME target: ---
GNOME version: ---


Attachments
requested stack trace for Evolution bug (313.40 KB, application/octet-stream)
2009-05-04 17:00 UTC, Paul Menzel
Details
gdb thread apply all backtrace full (52.32 KB, application/octet-stream)
2009-05-04 20:11 UTC, Paul Menzel
Details

Description Sam Morris 2009-05-02 12:17:13 UTC
When Evolution is closed by clicking the window's close button, the window
and all elemets gray out and a constant disk IO activity of several MB per
second goes on. Investigations have shown that GConf is writing its config
file /home/hansi/.gconf/%gconf-tree.xml.new over and over again.

Forwarded from <http://bugs.debian.org/526217>.
Comment 1 Matthew Barnes 2009-05-02 14:58:22 UTC
Can you try to get a stack trace for this?
Comment 2 Yves-Alexis Perez 2009-05-04 06:18:31 UTC
It might be related to vfolder, disabling them seems to fix the problem.
Comment 3 Matthew Barnes 2009-05-04 12:29:28 UTC
Sounds like possibly a circular notification loop, where something detects a change in GConf and the reaction triggers another write to GConf.  But it's speculation until we have a stack trace.  Not seeing this myself at all...
Comment 4 Paul Menzel 2009-05-04 17:00:40 UTC
Created attachment 133934 [details]
requested stack trace for Evolution bug

I created the stack trace with the following command.

strace -o/tmp/20090504--gnome-bts--581090--evolution.strace evolution

It is 30 MB big, so I just send the last lines.

The search folder message at the bottom was displayed already short time after start. In the end I hit Ctrl + q to quit and then after a while Ctrl + c.

Please tell me, if there are any passwords stored in the trace, so I can react if it should be the case.
Comment 5 Sam Morris 2009-05-04 17:10:56 UTC
Paul, that's not quite the stack trace we need.

You can get the stack trace by installing evolution-dbg & evolution-data-server-dbg; then running 'gdb -p <pid of evolution>' (you can find out the pid by running 'pgrep -l evolution').

Once you get evolution into the state where it writes all these files, hit ctrl+c in the gdb window; this should pause evolution and drop you to a gdb prompt. From there, you can enter 'thread all apply backtrace full' to get the stack trace.
Comment 6 Paul Menzel 2009-05-04 20:11:00 UTC
Created attachment 133956 [details]
gdb thread apply all backtrace full

Thank you Sam. (Other readers just switch all and apply so the command looks like this.

thread apply all backtrace full

I hope this is better for analysation. The first problem seems to be something different.

“Fenstermanager-Warnung:Attempt to perform window operation 20 on window none when operation 20 on none already in effect” always appears on the console when I want to switch windows with Alt + Tabulator.


Thanks,

Paul
Comment 7 Matthew Barnes 2009-05-04 20:38:06 UTC
Thread 93 looks strange.  Not seeing the GConf connection here but it does seem to confirm that it's vfolder-related.  CC'ing Srini.


Thread 93 (Thread 0xec7dab90 (LWP 10750))

  • #0 __kernel_vsyscall
  • #1 __lll_lock_wait
    at ../nptl/sysdeps/unix/sysv/linux/i386/i686/../i486/lowlevellock.S line 136
  • #2 _L_lock_89
    from /lib/i686/cmov/libpthread.so.0
  • #3 __pthread_mutex_lock
    at pthread_mutex_lock.c line 86
  • #4 camel_db_begin_transaction
    at camel-db.c line 514
  • #5 camel_db_delete_uid
    at camel-db.c line 1481
  • #6 camel_folder_summary_remove
    at camel-folder-summary.c line 2227
  • #7 folder_changed_add_uid
    at camel-vee-folder.c line 1342
  • #8 folder_changed_change
    at camel-vee-folder.c line 1558
  • #9 session_thread_proxy
    at camel-session.c line 597
  • #10 g_thread_pool_thread_proxy
    at /build/buildd-glib2.0_2.20.1-2-i386-hGzT8z/glib2.0-2.20.1/glib/gthreadpool.c line 265
  • #11 g_thread_create_proxy
    at /build/buildd-glib2.0_2.20.1-2-i386-hGzT8z/glib2.0-2.20.1/glib/gthread.c line 635
  • #12 start_thread
    at pthread_create.c line 297
  • #13 clone
    at ../sysdeps/unix/sysv/linux/i386/clone.S line 130

Comment 8 Akhil Laddha 2009-05-05 12:01:23 UTC
Committed the patch for 2.26.2 from bug 579360. Please report back if it doesn't fix the problem for you.



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