[Bug 28350] SSL breaks idle
bugzilla-daemon at freedesktop.org
bugzilla-daemon at freedesktop.org
Tue Oct 30 19:10:03 CET 2012
https://bugs.freedesktop.org/show_bug.cgi?id=28350
--- Comment #3 from Will Thompson <will.thompson at collabora.co.uk> ---
(In reply to comment #2)
> This list of servers for OFTC in Empathy was incomplete:
> https://bugzilla.gnome.org/656933
>
> It did not have the ports on which the servers accept SSL connections, so
> unless you added them yourself, it won't work.
>
> Having said that, Idle should still not crash. It could be because of this
> bug in GIO: https://bugzilla.gnome.org/656283
This still crashes Idle. It's easy to test by changing
connect/connect-success-ssl.py's final line to read
exec_test(test, {'use-ssl':dbus.Boolean(True)})#, protocol=SSLIRCServer)
(that is, making Idle use SSL but listening in plaintext).
Idle crashes as follows:
(telepathy-idle:15153): tp-glib/connection-DEBUG:
tp_base_connection_change_status: was 1, now 2, for reason 1
(telepathy-idle:15153): tp-glib/connection-DEBUG:
tp_base_connection_change_status: emitting status-changed to 2, for reason 1
(telepathy-idle:15153): tp-glib/params-DEBUG: connection_shutdown_finished_cb:
dereferenced connection
(telepathy-idle:15153): tp-glib/sasl-DEBUG: tp_simple_password_manager_dispose:
dispose called
(telepathy-idle:15153): tp-glib/connection-DEBUG: tp_contacts_mixin_finalize:
0x2582020
** (telepathy-idle:15153): DEBUG: _connect_to_host_ready:
g_socket_client_connect_to_host failed: Peer failed to perform TLS handshake
** (telepathy-idle:15153): DEBUG: change_state: emitting status-changed, state
0, reason 0
(telepathy-idle:15153): GLib-GObject-CRITICAL **: g_type_instance_get_private:
assertion `instance != NULL && instance->g_class != NULL' failed
with this backtrace:
#3 0x00002b619257c1aa in g_type_instance_get_private
(instance=instance at entry=0x2582020, private_type=39298000)
at /tmp/buildd/glib2.0-2.33.12+really2.32.4/./gobject/gtype.c:4510
#4 0x000000000040b930 in sconn_status_changed_cb (sconn=<optimized out>,
state=SERVER_CONNECTION_STATE_NOT_CONNECTED,
reason=SERVER_CONNECTION_STATE_REASON_ERROR, conn=0x2582020) at
idle-connection.c:743
#5 0x00002b61947127bc in ffi_call_unix64 () from
/usr/lib/x86_64-linux-gnu/libffi.so.5
#6 0x00002b6194712237 in ffi_call () from
/usr/lib/x86_64-linux-gnu/libffi.so.5
#7 0x00002b619255a03b in g_cclosure_marshal_generic (closure=0x258af60,
return_gvalue=0x0, n_param_values=<optimized out>,
param_values=<optimized out>, invocation_hint=<optimized out>,
marshal_data=0x40b900)
at /tmp/buildd/glib2.0-2.33.12+really2.32.4/./gobject/gclosure.c:1454
#8 0x00002b61925596e0 in g_closure_invoke (closure=0x258af60,
return_value=0x0, n_param_values=3, param_values=0x7fff8c042ed0,
invocation_hint=0x7fff8c042e70) at
/tmp/buildd/glib2.0-2.33.12+really2.32.4/./gobject/gclosure.c:777
#9 0x00002b619256a750 in signal_emit_unlocked_R (node=node at entry=0x2583c00,
detail=detail at entry=0, instance=instance at entry=0x2588000,
emission_return=emission_return at entry=0x0,
instance_and_params=instance_and_params at entry=0x7fff8c042ed0)
at /tmp/buildd/glib2.0-2.33.12+really2.32.4/./gobject/gsignal.c:3551
#10 0x00002b61925726bc in g_signal_emit_valist (instance=0x2588000,
signal_id=<optimized out>, detail=0,
var_args=var_args at entry=0x7fff8c043148) at
/tmp/buildd/glib2.0-2.33.12+really2.32.4/./gobject/gsignal.c:3300
#11 0x00002b6192572852 in g_signal_emit (instance=instance at entry=0x2588000,
signal_id=<optimized out>, detail=detail at entry=0)
at /tmp/buildd/glib2.0-2.33.12+really2.32.4/./gobject/gsignal.c:3356
#12 0x00000000004170a1 in change_state (conn=conn at entry=0x2588000,
state=state at entry=SERVER_CONNECTION_STATE_NOT_CONNECTED,
reason=reason at entry=0) at idle-server-connection.c:212
#13 0x0000000000417aaf in _connect_to_host_ready (source_object=<optimized
out>, res=0x2578410, user_data=<optimized out>)
at idle-server-connection.c:272
which looks a lot like the IdleConnection has been disposed without
disconnecting sconn_status_changed_cb from the signal.
--
You are receiving this mail because:
You are the QA Contact for the bug.
You are the assignee for the bug.
More information about the telepathy-bugs
mailing list