Hi, I believe I understand the bug now.
At heart this is indeed a race condition between the removing of the seat due to the dbus name owner change (the path in the stacktrace) and due to the IN_IGNORED event from inotify. When a session is closed it will trigger the dbus event, which will remove the watch, and call inotify_rm_watch. This may stop the inotify event from coming. There is also a point where inotify events for paths that aren't watched are filtered out (the reason why it doesn't cause an infinite loop), so if the watch is removed before the inotify event hits that point it will also be ok. If however the inotify event arrives early enough that it makes it past this then it will cause the watch to be removed as well. The remove code does g_hash_table_remove (monitor->priv->path_to_watch, watch->path); which will crash if watch->path is NULL (I was wrong in my last comment, as this uses a g_str_hash, not a g_direct_hash). It then calls monitor_release_watch (monitor, watch); which does g_free (watch->path); watch->path = NULL; so if one remove call makes it to that point before the other makes it to the g_hash_table_remove call then it will cause the crash. We can check for this before calling g_hash_table_remove, which makes the time when it is possible to trigger the bug very short, but it's still possible, so we should look for a better solution. I think having the two threads do the removal is going to be problematic, so we should push the removal from the inotify thread in to the main thread. It can then check whether it has been removed yet without being racy. Thanks, James -- console-kit-daemon crashed with SIGSEGV in g_str_hash() https://bugs.launchpad.net/bugs/269651 You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs