GNOME Bugzilla – Bug 753311
Crashes when data connection setup failed
Last modified: 2015-09-23 08:20:00 UTC
Created attachment 308840 [details] [review] sftp: Fix crashes when data connection setup failed destroy_connection() is called twice when setup of data connection failed. Consequently g_hash_table_destroy() is called on already destroyed hash table on finalize. Set conn->expected_replies to NULL in destroy_connection() to fix the issue. There is another crash on force unmount when setup of data connection failed. fail_jobs() is called on already destroyed connection. Check usability of the connection before use to avoid the crash. Finally move the hast table initialization into the setup_connection, because the initialization in g_vfs_backend_sftp_init() is confusing.
Review of attachment 308840 [details] [review]: ::: daemon/gvfsbackendsftp.c @@ +1315,3 @@ gpointer key, value; + g_return_if_fail (connection_is_usable (conn)); According to the docs, g_return_val_if_fail is only supposed to be used to guard against programmer errors, whereas in this case it is expected that fail_jobs may be called with an unsable connection.
Created attachment 308997 [details] [review] sftp: Fix crashes when data connection setup failed Damn, fixed, thanks for review!
Review of attachment 308997 [details] [review]: Looks good!
Created attachment 310691 [details] [review] sftp: Don't call g_vfs_backend_force_unmount multiple times If the remote connection(s) are closed (e.g. the remote host is rebooted), ensure that g_vfs_backend_force_unmount is only called once. This avoids a warning like the following: forced_unregister_mount_callback forced_unregister_mount_callback ** (process:12472): WARNING **: Error unregistering mount: Mountpoint not registered (g-io-error-quark, 16) Additionally, remove some backend member variables.
The above patch fixes a warning that I noticed while testing.
Thanks for the patch, looks good, and sorry, I forgot on this bug. I've pushed the patches as commit 46487b4 and commit e1a3c29 .