Skip site navigation (1)Skip section navigation (2)
Date:      Thu, 16 Nov 2017 23:13:59 +0000
From:      bugzilla-noreply@freebsd.org
To:        gnome@FreeBSD.org
Subject:   [Bug 199872] devel/glib20  Apps using glib 2.42.2 crashing with 'pthread_mutex_lock' abort
Message-ID:  <bug-199872-6497-sKGOgTxb1i@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
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=3D199872

Guido Falsi <madpilot@FreeBSD.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
 Attachment #186826|0                           |1
        is obsolete|                            |
 Attachment #186826|maintainer-approval?(gnome@ |
              Flags|FreeBSD.org)                |
 Attachment #188059|                            |maintainer-approval?(gnome@
              Flags|                            |FreeBSD.org)

--- 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.

--=20
You are receiving this mail because:
You are on the CC list for the bug.
You are the assignee for the bug.=



Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?bug-199872-6497-sKGOgTxb1i>