Date: Thu, 16 Nov 2017 23:13:59 +0000 From: bugzilla-noreply@freebsd.org To: gnome@FreeBSD.org Subject: 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 Message-ID: <bug-199872-6497-5Dspk9wVre@https.bugs.freebsd.org/bugzilla/> In-Reply-To: <bug-199872-6497@https.bugs.freebsd.org/bugzilla/> References: <bug-199872-6497@https.bugs.freebsd.org/bugzilla/>
next in thread | previous in thread | raw e-mail | index | archive | help
Guido Falsi <madpilot@FreeBSD.org> has asked gnome@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=3D199872 Attachment 188059: Further update glib patch https://bugs.freebsd.org/bugzilla/attachment.cgi?id=3D188059&action=3Dedit --- Comment #18 from Guido Falsi <madpilot@FreeBSD.org> --- Created attachment 188059 --> https://bugs.freebsd.org/bugzilla/attachment.cgi?id=3D188059&action= =3Dedit 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 t= o 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 t= ime. 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 wi= ll 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.
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?bug-199872-6497-5Dspk9wVre>