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 653736 - Crash due to out of memory from google backend
Crash due to out of memory from google backend
Status: RESOLVED INCOMPLETE
Product: evolution-data-server
Classification: Platform
Component: Contacts
3.0.x (obsolete)
Other Linux
: Normal critical
: ---
Assigned To: evolution-addressbook-maintainers
Evolution QA team
Depends on:
Blocks:
 
 
Reported: 2011-06-30 11:58 UTC by Milan Crha
Modified: 2011-08-16 02:06 UTC
See Also:
GNOME target: ---
GNOME version: ---


Attachments
valgrind log (288.60 KB, text/plain)
2011-06-30 11:58 UTC, Milan Crha
Details

Description Milan Crha 2011-06-30 11:58:22 UTC
Created attachment 191006 [details]
valgrind log

Moving this from a downstream bug report:
https://bugzilla.redhat.com/show_bug.cgi?id=714418

abrt version: 2.0.1
architecture:   x86_64
cmdline:        /usr/libexec/e-addressbook-factory
comment:        Openning the addressbook.
component:      evolution-data-server
crash_function: _int_realloc
executable:     /usr/libexec/e-addressbook-factory
kernel:         2.6.38.8-32.fc15.x86_64
os_release:     Fedora release 15 (Lovelock)
package:        evolution-data-server-3.0.2-1.fc15
rating:         4
reason:         Process /usr/libexec/e-addressbook-factory was killed by signal
11 (SIGSEGV)

Thread 1 (Thread 0x7fc1109797e0 (LWP 1622))

  • #0 _int_malloc
    at malloc.c line 4636
  • #1 _int_realloc
    at malloc.c line 5290
  • #2 __libc_realloc
    at malloc.c line 3821
  • #3 g_realloc
    at gmem.c line 233
  • #4 xmlStrncat__internal_alias
    at xmlstring.c line 460
  • #5 xmlNodeAddContentLen__internal_alias
    at tree.c line 5670
  • #6 xmlStringGetNodeList__internal_alias
    at tree.c line 1475
  • #7 xmlNodeSetContent__internal_alias
    at tree.c line 5488
  • #8 foreach_save_func
    at e-xml-hash-utils.c line 109
  • #9 g_hash_table_foreach
    at ghash.c line 1326
  • #10 e_xml_from_hash
    at e-xml-hash-utils.c line 141
  • #11 e_xmlhash_write
    at e-xml-hash-utils.c line 364
  • #12 e_file_cache_thaw_changes
    at e-file-cache.c line 532
  • #13 cache_thaw
    at e-book-backend-google.c line 293
  • #14 get_new_contacts_cb
    at e-book-backend-google.c line 556
  • #15 complete_in_idle_cb_for_thread
    at gsimpleasyncresult.c line 812
  • #16 g_main_dispatch
    at gmain.c line 2441
  • #17 g_main_context_dispatch
    at gmain.c line 3014
  • #18 g_main_context_iterate
    at gmain.c line 3092
  • #19 g_main_loop_run
    at gmain.c line 3300
  • #20 main
    at e-data-book-factory.c line 686

Comment 1 Milan Crha 2011-06-30 11:59:44 UTC
After more investigation from the reporter (he provided the above attached valgrind log), it seems that google addressbook backend is leaking memory. Mine comment on the downstream bug:

The valgrind log shows some definitely lost memory, mostly related to google backend/account, but still, it may not result in a low memory for the process:
> LEAK SUMMARY:
>    definitely lost: 88 bytes in 17 blocks
>    indirectly lost: 192 bytes in 1 blocks
>      possibly lost: 10,524 bytes in 194 blocks
>    still reachable: 1,614,257 bytes in 7,707 blocks

On the other hand, having e-addressbook-factory running for a longer time, with some extensive using of a google backend, I believe it can get out of memory too.

There are also interesting these runtime warnings:
> ...libebookbackendgoogle-WARNING **: Connection to Google already established.
> ...g_object_unref: assertion `G_IS_OBJECT (object)' failed
> ...g_object_unref: assertion `G_IS_OBJECT (object)' failed
>
> ...libebookbackendgoogle-WARNING **: Connection to Google already established.
> ...g_object_unref: assertion `G_IS_OBJECT (object)' failed
> ...g_object_unref: assertion `G_IS_OBJECT (object)' failed
Comment 2 Philip Withnall 2011-06-30 18:30:35 UTC
That valgrind log isn't very useful without debug symbols for the Google Contacts backend and libgdata. Would it be possible to get a new one with debug symbol packages installed?

The same is true for the assertion failures: I can't do much without backtraces. :-(

Thanks.
Comment 3 Fabio Durán Verdugo 2011-08-16 02:06:57 UTC
Closing this bug report as no further information has been provided. Please feel free to reopen this bug if you can provide the information asked for.
Thanks!