These tests clear up a misunderstanding of mine: Monitoring
nonexisting files and directories *does* work with the inotify
implementation, it just has a very long timeout for scanning
for missing locations, so the test needs to take that into
account.
Add a new test which checks that atomically replacing a file that
is being monitored by GFileMonitor produced the expected events.
The test can easily be expanded to cover other file monitoring
scenarios.
This is a binding-friendly version of g_dbus_connection_register_object.
Based on a patch by Martin Pitt and the code of g_bus_watch_name_with_closures.
https://bugzilla.gnome.org/show_bug.cgi?id=656325
We already have start, stop and is_active methods, but turning it
into a real property is useful for a few reasons:
- it allows us to bind the property to an UI or a setting
- it allows us to get notified when the state changes
- it allows us to instantiate objects directly in the stopped state
https://bugzilla.gnome.org/show_bug.cgi?id=752089
In 4e7d22e268, deleting the file was moved
after the assertion which checks for the changed event that results from
it being deleted. This is the wrong way around and makes the assertion
fail.
Move the deletion back up before we check the condition. delete_app is
no longer an idle callback so it can be made void. The change
notification might come in when the loop isn't running now, so don't try
to quit if it isn't running. In this case we'll wait for the three
second timeout and the test will still pass.
https://bugzilla.gnome.org/show_bug.cgi?id=751737
This can be handy when you want to change the sense of a toggle
in the UI without rewriting the underlying logic. Currently, this
is just exposed as a construct-only property. We may add a
convenience wrapper or a special !property syntax for this later.
https://bugzilla.gnome.org/show_bug.cgi?id=728489
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>
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>
When running the nonce-tcp and tcp-anonymous tests in one run
of gdbus-peer, or running one of them twice via command-line options
"-p /gdbus/tcp-anonymous -p /gdbus/tcp-anonymous", the one run second
would sometimes fail to connect with ECONNRESET.
Adding more debug messages revealed that in the successful case,
g_main_loop_run() was executed in the server thread first:
# tcp-anonymous: server thread: listening on tcp:host=localhost,port=53517
# tcp-anonymous: server thread: starting server...
# tcp-anonymous: server thread: creating main loop...
# tcp-anonymous: server thread: running main loop...
# tcp-anonymous: main thread: trying tcp:host=localhost,port=53517...
# tcp-anonymous: main thread: waiting for server thread...
but in the failing case, the main thread attempted to connect
before the call to g_main_loop_run() in the server thread:
# tcp-anonymous: server thread: listening on tcp:host=localhost,port=40659
# tcp-anonymous: server thread: starting server...
# tcp-anonymous: server thread: creating main loop...
# tcp-anonymous: main thread: trying tcp:host=localhost,port=40659...
# tcp-anonymous: server thread: running main loop...
(The log message "creating main loop" was immediately before
create_service_loop(), and "running main loop" was immediately
before g_main_loop_run().)
To ensure that the GDBusServer has a chance to start accepting
connections before the main thread tries to connect to it, do not
tell the main thread about the service_loop immediately, but instead
defer it to an idle.
Bug: https://bugzilla.gnome.org/show_bug.cgi?id=749079
Signed-off-by: Simon McVittie <simon.mcvittie@collabora.co.uk>
Reviewed-by: Philip Withnall <philip.withnall@collabora.co.uk>
This test originally did not connect to the bus, which meant it was
omitted from commits like 415a8d81 that made sure none of GLib tests
rely on the presence of an existing session bus. (In particular,
Debian autobuilders don't have a session bus.)
When test_double_array() was added, environments like the Debian
autobuilders didn't catch the fact that this test relied on having a
session bus, because it is often skipped in minimal environments
due to its libdbus-1 dependency.
We don't actually need to connect to a dbus-daemon here: it's enough
to convert the message from GVariant to D-Bus serialization, and
back into an in-memory representation through libdbus. That's what
check_serialization() does, and I've verified that when I re-introduce
bug #732754 by reverting commits 627b49b and 2268628 locally, this
test still fails.
Bug: https://bugzilla.gnome.org/show_bug.cgi?id=744895
Signed-off-by: Simon McVittie <simon.mcvittie@collabora.co.uk>
Reviewed-by: Colin Walters <walters@verbum.org>
The third parameter of the thumnail_verify() function had been updated to
const GLocalFileStat, so update the thumbnail-verification test likewise
so that the test works properly on all supported platforms.
https://bugzilla.gnome.org/show_bug.cgi?id=711547
Make sure error handling on repeated <summary> and <description> is
being done properly, not resulting in glib-compile-schemas throwing a
critical.
https://bugzilla.gnome.org/show_bug.cgi?id=747542
The gdbus GTask port introduced a deadlock because some code had been
using g_simple_async_result_complete_in_idle() to ensure that the
callback didn't run until after a mutex was unlocked, but in the gtask
version, the callback was being run immediately. Fix it to drop the
mutex before calling g_task_return*(). Also, tweak
tests/gdbus-connection to test this.
https://bugzilla.gnome.org/show_bug.cgi?id=747349
This allows the caller to know when a socket has been bound so that
it can for instance set the SO_SENDBUF and SO_RECVBUF socket options
before listen is called
https://bugzilla.gnome.org/show_bug.cgi?id=738207
GTask used a 10-thread thread pool for g_task_run_in_thread() /
g_task_run_in_thread_sync(), but this ran into problems when task
threads blocked waiting for another g_task_run_in_thread_sync()
operation to complete. Previously there was a workaround for this, by
bumping up the thread limit when that case was detected, but deadlocks
could still happen if there were non-GTask threads involved. (Eg, task
A sends a message to thread X and waits for a response, but thread X
needs to complete task B in a thread before returning the response to
task A.)
So, allow GTask's thread pool to be expanded dynamically, by watching
it from the glib worker thread, and growing it (at an
exponentially-decreasing rate) if too much time passes without any
tasks completing. This should solve the deadlocking problems without
causing sudden breakage in apps that assume they can queue huge
numbers of tasks at once without consequences.
https://bugzilla.gnome.org/show_bug.cgi?id=687223
This schema compiler was completely ignoring <summary> and
<description> tags. Unfortunately, there are modules out there
who merge translations for these back in, with xml:lang. And
this is giving dconf-editor a hard time. Since this is not
how translations of schemas are meant to be done, just
reject such schema files.
Also add tests exercising the new error handling.
https://bugzilla.gnome.org/show_bug.cgi?id=747209
For all of the effort spent ensuring that this algorithm would be
correctly threadsafe, I messed up the order of operations within a
single thread when porting to the new approach.
Fix that up.
Also: fix some overzealous asserting in the testcases. Since shutdown
is now lazy, we can never surely say !is_running at any particular point
in time.
This can be used to query whether the task has completed, in the sense
that it has had a result set on it, and has already – or will soon –
invoke its callback function.
Notifications for this property are emitted immediately after the task’s
main callback, in the same main context as that callback. This allows
for multiple bits of code to listen for completion of the GTask, which
opens the door for blocking on cancellation of the GTask and improved
handling of ‘pending’ behaviour.
https://bugzilla.gnome.org/show_bug.cgi?id=743636
There was a theoretical deadlock between the worker trying to emit a
signal at the same time as we were waiting for it to shutdown the
notification (while holding the lock).
The deadlock was particularly annoying because we didn't really need to
wait for the shutdown and because it wasn't possible to signals to
arrive while waiting for a start. Attempting to deal with start and
stop in an asymmetric way could have lead to other weird situations,
however.
Drop the lock while waiting for the worker thread to start. This means
that we face the possibility of multiple waiters on the cond at the same
time, so we need to make more of a state machine.
https://bugzilla.gnome.org/show_bug.cgi?id=742599
We install win32-software/autorun.exe (as test data for mime scanning)
only on UNIX builds, so don't attempt to chmod it on 'make install'
unless we're on UNIX.
I love Emacs keyboard macros, used them to convert the list of
defines cleverly into a list of tests, then iterated and filled in
the necessary constructor arguments.
This is *significantly* more pleasant to use from C (while handling
errors and memory cleanup).
While we're here, change some ugly, leaky code in
tests/desktop-app-info.c to use it, in addition to a test case
in tests/file.c.
https://bugzilla.gnome.org/show_bug.cgi?id=661554
delayed_close_free() calls g_object_unref() on a variable that is
expected to possibly contain NULL (as indicated by the fact that the
NULL case is handled in my_slow_close_output_stream_close_async()).
This is dead code right now (due to a bug in GDBus), which is why it
isn't actually causing a failure. It should still be fixed, however.
https://bugzilla.gnome.org/show_bug.cgi?id=743990
