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 590596 - evolution-data-server-2.28 crashed with SIGSEGV in g_atomic_int_exchange_and_add()
evolution-data-server-2.28 crashed with SIGSEGV in g_atomic_int_exchange_and_...
Status: RESOLVED INCOMPLETE
Product: evolution-data-server
Classification: Platform
Component: Calendar
2.28.x (obsolete)
Other Linux
: Normal critical
: ---
Assigned To: evolution-calendar-maintainers
Evolution QA team
evolution[caldav] evolution[google]
Depends on:
Blocks:
 
 
Reported: 2009-08-03 10:03 UTC by Pedro Villavicencio
Modified: 2011-09-07 06:46 UTC
See Also:
GNOME target: ---
GNOME version: 2.27/2.28


Description Pedro Villavicencio 2009-08-03 10:03:56 UTC 
this report has been filed here:

https://bugs.edge.launchpad.net/ubuntu/+source/evolution-data-server/+bug/407734

"Trying to Sync with Google Calender.

Evolution Data Server crashed"

".

+ Trace 216762

Thread 4 (process 14774)

  • #0 __lll_lock_wait
    from /lib/libpthread.so.0
  • #1 _L_lock_102
    from /lib/libpthread.so.0
  • #2 pthread_mutex_lock
    from /lib/libpthread.so.0
  • #3 caldav_do_open
    at e-cal-backend-caldav.c line 2327
  • #4 e_cal_backend_sync_open
    at e-cal-backend-sync.c line 187
  • #5 _e_cal_backend_open
    at e-cal-backend-sync.c line 707
  • #6 ORBit_small_invoke_adaptor
    at orbit-small.c line 846
  • #7 ORBit_POAObject_handle_request
    at poa.c line 1357
  • #8 ORBit_POAObject_invoke_incoming_request
    at poa.c line 1427
  • #9 giop_thread_queue_process
    at giop.c line 792
  • #10 giop_request_handler_thread
    at giop.c line 502
  • #11 g_thread_pool_thread_proxy
    at /build/buildd/glib2.0-2.21.4/glib/gthreadpool.c line 265
  • #12 g_thread_create_proxy
    at /build/buildd/glib2.0-2.21.4/glib/gthread.c line 635
  • #13 start_thread
    from /lib/libpthread.so.0
  • #14 clone
    at ../sysdeps/unix/sysv/linux/x86_64/clone.S line 112
  • #15 ??

Thread 3 (process 14771)

  • #0 __lll_lock_wait
    from /lib/libpthread.so.0
  • #1 _L_lock_102
    from /lib/libpthread.so.0
  • #2 pthread_mutex_lock
    from /lib/libpthread.so.0
  • #3 caldav_synch_slave_loop
    at e-cal-backend-caldav.c line 1956
  • #4 g_thread_create_proxy
    at /build/buildd/glib2.0-2.21.4/glib/gthread.c line 635
  • #5 start_thread
    from /lib/libpthread.so.0
  • #6 clone
    at ../sysdeps/unix/sysv/linux/x86_64/clone.S line 112
  • #7 ??

Thread 1 (process 14759)

  • #0 IA__g_atomic_int_exchange_and_add
    at /build/buildd/glib2.0-2.21.4/glib/gatomic.c line 228
  • #1 IA__g_io_channel_unref
    at /build/buildd/glib2.0-2.21.4/glib/giochannel.c line 136
  • #2 disconnect_internal
    at soup-socket.c line 123
  • #3 socket_connect_internal
    at soup-socket.c line 691
  • #4 soup_connection_connect_sync
    at soup-connection.c line 451
  • #5 process_queue_item
    at soup-session-sync.c line 204
  • #6 send_message
    at soup-session-sync.c line 311
  • #7 send_and_handle_redirection
    at e-cal-backend-caldav.c line 897
  • #8 caldav_do_open
    at e-cal-backend-caldav.c line 950
  • #9 e_cal_backend_sync_open
    at e-cal-backend-sync.c line 187
  • #10 _e_cal_backend_open
    at e-cal-backend-sync.c line 707
  • #11 ORBit_small_invoke_adaptor
    at orbit-small.c line 846
  • #12 ORBit_POAObject_handle_request
    at poa.c line 1357
  • #13 ORBit_POAObject_invoke_incoming_request
    at poa.c line 1427
  • #14 giop_thread_queue_process
    at giop.c line 792
  • #15 giop_request_handler_thread
    at giop.c line 502
  • #16 g_thread_pool_thread_proxy
    at /build/buildd/glib2.0-2.21.4/glib/gthreadpool.c line 265
  • #17 g_thread_create_proxy
    at /build/buildd/glib2.0-2.21.4/glib/gthread.c line 635
  • #18 start_thread
    from /lib/libpthread.so.0
  • #19 clone
    at ../sysdeps/unix/sysv/linux/x86_64/clone.S line 112
  • #20 ?? 






Comment 1


Milan Crha





          2009-08-04 09:16:15 UTC
        



What exact version of glib and libsoup are you using, please? I do not see this myself with glib2-2.20.3 and libsoup-2.26.2






Comment 2


Matthew Barnes





          2009-08-04 11:26:00 UTC
        



The SoupConnection instance appears valid, but it's unreffing a dead internal GIOChannel (channel=0xaaaaaaaaaaaaaaaa).  Possibly a libsoup bug, but not sure yet.  CC'ing Dan at least.






Comment 3


Dan Winship





          2009-08-04 13:40:13 UTC
        



I can't see how priv->iochannel would ever get set to 0xaaaaaaaaaaaaaaaa in a valid SoupSocket. So either the socket is getting disposed during the connection attempt (which also shouldn't be possible), or something is clobbering it. If this is reproducible I'd say valgrind it.







Comment 4


Akhil Laddha





          2011-07-25 08:49:36 UTC
        



Could you please confirm if this bug is still happening at your end ? Please try with Evolution 2.32.x/ 3.0.x and if you can reproduce, please report back with valgrind trace as mentioned in comment#3, thanks.






Comment 5


Akhil Laddha





          2011-09-07 06:46:25 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!