GPollFileMonitor emits CHANGES_DONE_HINT after CHANGED signals, but it
doesn't check to ensure that the file monitor wasn't cancelled before it
does that.
If the original signal caused the monitor to be unreffed, cancelled and
destroyed, we would still end up emitting an extra signal on it.
Avoid that by checking first for cancellation.
https://bugzilla.gnome.org/show_bug.cgi?id=739424
Removed all mentions of GLib file name encoding referring to
the environment strings. The env var content has no defined relation
to GLib's notion of filename encoding, or any encoding whatsoever.
It would be wrong to pass all UTF-8 strings through
g_filename_from_utf8() in order to put them into the environment,
for one thing.
https://bugzilla.gnome.org/show_bug.cgi?id=738185
DBus has recently introduced new message flag
DBUS_HEADER_FLAG_ALLOW_INTERACTIVE_AUTHORIZATION, which tells that
caller is willing to wait for unspecified amount of time for the call
to return, as the service may perform interactive authorization (e.g.
using polkit).
https://bugzilla.gnome.org/show_bug.cgi?id=739616
In order to maintain a logical stream of events, we need to make sure we
flush and queued change notifications before responding to any requests
for information from clients.
If we don't do this, it's possible that we emit an 'add' event that was
queued at the time of a 'DescribeAll' call _after_ the reply to that
call (which already contained the description of the new action).
In practice, this is not only logically incorrect, but it can also cause
problems. If a change to action 'state' or 'enabled' occurs after the
DescribeAll but before the signal has been dispatched, it will be
ignored because an 'add' signal is already pending. When that add
signal is sent, it will contain the correct data, but the receiver will
ignore it because it already saw the action in the DescribeAll reply.
https://bugzilla.gnome.org/show_bug.cgi?id=749693
This is a hack for GLocalFileInfo to correctly get icons for directories.
Without this change content type for any W32 directory is NULL
(because there's no registry entry for "inode/directory" by default,
and in any way there's no file extension that means "directory" to put there),
and GLocalFileInfo uses content type to grab icons.
https://bugzilla.gnome.org/show_bug.cgi?id=748727
The code here was returning gtk-directory and similar names as
fallback, with a comment claiming that these are 'builtin gtk'.
But they aren't, anymore, so just return the standard names.
Prevents race condition in function g_io_condition_get_type by ensuring
that the initialization section for 'etype' is executed only once
during a program's life time, and that concurrent threads are blocked
until initialization completes. This changes solves the problem that
concurrent threads could execute the check 'etype == 0' before any of
them had initialized it, which in turn meant that multiple threads
would then attempt to register the "GIOCondition" type.
https://bugzilla.gnome.org/show_bug.cgi?id=750386
It isn't actually doing anything, instead it is
being managed without actually being used.
This has the result that GBinding is now more
thread-safe.
https://bugzilla.gnome.org/show_bug.cgi?id=745013
This code used to look at the SCM_CREDENTIALS and ignore every message
not from uid 0. However, when user namespaces are in use this does not
work, as if uid 0 is not mapped you get overflowuid instead. Right now
this means we ignore all messages in such user namespaces and glib
apps hang on startup.
We can't look at pids either, as pid 0 is returned for processes
outside your pid namespace.
Instead the correct approach is to look at the sending sockaddr and
if the port id (nl_pid) is zero, then its from the kernel.
Source:
http://lists.linuxfoundation.org/pipermail/containers/2015-May/036032.htmlhttps://bugzilla.gnome.org/show_bug.cgi?id=750203
Instead of just dropping address types that we're not specifically
handling we return a GNativeSocketAddress which is just a dummy
container for the stuct sockaddr.
https://bugzilla.gnome.org/show_bug.cgi?id=750203
Add a global lookup table for signal handlers. We already give
them a unique ID, so there is no good reason to pay for
non-constant lookups when disconnecting handlers.
https://bugzilla.gnome.org/show_bug.cgi?id=737009
This test checks the performance of connecting, disconnecting and
blocking many handlers. Various cases are checked: disconnect in
the same order, in the inverse order, at random. Connect to one
signal on a single object, to two signals on the same object, or
to the same signal on two different objects.
https://bugzilla.gnome.org/show_bug.cgi?id=737009
Only add [OPTION...] to the usage line if the context
has options. And shorten "Application Options" to just
"Options" if we don't have to differentiate from other
kinds of options.
GListStore requires that item-type be derived from GObject, so specify
that the type of the item parameters is GObject so the functions can be
used via gobject-introspection.
Add a scope parameter for the callback used during insert_sorted.
This was fixed in 8.32, so if we have that version, assert that it is
fixed; if we don't (e.g. the current internal pcre), still don't
assert that it *isn't* fixed.
Bug: https://bugzilla.gnome.org/show_bug.cgi?id=733325
Reviewed-by: Christian Persch <chpe@gnome.org>
Signed-off-by: Simon McVittie <simon.mcvittie@collabora.co.uk>
Previously, we waited up to 0.5s, but that can fail on slow
architectures like ARM; now we wait up to 60s in 0.1s increments.
Patch originally by Simon McVittie <simon.mcvittie@collabora.co.uk>,
modified by Iain Lane to be called earlier, to catch all testcases in a
particular test.
Bug: https://bugzilla.gnome.org/show_bug.cgi?id=724113
Reviewed-by: Simon McVittie <simon.mcvittie@collabora.co.uk>
Acked-by: Matthias Clasen <mclasen@redhat.com>
We previously waited 0.25s, which should be enough even on slow machines,
but you never know; but we also now wait in 0.1s increments, so this test
should actually be faster now.
Bug: https://bugzilla.gnome.org/show_bug.cgi?id=724113
Acked-by: Matthias Clasen <mclasen@redhat.com>
Instead of INCLUDES, which is deprecated in automake. Using AM_CPPFLAGS
also gives the hint that the -D argument should be a CPPFLAGS variable,
rather than CFLAGS.
Restricting the number of children to be less than 4095 can
be an issue when generating types. This is also an issue for
the Lua bindings as each Lua state will create a new GType each
time the Lua code is executed.
https://bugzilla.gnome.org/show_bug.cgi?id=747882
I searched all files that mention g_test_run, and replaced most
g_print() calls. This avoids interfering with TAP. Exceptions:
* gio/tests/network-monitor: a manual mode that is run by
"./network-monitor --watch" is unaffected
* glib/gtester.c: not a test
* glib/gtestutils.c: not a test
* glib/tests/logging.c: specifically exercising g_print()
* glib/tests/markup-parse.c: a manual mode that is run by
"./markup-parse --cdata-as-text" is unaffected
* glib/tests/testing.c: specifically exercising capture of stdout
in subprocesses
* glib/tests/utils.c: captures a subprocess's stdout
* glib/tests/testglib.c: exercises an assertion failure in g_print()
Bug: https://bugzilla.gnome.org/show_bug.cgi?id=725981
Reviewed-by: Colin Walters <walters@verbum.org>
Signed-off-by: Simon McVittie <simon.mcvittie@collabora.co.uk>
This stops it from interfering with structured stdout such as TAP.
Bug: https://bugzilla.gnome.org/show_bug.cgi?id=725981
Reviewed-by: Colin Walters <walters@verbum.org>
Signed-off-by: Simon McVittie <simon.mcvittie@collabora.co.uk>
The test is to remove all the odd values with my_hash_callback_remove(),
then iterate over all values and verify that they are even. However,
failing this check would just print "bad!" instead of failing the test.
Bug: https://bugzilla.gnome.org/show_bug.cgi?id=725981
Reviewed-by: Colin Walters <walters@verbum.org>
Signed-off-by: Simon McVittie <simon.mcvittie@collabora.co.uk>
This avoids any possibility of interfering with test syntax (such as
TAP) on stdout. TAP specifically does not parse stderr.
Bug: https://bugzilla.gnome.org/show_bug.cgi?id=725981
Reviewed-by: Colin Walters <walters@verbum.org>
Signed-off-by: Simon McVittie <simon.mcvittie@collabora.co.uk>
If we call time(NULL), then do something (however trivial), then call
g_date_time_new_now_utc(), they do not necessarily share a seconds
value. Let's say the gmtime call takes 2ms. time(NULL) could
return xx:xx:23 when the time is actually xx:xx:23.999999, resulting
in the g_date_time_new_now_utc() happening at xx:xx:24.000001. This is
unlikely, but did happen to me in a parallel build:
GLib:ERROR:.../glib/tests/gdatetime.c:674:test_GDateTime_now_utc: assertion failed (tm.tm_sec == g_date_time_get_second (dt)): (23 == 24)
A similar argument applies to the rollover from xx:23:59.999999 to
xx:24:00, so comparing seconds with a 1s "fuzz" or a >= comparison
is not sufficient; and so on into higher-order fields.
I haven't seen the other tests that use _now() fail in the same way,
but they could.
Bug: https://bugzilla.gnome.org/show_bug.cgi?id=749080
Reviewed-by: Philip Withnall <philip.withnall@collabora.co.uk>
Signed-off-by: Simon McVittie <simon.mcvittie@collabora.co.uk>
