I'm seeing this with telepathy-idle 0.1.16 on Debian (and have seen it earlier as well). It is common enough to be a real pain in the ass... Often it happens in relation to some short term network problems, and the result is telepathy-idle hogging 100% of one core -- seemingly forever.

Looks like this:

(gdb) thread apply all bt

Thread 3 (Thread 0x7f46b959e700 (LWP 3633)):
#0  0x00007f46bc36e19d in poll () at ../sysdeps/unix/syscall-template.S:81
#1  0x00007f46bccdb5c4 in g_main_context_poll (priority=2147483647, n_fds=1, fds=0x7f46980010c0, 
    timeout=-1, context=0x7f46b400aca0) at /build/glib2.0-U55j9q/glib2.0-2.37.6/./glib/gmain.c:4006
#2  g_main_context_iterate (context=context@entry=0x7f46b400aca0, block=block@entry=1, 
    dispatch=dispatch@entry=1, self=<optimized out>)
    at /build/glib2.0-U55j9q/glib2.0-2.37.6/./glib/gmain.c:3707
#3  0x00007f46bccdb6cc in g_main_context_iteration (context=0x7f46b400aca0, may_block=1)
    at /build/glib2.0-U55j9q/glib2.0-2.37.6/./glib/gmain.c:3773
#4  0x00007f46b95a5a1d in ?? () from /usr/lib/x86_64-linux-gnu/gio/modules/libdconfsettings.so
#5  0x00007f46bcd00275 in g_thread_proxy (data=0x7f46b4003400)
    at /build/glib2.0-U55j9q/glib2.0-2.37.6/./glib/gthread.c:798
#6  0x00007f46bc644e0e in start_thread (arg=0x7f46b959e700) at pthread_create.c:311
#7  0x00007f46bc37993d in clone () at ../sysdeps/unix/sysv/linux/x86_64/clone.S:113

Thread 2 (Thread 0x7f4697bea700 (LWP 3638)):
#0  0x00007f46bc36e19d in poll () at ../sysdeps/unix/syscall-template.S:81
#1  0x00007f46bccdb5c4 in g_main_context_poll (priority=2147483647, n_fds=3, fds=0x7f46900010c0, 
    timeout=-1, context=0x7f469800e520) at /build/glib2.0-U55j9q/glib2.0-2.37.6/./glib/gmain.c:4006
#2  g_main_context_iterate (context=0x7f469800e520, block=block@entry=1, dispatch=dispatch@entry=1, 
    self=<optimized out>) at /build/glib2.0-U55j9q/glib2.0-2.37.6/./glib/gmain.c:3707
#3  0x00007f46bccdba2a in g_main_loop_run (loop=0x7f4698010350)
    at /build/glib2.0-U55j9q/glib2.0-2.37.6/./glib/gmain.c:3906
#4  0x00007f46bd2b9956 in gdbus_shared_thread_func (user_data=0x7f469800e4f0)
    at /build/glib2.0-U55j9q/glib2.0-2.37.6/./gio/gdbusprivate.c:278
#5  0x00007f46bcd00275 in g_thread_proxy (data=0x7f46a40026d0)
    at /build/glib2.0-U55j9q/glib2.0-2.37.6/./glib/gthread.c:798
#6  0x00007f46bc644e0e in start_thread (arg=0x7f4697bea700) at pthread_create.c:311
#7  0x00007f46bc37993d in clone () at ../sysdeps/unix/sysv/linux/x86_64/clone.S:113

Thread 1 (Thread 0x7f46bdbb4800 (LWP 3626)):
#0  g_mutex_get_impl (mutex=0x25264e0)
    at /build/glib2.0-U55j9q/glib2.0-2.37.6/./glib/gthread-posix.c:126
#1  0x00007f46bcd1b519 in g_mutex_lock (mutex=mutex@entry=0x25264e0)
    at /build/glib2.0-U55j9q/glib2.0-2.37.6/./glib/gthread-posix.c:213
#2  0x00007f46bccdac79 in g_main_context_prepare (context=context@entry=0x25264e0, 
    priority=priority@entry=0x7fffdd286698) at /build/glib2.0-U55j9q/glib2.0-2.37.6/./glib/gmain.c:3341
#3  0x00007f46bccdb4e3 in g_main_context_iterate (context=0x25264e0, block=block@entry=1, 
    dispatch=dispatch@entry=1, self=<optimized out>)
    at /build/glib2.0-U55j9q/glib2.0-2.37.6/./glib/gmain.c:3692
#4  0x00007f46bccdba2a in g_main_loop_run (loop=0x2529310)
    at /build/glib2.0-U55j9q/glib2.0-2.37.6/./glib/gmain.c:3906
#5  0x00007f46bc9a5ca2 in tp_run_connection_manager ()
   from /usr/lib/x86_64-linux-gnu/libtelepathy-glib.so.0
#6  0x000000000040a326 in ?? ()
#7  0x00007f46bc2b2995 in __libc_start_main (main=0x40a2e0, argc=1, ubp_av=0x7fffdd286838, 
    init=<optimized out>, fini=<optimized out>, rtld_fini=<optimized out>, stack_end=0x7fffdd286828)
    at libc-start.c:260
#8  0x000000000040a361 in ?? ()
#9  0x00007fffdd286828 in ?? ()
#10 0x0000000000000000 in ?? ()


Threads 2 and 3 seem to stay the same, thread 1 is occasionally in a libdbus call as well (at least dbus_connection_get_dispatch_status()).

I can confirm the issue occurring in 0.1.16 as well.

In my case it happens as soon as I login to freenode with a password.

Let me know if and how I need to create a log.

Created attachment 84885 [details] [review]
ServerConnection: kill async read when disconnecting

This is the fix.

Created attachment 84886 [details] [review]
ServerConnection: dispose internal objects

That's just a cleanup.

I also filed https://bugzilla.gnome.org/show_bug.cgi?id=707097 on GSocket, it seems a different default behavior from GSocket would be welcome.

Patches look good, I'll merge them (with s/g_clear_object/tp_clear_object/ if we don't already depend on a suitable GLib).

Fixed in git for 0.1.18, thanks