Nautilus crashes with SIGSEGV in g_str_hash()

[z]

Binary package hint: ubuntuone-client

System: Ubuntu 10.10 (amd64)
Source Package: ubuntuone-client
Binary Package: ubuntuone-client-gnome
UbuntuOne Client Version: 1.4.4.1-0ubuntu1

Test Case:
Move items to remote share (samba) from local folder using cut, keeping items selected in the folder during the copy. When the first item finishes and it is deleted from the local folder nautilus crashes. It does not happen if nothing is selected during the copy. Note: the actual copy works.

I have recompiled ubuntuone-client without optimizations and debugged using gdb. The offending line is 145 in ubuntuone-nautilus.c in ubuntuone_nautilus_observed_file_unref().

static void ubuntuone_nautilus_observed_file_unref (gpointer user_data,
                                                    GObject *where_the_object_was) {
  UbuntuOneNautilus * uon;
  NautilusFileInfo * file;
  gchar * path = NULL;

  uon = UBUNTUONE_NAUTILUS(user_data);
  file = NAUTILUS_FILE_INFO(where_the_object_was);
  path = g_filename_from_uri (nautilus_file_info_get_uri (file), NULL, NULL);

  if (g_hash_table_lookup (uon->observed, path )) // HERE 'path' is NULL when the crash happens
    g_hash_table_remove (uon->observed, path);

}

I have patched the code to check that path is non-null before calling g_hash_table_lookup and it fixes the bug.

>> if (path && g_hash_table_lookup (uon->observed, path ))
<< if (g_hash_table_lookup (uon->observed, path ))

I don't know what the hash table keeps track of, so someone familiar with the code should figure out what is correct here.

[Roman Yepishev (rye)]

Thank you for an awesome bug report!

Ok, it looks like under some conditions the g_filename_from_uri or nautilus_file_info_get_uri can return NULL. In this case we are notified about object dereferencing but we have no idea what path was that. In case we simply discard such message we will end up leaking the hash entries which is most likely better than crashing.

I was able to reproduce this and trying to get more information about the reason at the moment.

[Roman Yepishev (rye)]

Ok, I am making this a duplicate of LP:680968 since apport insists that one contains the proper stack trace.
Will update the description there since the reason is now known and yes, it is related to remote file systems.