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 273286 - e-d-s chewing 100% CPU
e-d-s chewing 100% CPU
Status: RESOLVED FIXED
Product: evolution-data-server
Classification: Platform
Component: Contacts
1.2.x (obsolete)
Other All
: Normal major
: ---
Assigned To: Evolution Groupwise development team
Evolution QA team
evolution[groupwise]
: 273430 328913 (view as bug list)
Depends on:
Blocks:
 
 
Reported: 2005-03-03 15:45 UTC by Michael Meeks
Modified: 2006-06-07 13:02 UTC
See Also:
GNOME target: ---
GNOME version: ---


Description Michael Meeks 2005-03-03 15:45:17 UTC 
I'm using:

evolution-devel-2.1.6.0.200503020400-0.snap.novell.0.1
evolution-data-server-1.1.6.0.200503020400-0.snap.novell.0.1
evolution-2.1.6.0.200503020400-0.snap.novell.0.1
evolution-data-server-devel-1.1.6.0.200503020400-0.snap.novell.0.1

ok - so it looks like there is some nice RPM conflict/problem there - but
either way, I'm getting this interesting 100% CPU usage from this stack trace:

+ Trace 56388

Thread 5 (Thread 11419653 (LWP 19402))

  • #0 xmlStrlen
    at xmlstring.c line 426
  • #1 xmlStrncat
    at xmlstring.c line 454
  • #2 xmlNodeAddContentLen
    at tree.c line 5201
  • #3 xmlNodeAddContent
    at tree.c line 5241
  • #4 xmlAddNextSibling
    at tree.c line 2836
  • #5 xmlStringGetNodeList
    at tree.c line 1482
  • #6 xmlNodeSetContent
    at tree.c line 5035
  • #7 foreach_save_func
    at e-xml-hash-utils.c line 95
  • #8 g_hash_table_foreach
    from /opt/gnome/lib/libglib-2.0.so.0
  • #9 e_xml_from_hash
    at e-xml-hash-utils.c line 114
  • #10 e_xmlhash_write
    at e-xml-hash-utils.c line 249
  • #11 e_file_cache_add_object
    at e-file-cache.c line 410
  • #12 e_book_backend_cache_add_contact
    at e-book-backend-cache.c line 277
  • #13 build_cache
    at e-book-backend-groupwise.c line 2196
  • #14 g_thread_create_proxy
    from /opt/gnome/lib/libglib-2.0.so.0
  • #15 pthread_start_thread
    from /lib/libpthread.so.0
  • #16 clone
    from /lib/libc.so.6 

It (amazingly) takes several seconds to complete:

6  0x405c9749 in xmlNodeSetContent (cur=0x422a4f90, 
    content=0x42800008 "BEGIN:VCARD
\nV

if I type finish a lot ;-)
Comment 1 Elijah Newren 2005-04-09 23:10:34 UTC 
*** Bug 273430 has been marked as a duplicate of this bug. ***
Comment 2 Nagappan Alagappan 2005-06-20 10:25:56 UTC 
Michael: Can you provide us some steps to reproduce this bug ?
Comment 3 Michael Meeks 2005-06-20 11:18:59 UTC 
Sure - I guess you'd want to try to use the evolution / G/W connectivity ;->

I believe there was some hack added to filter out large address lists - which
AFAIR was claimed to be a root cause of this problem.

Either way - we really shouldn't be typing xmlNodeSetContent for anything
complex - it's far too inefficient it seems.

Either way - quite why we need to construct some gigantic in-memory model in the
(horribly inefficient) libxml2 tree representation just to write the data out is
beyond me.

fprintf (file-handle, "<this_is_xml/>\n");

would appear to be thousands of times more efficent, robust, readable ;-> ...
Comment 4 Michael Meeks 2005-06-20 14:44:39 UTC 
So - bad news; I just got an identical 100% CPU chew, with an identical
stack-trace with a very recent snapshot:

evolution-data-server-1.2.3.0.200506170310-0.snap.novell.0.1

of course, it's possible I need to clear my e-book cache somehow: how would I do
that ?
Comment 5 Sushma Rai 2005-08-19 06:22:17 UTC 
can you test this with the recent version of Evolution?
Comment 6 Michael Meeks 2005-08-19 14:35:35 UTC 
where are the snapshots for NLD ?
Comment 7 Nagappan Alagappan 2005-08-19 15:26:40 UTC 
Michael, the latest devel snapshots are available only for SuSE 9.3. I'm not
sure, whether they are available for NLD.
Comment 8 André Klapper 2006-01-08 23:24:04 UTC 
hmm... michael, any news on this?
Comment 9 Michael Meeks 2006-01-09 09:51:53 UTC 
Well - the hack added to filter out huge address lists is in-place I believe & prolly helps with this - however, the underlying issue of being unable to save large address lists quickly due to this rather daft code is presumably still in-place. Either way the symptom is gone AFAICS.
Comment 10 Karsten Bräckelmann 2006-01-17 22:05:22 UTC 
Apparently no duplicates, and even Michael doesn't get the symtoms any longer. Does this mean it has not been seen since e-d-s 1.2.x days?

Downing Severity, this is not a blocker.

Michael, anything to add? Could you try to reproduce the issue you described originally?
Comment 11 Michael Meeks 2006-01-19 10:42:20 UTC 
re-title to reflect ongoing underlying issue ...
Comment 12 Devashish Sharma 2006-01-30 08:13:11 UTC 
*** Bug 328913 has been marked as a duplicate of this bug. ***
Comment 13 Gen Zhang 2006-04-12 12:30:53 UTC 
I've seen this again... in FC5. See https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=188349
Comment 14 Quazatron 2006-05-18 11:07:37 UTC 
I'm getting about 50% to 99% CPU usage on Ubuntu Hoary.
Comment 15 Sushma Rai 2006-05-19 05:15:44 UTC 
Quazatron,
Are you seeing this with GroupWise address book or 
LDAP address book?
Comment 16 Devashish Sharma 2006-06-07 13:02:08 UTC 
The fix for this has been committed to the head.
Try this and see whether the condition is still reproducible.