GNOME Bugzilla – Bug 795522
_ip_get_path_for_wd assertion failed: (wd >= 0)
Last modified: 2018-05-24 20:27:23 UTC
In Ubuntu we're getting some reports about this crash (see https://errors.ubuntu.com/problem/7d4e9fc521926903d3f796d9d01b38c242396745, you might get access from https://forms.canonical.com/reports/)
+ Trace 238584
For some reaseon the parir watch description is unset, not sure if in such case we should just not try to get the path with something like: diff --git a/gio/inotify/inotify-helper.c b/gio/inotify/inotify-helper.c index d94458753..a24f1a645 100644 --- a/gio/inotify/inotify-helper.c +++ b/gio/inotify/inotify-helper.c @@ -175,7 +175,7 @@ ih_event_callback (ik_event_t *event, { GFile *other; - if (event->pair) + if (event->pair && event->pair->wd >= 0) { const char *parent_dir; gchar *fullpath;
I don’t think you can just fix it by checking whether the paired event’s watch descriptor is valid — this will just cause the code to treat the event as if it doesn’t have a paired event, which is incorrect and will result in the wrong GFileMonitorEvent handling at a higher level. The problem here seems to be a state management problem: somehow ih_event_callback() is being called for an ik_event_t whose paired event has been stopped (ip_watched_file_stop()) or not started (ip_watched_file_start()), or which has somehow otherwise never received a valid watch descriptor or had its watch descriptor invalidated. I wonder if there’s a problem with stopping events for one descriptor when stopping events for its pair, or something like that. Would you be able to investigate further to work out exactly where the state management problem is?
*** Bug 756974 has been marked as a duplicate of this bug. ***
(In reply to Philip Withnall from comment #1) > I don’t think you can just fix it by checking whether the paired event’s > watch descriptor is valid — this will just cause the code to treat the event > as if it doesn’t have a paired event, which is incorrect and will result in > the wrong GFileMonitorEvent handling at a higher level. Yeah, I had some concerns in fact. Going a bit furher down at the at the stack I didn't notice anything obviously wrong though. > The problem here seems to be a state management problem > Would you be able to investigate further to work out exactly where the state > management problem is? So, yeah, I might check a bit furhter... However I've never got this crash personally, so doing proper debugging is a bit tricky.
-- GitLab Migration Automatic Message -- This bug has been migrated to GNOME's GitLab instance and has been closed from further activity. You can subscribe and participate further through the new bug through this link to our GitLab instance: https://gitlab.gnome.org/GNOME/glib/issues/1370.