maintainer-approval requested: [Bug 199872] devel/glib20 Apps using glib 2.42.2 crashing with 'pthread_mutex_lock' abort : [Attachment 188059] Further update glib patch

[bugzilla-noreply at freebsd.org]

Guido Falsi <madpilot at FreeBSD.org> has asked gnome at FreeBSD.org for
maintainer-approval:
Bug 199872: devel/glib20  Apps using glib 2.42.2 crashing with
'pthread_mutex_lock' abort
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=199872

Attachment 188059: Further update glib patch
https://bugs.freebsd.org/bugzilla/attachment.cgi?id=188059&action=edit



--- Comment #18 from Guido Falsi <madpilot at FreeBSD.org> ---
Created attachment 188059
  --> https://bugs.freebsd.org/bugzilla/attachment.cgi?id=188059&action=edit
Further update glib patch

I have analysed another crash, in x11-wm/xfce4-desktop this time.

I've discovered a code path in the kqueue helper  casing glib to exit due to a
filed assertion.

This is triggered when a kqueue NOTE_RENAME is generated on a file. The code
translates it in a G_FILE_MONITOR_EVENT_MOVED and passes it to
g_file_monitor_source_handle_event(), where it ends in an assertion every time.

I simply commented out the code causing this, so this event is actually
ignored.

It does not look like a problem since this code path is bound to end in a
failed assertion every time, while the same file move causing this event will
also generate an event for the parent directory, which is handled through a
slightly different code path.

My intuition is that while kqueue generates NOTE_RENAME events for single
files, GIO semantics are that such events should be generated only for moves
happening in watched directories, so ignoring a moved event for a file here is
actually correct.

Please test this patch, I think it will fix a few more problems, but needs
ample testing to make sure it's not causing problems in other areas.