res_ninit() requires the __res_state struct passed to it to be
zero-filled on FreeBSD.
Spotted and analysed by Ashish SHUKLA.
Signed-off-by: Philip Withnall <withnall@endlessm.com>
Fixes#1697
Synchronize access to cancelled flag of cancellable, which was
previously access without synchronization in g_cancellable_is_cancelled.
Use atomic operations instead of existing global mutex, to avoid
serializing calls to g_cancellable_is_cancelled across all threads.
Ensure that source is attached to the context before it migth be used
from another thread, since otherwise operation on source are
unsynchronized and not thread-safe.
In particular there was a data race between g_source_attach and
g_source_set_ready_time (used from g_file_monitor_source_handle_event).
This essentially reverts commit
cffed58737.
The preceding two commits have fixed the test so it’s no longer flaky.
The following command gives 5000 passes in a row for me:
meson test -C /opt/gnome/build/glib/ socket-service --repeat 5000
Signed-off-by: Philip Withnall <withnall@endlessm.com>
Fixes: #1679
It’s occasionally possible for the cancellation of the service to happen
before connection_cb() gets scheduled in the other thread. The
locking/unlocking order of mutex_712570 requires:
• test_threaded_712570(): lock mutex
• test_threaded_712570(): start wait loop
• connection_cb(): lock mutex
• test_threaded_socket_service_finalize(): unlock mutex
• test_threaded_712570(): end wait loop
• test_threaded_712570(): unlock mutex
Fix that by quitting the main loop once connection_cb() has been called
(i.e. once the server thread has received the incoming connection
request), rather than just after the client thread (main thread) has
sent a connection request.
Signed-off-by: Philip Withnall <withnall@endlessm.com>
Helps: #1679
On about 1 in 3 test runs, the socket-service would fail with the
ref_count assertion in connection_cb() failing (the ref_count would be 3
rather than the expected 2).
This was happening because the GTask from
g_socket_listener_accept_socket_async() now always takes at least one
main context iteration to return a result (whereas before
6f3d57d2ee it might have taken zero), but
the ref_count can drop below 3 before the process of returning a result
starts. During the process of returning a result, the ref_count
temporarily increases again, which is what was breaking the test.
Fix this by waiting for one more main context iteration. This is a bit
of a hack, but the real fix would be to expose the outstanding_accept
boolean from GSocketService as public API (which the test can
interrogate), and that seems too much like exposing internal state.
Signed-off-by: Philip Withnall <withnall@endlessm.com>
Helps: #1679
Almost everything that needs gioenumtypes.h also needs
gobjectenumtypes.h. Fixes:
ccache cc @gio/win32/gio@win32@@giowin32@sta/gwin32filemonitor.c.obj.rsp
In file included from ../gio/win32/gwin32filemonitor.h:25:0,
from ../gio/win32/gwin32filemonitor.c:26:
../glib/glib-object.h:37:10: fatal error: gobject/gobjectenumtypes.h: No such file or directory
#include <gobject/gobjectenumtypes.h>
^~~~~~~~~~~~~~~~~~~~~~~~~~~~
GIO modules built with MSVC do not begin with 'lib', but they can
begin with 'gio'. Without this, you can only load GIO modules built
with MSVC that are `name.dll`, not `gioname.dll`.
Eliminate several cases of splitting sentences between multiple
translatable strings, and remove some newlines from the translatable
strings (they always need to be present, and can confuse translation, so
add them unconditionally afterwards).
Signed-off-by: Philip Withnall <withnall@endlessm.com>
Compilers get confused when variables are initialized by a function by
taking them as reference in an out argument; this, coupled with the fact
that C does not initialize variables by default, most commonly results
in a "maybe uninitialized" compiler warning.
512e9b3b34 added a call to schedule_pending_close() in the read
callback after the reference to the worker is already gone. In case this was
the last reference to the worker this resulted in a use-after-free.
6f3d57d2ee made this more likely to happen because on connection close
the worker cancel action is now async while the reference to the worker
gets dropped right away.
Move the call to schedule_pending_close() before the unref.
Fixes#1686
When testing as root, changing the permissions of the keyfile will have
no effect on the writability since root bypasses these permissions. See
path_resolution(7). Skip the test in this case.
g_assert_*() give more informative error messages, and aren’t compiled
out when building with G_DISABLE_ASSERT.
Signed-off-by: Philip Withnall <withnall@endlessm.com>
getsockname() returns the address that the socket was bound to.
If it was bound to INADDR_ANY, getsockname() will stubbornly return INADDR_ANY
(and someport - that one is valid).
Subsequent connection attempts to INADDR_ANY:someport will fail with winsock.
Actually, it doesn't make even sense to connect to INADDR_ANY at all
(where is the socket connecting to? To a random interface of the host?),
so this is just a straight-up change, without platform-specific ifdefing.
Use loopback instead of INADDR_ANY. To ensure that binding and creation
of INADDR_ANY is still tested, use two addresses: bind to INADDR_ANY,
but connect to loopback, with the port number that we got from the bound
address.
Use a static GQueue to form the GList of mounts by appending (which
is fast, because GQueue tracks the tail pointer of its internal GList),
then return that GList. This way we don't need to form the list
by prepending, which would have made it necessary to reverse it before
returning.
If the list is not ordered correctly, local drives in GTK places sidebar
are shown in reverse order.
The gsocketclient-slow test needs this, otherwise connect() succeeds
immeidately and the test fails, because it is checking that cancellation
works. We weren't installing it for installed tests.
It's necessary sometimes for installed tests to be able to run with a
custom environment. For example, the gsocketclient-slow test requires an
LD_PRELOADed library to provide a slow connect() (this is to be added in
a followup commit).
Introduce a variable `@env@` into the installed test template, which we
can override as necessary when generating `.test` files, to run tests
prefixed with `/usr/bin/env <LIST OF VARIABLES>`.
As the only test that requires this currently lives in `gio/tests/`, we
are only hooking this up for that directory right now. If other tests in
future require this treatment, then the support can be extended at that
point.
There's no /tmp directory on Windows.
Use g_get_tmp_dir(), and adjust the test to work with that.
The test *still* checks the basename of the new CWD, it just
doesn't need to be "tmp" anymore.
envp in spawn() functions is the *whole* environment table
for the child process. Including PATH. Thus, unless PATH is explicitly
put into that table, the process will be spawned without PATH.
Since on Windows binaries are found via PATH instead of LD_LIBRARY_PATH
or whatever, almost no program (unless installed in WINDIR, maybe)
can run without a PATH. Certainly not test programs - meson
adds bld subdirs to the PATH to make sure that test programs
use uninstalled glib at runtime.
So make sure that PATH is passed along.
Windows \r\n EOLs strike again. The test already knows about LINEEND,
so make it use LINEEND more (instead of swithcing pipes
to binary mode). This also applies to counting the bytes
read.
With winsock sending messages to NULL results in G_IO_ERROR_NOT_CONNECTED
instead of G_IO_ERROR_FAILED.
MSDN says:
WSAENOTCONN
10057
Socket is not connected.
A request to send or receive data was disallowed because the socket is not connected
and (when sending on a datagram socket using sendto) no address was supplied.
So this is a direct mapping of the implementation error.
Covering it up in the wrapper (by converting it to G_IO_ERROR_FAILED)
doesn't seem feasible or needed (no one, except for the testsuite,
really cares which unrecoverable error is returned by sendto()).
getaddrinfo() in winsock can't understand scope IDs.
There's no obvious way to fix that, short of re-implementing
that function, so disable that part of the test on Windows.
G_RESOURCE_OVERLAYS is a list of resource-path and filesystem-path pairs.
Since on Windows filesystem paths use ':', this list can't be ':'-separated
there. Fix that by making it ';'-separated on Windows. Make the parser
error clearer (we're not looking for a slash, we're looking for an absolute
path).
If a URI can't be handled by by WinHTTPVfs, it should pass that URI
along to the URI parser of the wrapped Vfs, not to its generic parser.
Theoretically, generic parser should also be able to handle URIs,
but this is subject to Vfs semantics.
In case of Windows, the wrapped Vfs is GLocalVfs, which is *local* and
treats any generic names as either file:// URIs or as filesystem
paths. It only ever treats URIs as URIs when they are passed
to its URI parser. This breaks the testsuite when g-icon GIO test passes
unhandleable sftp:// URI, and expects it to come through unmolested,
yet GLocalVfs, getting that URI as a generic parse name, treats it as
a filesystem path, and then "canonicalizes" it by prepending CWD.
Fix this by making WinHTTPVfs pass any URIs it gets to the URI parser
of the wrapped Vfs. This way unknown URIs remain URI-ish. This seems
like a reasonable things to do, since the URI parser should not be
given anything other than URIs, so there's no reason to try generic
parsing with these strings.
Closes: #875
Previously once the end of addresses was reached it would return
NULL even if it was waiting on a dns response. Now it will keep
waiting so all addresses are received.
Fixes#1680
Currently, the actual asynchronous work, represented by
asynchronous_cancellation_run_task, was over before the GCancellable
could be triggered. While that doesn't invalidate the purpose of the
test, since it's fundamentally about cancellation, it would be
nicer if the cancellation actually served some purpose instead of
being a mere formality.
https://gitlab.gnome.org/GNOME/glib/issues/1608
When calling g_socket_listener_accept_socket_async() on a
GSocketListener with multiple sockets, the accept_ready() callback is
called for the first incoming connection on each socket. It will return
success/failure for the entire accept_socket_async() GTask, and then
free the GSources for listening for incoming connections on the other
sockets in the GSocketListener. The GSources are freed when the GTask is
finalised.
However, if incoming connections arrive for multiple sockets within the
same GMainContext iteration, accept_ready() will be called multiple
times, and will call g_task_return_*() multiple times, before the GTask
is finalised. Calling g_task_return_*() multiple times is not allowed.
Propagate the first success/failure, as before, but then ignore all
subsequent incoming connections until the GTask is finalised.
Signed-off-by: Philip Withnall <withnall@endlessm.com>
Once cancelled, a GTask's callback should not only be invoked
asynchronously with respect to the creation of the task, but also with
respect to the GCancellable::cancelled handler. This is particularly
relevant in cases where the cancellation happened in the same thread
where the task is running.
Spotted by Dan Winship and Michael Catanzaro.
Closes https://gitlab.gnome.org/GNOME/glib/issues/1608
It needs investigating and fixing properly, but let’s not let it disrupt
the CI in the meantime.
Follow-up in https://gitlab.gnome.org/GNOME/glib/issues/1679.
Signed-off-by: Philip Withnall <withnall@endlessm.com>
To make things consistent across the board as that is the WinSock2 error
code that is received by g_socket_send_message_with_timeout() when it
returns G_POLLABLE_RETURN_WOULD_BLOCK.
This never caused any problems because the default GSettingsBackend is
cached forever by GIOModule anyway.
Signed-off-by: Philip Withnall <withnall@endlessm.com>
I was trying to debug some memory leaks in the gsettings test.
Eventually, it seems that actually they’re caused by the
GMemorySettingsBackend being cached by GIOModule — so this commit makes
no functional changes. It should make the code and documentation a bit
clearer though.
Signed-off-by: Philip Withnall <withnall@endlessm.com>
This mostly affects the 2.56 branch, but, given that GCC 9 is being
stricter about passing null string pointers to printf-like functions, it
might make sense to proactively fix such calls.
gdbusauth.c: In function '_g_dbus_auth_run_server':
gdbusauth.c:1302:11: error: '%s' directive argument is null
[-Werror=format-overflow=]
1302 | debug_print ("SERVER: WaitingForBegin, read '%s'",
line);
|
gdbusmessage.c: In function ‘g_dbus_message_to_blob’:
gdbusmessage.c:2730:30: error: ‘%s’ directive argument is null [-Werror=format-overflow=]
2730 | tupled_signature_str = g_strdup_printf ("(%s)", signature_str);
|
The recent changes of the g_app_info_launch_default_for_uri_async()
function ensures that the callback is not called before DBus-activated
applications start. Let's use g_app_info_launch_default_for_uri_async()
and remove the workarounds for DBus-activated applications.
Closes: https://gitlab.gnome.org/GNOME/glib/issues/1249
The g_app_info_launch_uris_async() and g_app_info_launch_uris_finish()
functions are crucial to fix g_app_info_launch_default_for_uri_async()
to be really asynchronous.
This patch also adds GDesktopAppInfo implementation of that vfuncs.
The implementation may still use some synchronous calls to local MIME DB.
https://gitlab.gnome.org/GNOME/glib/issues/1347https://gitlab.gnome.org/GNOME/glib/issues/1249
In the writev() tests, the handling of cancellation is tested. However,
the GCancellable was cancelled after the writev_async() call was
started. Depending on the implementation of the writev() vfunc, the
operation could be done in a thread or in callbacks on the current
thread’s main loop. If done in a separate thread, there’s a chance that
enough of the write could happen before cancellation reaches that thread
that the overall operation returns success with a short write.
That would cause the test to fail, sometimes.
Avoid that by cancelling the GCancellable before starting the writev()
operation.
Signed-off-by: Philip Withnall <withnall@endlessm.com>
Reviewed-by: nobody
It would always be initialized but initialize it to NULL to silence the
compiler, and also check that it is not NULL anymore when we expect it
to contain a valid value.
../gio/tests/desktop-app-info.c: In function ‘test_fallback’:
../gio/tests/desktop-app-info.c:191:18: warning: ‘app’ may be used uninitialized in this function [-Wmaybe-uninitialized]
g_assert_true (g_app_info_equal (info1, app));
^~~~~~~~~~~~~~~~
It could've never been uninitialized in this code but the code flow is
not obvious to the compiler. Initialize it to NULL and for clarity also
add an assertion that it is not NULL anymore on usage.
In file included from ../glib/glib.h:62,
from ../gobject/gbinding.h:28,
from ../glib/glib-object.h:23,
from ../gio/gioenums.h:28,
from ../gio/giotypes.h:28,
from ../gio/giomodule.h:28,
from ../gio/giomodule.c:25:
../gio/giomodule.c: In function ‘_g_io_module_get_default’:
../glib/gmessages.h:343:25: warning: ‘extension’ may be used uninitialized in this function [-Wmaybe-uninitialized]
#define g_debug(...) g_log (G_LOG_DOMAIN, \
^~~~~
../gio/giomodule.c:912:17: note: ‘extension’ was declared here
GIOExtension *extension, *preferred;
^~~~~~~~~
This allows returning WOULD_BLOCK without allocating a GError, and
should later be used for various functions of GPollableOutputStream,
GPollableInputStream and anything else that can potentially block.
Interpret the value "help" for environment variables that
are passed to _g_io_module_get_default(), and print the
names and priorities of available extensions.
This lets users explore what is available, and can be helpful
in figuring out why a certain extension was chosen as default.
It is similar in spirit to what we already do with environment
variables like G_DEBUG.
This is useful for debugging in many situations. It’ll be printed with
G_MESSAGES_DEBUG=GLib-GIO or G_MESSAGES_DEBUG=all.
Mostly I need it for debugging the default GNetworkMonitor, but it will
work for all GIO module implementations.
Signed-off-by: Philip Withnall <withnall@endlessm.com>
When we are in a sandboxed situation, bump the priority
of the keyfile settings backend above the dconf one,
so we use a keyfile inside the sandbox instead of requiring
holes in the sandbox for dconf.
Stacked databases and locks are dconf features that allow
management software like Fleet Commander to set system-wide
defaults and overrides centrally for applications.
This patch adds minimal support for the same to the keyfile
backend. We look for a keyfile named 'defaults' and a
lock-list named 'locks'.
Suitable files can be produced from a dconf database with
dconf dump and dconf list-locks, respectively.
The default location for these files is /etc/glib-2.0/settings/.
For test purposes, this can be overwritten with the
GSETTINGS_DEFAULTS_DIR environment variable.
Writes always go to the per-user keyfile.
Make it possible to instantiate a keyfile settings backend
without specifying parameters, by turning the arguments to
the new() function into construct-only properties. If no
filename is specified, default to
$XDG_CONFIG_HOME/glib-2.0/settings/keyfile
It needs investigating and fixing properly, but let’s not let it disrupt
the CI in the meantime.
Follow-up in https://gitlab.gnome.org/GNOME/glib/issues/1653.
Signed-off-by: Philip Withnall <withnall@endlessm.com>
There's a race here, as revealed by Debian's buildds.
We call g_dbus_proxy_new() to create a proxy for the test server, with
callback proxy_ready() Then we call g_spawn_command_line_async() to
start the test server, and then start the main loop.
proxy_ready() assumes that the test server hasn't been started when it
is called. But there is no guarantee that these asynchronous operations
involving spawning a process won't happen in a different order that mean
the bus name *does* have an owner.
What we can do is move starting the server inside of proxy_ready(), so
we know that the test server isn't started until after the proxy is
created. We also add an assertion to check that it is indeed not running
before we execute it.
Rather than storing it as an invalid value in last_position, store it as
a separate boolean.
This introduces no functional changes, but should fix some warnings from
MSVC.
Signed-off-by: Philip Withnall <withnall@endlessm.com>
https://gitlab.gnome.org/GNOME/glib/issues/1500
If we can't find the mount point for target or tmp (as currently
happens on Launchpad autobuilders, and perhaps relatedly, on a
development system that uses btrfs), that's probably not great but is
not really the point of this test.
Signed-off-by: Simon McVittie <smcv@collabora.com>
In a minimal autobuilder environment, this test could conceivably be
the first thing to refer to ~/.local.
Modified by Iain Lane <laney@debian.org>: Don't try to create ~/.local
from tests, but skip if it doesn't exist.
Signed-off-by: Simon McVittie <smcv@collabora.com>
So long, and thanks for everything. We’re a Meson-only shop now.
glib-2-58 will remain the last stable GLib release series which is
buildable using autotools.
We continue to install autoconf macros for autotools-using projects
which depend on GLib; they are stable API.
Signed-off-by: Philip Withnall <withnall@endlessm.com>
Like for the OpenURI portal, O_PATH file descriptors do not prove access
to the underlying file data. I've used O_RDWR file descriptors here to
mirror the requested read/write permissions.
This change relates to https://github.com/flatpak/xdg-desktop-portal/issues/167
The OpenURI portal requires the caller to pass a file descriptor as
proof of access for local files. Old versions required this file
descriptor to use the O_PATH mode. However, this does not prove access
since you can create O_PATH descriptors for files that you can't read.
Since xdg-desktop-portal 1.0.1, regular file descriptors are also
accepted with O_PATH descriptors restricted to flatpaks for the
transition.
Check for over- and underflow when manipulating positions.
This makes the sequence
g_list_model_get_item (store, 0);
g_list_model_get_item (store, -1u);
return NULL for the second call, as it should.
Closes: #1639
Calling
g_list_model_get_item (store, 0);
g_list_model_get_item (store, -1u);
does not return NULL for the second call, as it should.
This was showing up in GTK+ list model tests.
Since commit 290bb0dd, where various members of GTask were converted to
a bitfield, some of the getters:
• g_task_get_check_cancellable()
• g_task_get_return_on_cancel()
• g_task_get_completed()
have been returning truthy ints (zero or an arbitrary non-zero integer)
as boolean values, rather than the canonical boolean ints of 1 and 0.
This broke the `yield` statement in Vala, whose generated C code
compares `g_task_get_completed (…) != TRUE`. i.e. Whether the
`completed` field has a value not equal to 1.
Fix this by explicitly converting truthy ints to canonical boolean ints
in all getters.
Signed-off-by: Philip Withnall <withnall@endlessm.com>
https://gitlab.gnome.org/GNOME/glib/issues/1636
Names are a message bus feature, so it does not make sense to connect
to NameOwnerChanged when the underlying connection is not a message
bus.
Moreover, g_dbus_connection_signal_subscribe() will also enforce that
condition. Adding this extra check here is helpful to avoid a critical
warning when using GDBusProxy with peer-to-peer connections.
https://gitlab.gnome.org/GNOME/glib/issues/1620
Right now this can only be set at construction but not read back.
That seems unnecessarily restrictive, and we'll need to read these
flags from outside of gdbusconnection.c in the next commit, so let's
just make it public.
https://gitlab.gnome.org/GNOME/glib/issues/1620
Add option to not encode resource data into the C source file
in order to embed the data using `ld -b binary`. This improves compilation
times, but can only be done on Linux or other platforms with a
supporting linker.
(Rebased by Philip Withnall, fixing minor rebase conflicts.)
Fixes#1489
This reverts commit 52bab0254a.
It silently conflicted with another commit,
90ca3b4dd0, which was merged later than
it. I’ve kept commit 90ca3b because it also frees the GError; 52bab
doesn’t.
This is my failure to rebase and test old branches before merging them,
instead of assuming that the lack of automatically detected merge
conflicts actually means there are no merge conflicts.
Allow any type of private key in PEM files by treating PEM guards ending
with "PRIVATE KEY-----" as a private key instead of looking for a
pre-defined set of PEM guards. This enables the possibility for custom
GTlsBackend to add support for new key types.
Test cases have been expanded to ensure PEM parsing works for private
key when either header or footer is missing.
Encrypted PKCS#8 is still rejected. Test case has been added for this to
ensure behaviour is the same before and after this change.
The `apps` subprocess is spawned by desktop-app-info to interpret the
forest of .desktop files, and its output is provided on stdout. If debug
output is mixed up with that output, tests which parse the output fail.
Disable the debug output from the subprocess to prevent this.
The new debug output appeared as a result of recent changes to the
desktop file dir monitoring code in gdesktopappinfo.c.
Signed-off-by: Philip Withnall <withnall@endlessm.com>
The appinfo-test.desktop file is set up with an Exec= path which points
to the compiled and installed appinfo-test utility. When running the
tests uninstalled, however, this might not be present, which causes
loading appinfo-test.desktop to fail.
Split appinfo-test.desktop in two: keep the existing
appinfo-test.desktop for tests which need to launch appinfo-test, and
add a new appinfo-test-static.desktop for tests which don’t launch
anything (and, for example, just inspect GAppInfo properties).
appinfo-test-static.desktop uses an Exec= line which should always be
present (`true`) so it should never fail to load.
Allow the tests using appinfo-test-static.desktop to be run uninstalled
or installed. Allow the tests using appinfo-test.desktop to be skipped
if loading appinfo-test.desktop fails, which is an indicator that the
test is running uninstalled.
Signed-off-by: Philip Withnall <withnall@endlessm.com>
This causes the desktop directory cache to be correctly reloaded between
unit tests if G_TEST_OPTION_ISOLATE_DIRS is in use.
Signed-off-by: Philip Withnall <withnall@endlessm.com>
This allows the list of directories which contain MIME data to be set,
separately from the list of directories returned by
g_get_user_data_home() and g_get_system_data_dirs().
While the latter are overridden for a unit test, we don’t have access to
the system MIME registry, which can sometimes be useful for tests which
need to know about standard MIME associations from shared-mime-info.
Allow g_content_type_set_mime_dirs() to be used from unit tests to allow
them to use the system MIME registry again, or to allow them to be
pointed to another custom registry.
Signed-off-by: Philip Withnall <withnall@endlessm.com>
In order to make xdgmime properly relocatable so that unit tests can use
it without it reading and modifying the user’s actual xdgmime files, and
without the need to call setenv() (and get tied up with thread safety
problems), add a xdg_mime_set_dirs() method to allow the dirs to be
overridden. They will still default to the values of $XDG_DATA_HOME and
$XDG_DATA_DIRS.
Signed-off-by: Philip Withnall <withnall@endlessm.com>
g_assert() is for runtime code, and can be compiled out. g_assert_*()
cannot be compiled out, and give more helpful failure messages for
specific types.
Signed-off-by: Philip Withnall <withnall@endlessm.com>
g_assert() can be compiled out with G_DISABLE_ASSERT, which renders the
test useless. The g_assert_*() functions provide more helpful feedback
on failure too.
Signed-off-by: Philip Withnall <withnall@endlessm.com>
By encoding the path to the appinfo-test binary in the .desktop files,
we can avoid a chdir() call in the tests, which was a bit ugly.
Signed-off-by: Philip Withnall <withnall@endlessm.com>
https://gitlab.gnome.org/GNOME/glib/issues/538
This partially reverts commit 27b5fb5892.
The infrastructure for disabling a test is kept, but the appinfo and
desktop-app-info tests no longer need to be run serially.
Signed-off-by: Philip Withnall <withnall@endlessm.com>
https://gitlab.gnome.org/GNOME/glib/issues/1601
gtk-doc is unhappy that skeleton documentation comments had been written
for these functions (for the introspection annotations) but that the
documentation content was actually missing.
Add that content. I like a happy gtk-doc.
Signed-off-by: Philip Withnall <withnall@endlessm.com>
This partially reverts commit 799f8dcd46.
This patch seems to break the writability status of the server socket: once
somebody writes to it with success, then it reports it is not writable
anymore. Also, when the client socket has the flag FD_CONNECT set once,
it is never cleared and then it reports it is always writable, also when
it is not.
This checks if the stream is writable before writing
to it. If the write succeeded with no error, then the
stream has to be also writable after the write
Currently a new connection will not be attempted until the previous
one has timed out and as the current API only exposes a single
timeout value in practice it often means that it will wait 30 seconds
(or forever with 0 (the default)) on each connection.
This is unacceptable so we are now trying to follow the behavior
RFC 8305 recommends by making multiple connection attempts if
the connection takes longer than 250ms. The first connection
to make it to completion then wins.
As RFC 8305 recommends we can start multiple DNS queries in parallel
to more quickly make an initial response, especially when one is
particularly slow/broken.
This allows higher levels to have more control over resolving
(ipv4 or ipv6 for now) which allows for optimizations such
as requesting both in parallel as RFC 8305 recommends.
This means the output (including lists of filenames) does not depend on
the order of the input files, which may matter if this tool is invoked
with a glob or some other mechanism that doesn't guarantee an order.
Turns out the fix in commit 93555577c wasn't enough, when using glib as
subproject and the parent project uses only libgio_dep, and include
<gi18n.h>, it won't find libintl.h because it's in the
include_directories of libglib_dep. Fix that by declaring dependencies
explicitly, which is the right thing to do since glib and gobject are
public dependencies of gio. That reflects what we do for the pkg-config
file as well.
Previously, method and signal arguments were sorted by name, which
(assuming you don't happen to give your arguments
lexicographically-ordered names) means the generated signatures were
incorrect when there is more than 1 argument.
While sorting the methods and signals themselves (and properties, and
annotations on all these) is fine, it's easiest to not sort anything.
Since 1217b1bc4f, LICENSE_STR has taken two
parameters, not one. Without this change, running either mode fails
with a traceback like:
Traceback (most recent call last):
File "../gdbus-codegen", line 55, in <module>
sys.exit(codegen_main.codegen_main())
File ".../codegen_main.py", line 294, in codegen_main
gen.generate()
File ".../codegen.py", line 896, in generate
self.generate_body_preamble()
File ".../codegen.py", line 682, in generate_body_preamble
self.outfile.write(LICENSE_STR.format(config.VERSION))
IndexError: tuple index out of range
8916874ee6, which introduced these flags,
was actually merged after that commit, but I assume it was written
beforehand.
This is to ensure that the generated code is still compilable by the
running compiler, and see whether we can read the things in there
properly.
See issue #1580.
glib-compile-resources was updated to generate octal byte
representation in a string, but unfortunately this breaks the build
on Visual Studio when the generated string sequence exceeds 65535
characters, which is the imposed limit on Visual Studio compilers.
To make things work on Visual Studio builds and to not slow down things
on other compilers, generate a code path for Visual Studio an array of
octal byte representations, as well as a code path for other compilers
that use the new string representation of octal values, and let the
compiler take the appropriate code path when compiling the
generated code.
Fixes issue #1580.
While uniqueness is great, sometimes you want to restart
a newer version of the same app. These two flags make that
possible.
We also add a ::name-lost signal, that is emitted when it
happens. The default handler for this signal just calls
g_application_quit(), but applications may want to connect
and do cleanup or state-saving here.
When using glib as subproject we are forced to pass glib_dep,
gobject_dep and gio_dep to any build target. If we pass only gio_dep it
will missing include directory for glib and gobject.
Putting the raw URIs in the documentation comments would not link them,
and the ‘%20’s in the URIs were being parsed by gtk-doc as symbol
references. Fix that by using Markdown to format them correctly as
links.
Signed-off-by: Philip Withnall <withnall@endlessm.com>
Using `%` indicates that you’re linking to a symbol. In these cases we
wanted some nicely formatted literals, or a link to a specific property.
Use backticks for the literals, and link to the property fully.
Signed-off-by: Philip Withnall <withnall@endlessm.com>
Due to the line wrapping, gtk-doc was interpreting this second line as
redefining the @dbus_register documentation.
Signed-off-by: Philip Withnall <withnall@endlessm.com>
Otherwise they fill your real ~/.config/mimeapps.list with rubbish and
race for access to it. This is arguably not good.
Signed-off-by: Philip Withnall <withnall@endlessm.com>
https://gitlab.gnome.org/GNOME/glib/issues/1514
If a D-Bus interface was annotated with o.fd.DBus.Deprecated, then the
corresponding GObject property, in the common GInterface implemented
by the generated GDBusObjectProxies and GDBusObjectSkeletons, to
access the generated code for the D-Bus interface was not being marked
with G_PARAM_DEPRECATED, even though the gtk-doc snippet had the
'Deprecated: ' tag.
G_PARAM_DEPRECATED is older than gdbus-codegen, 2.26 and 2.30
respectively, hence it can be used unconditionally.
https://gitlab.gnome.org/GNOME/glib/merge_requests/485
If a D-Bus interface has a property that's annotated with
o.fd.DBus.Deprecated, then the corresponding GObject property was not
being marked with G_PARAM_DEPRECATED, even though the gtk-doc snippet
had the 'Deprecated: ' tag.
G_PARAM_DEPRECATED is older than gdbus-codegen, 2.26 and 2.30
respectively, hence it can be used unconditionally.
https://gitlab.gnome.org/GNOME/glib/merge_requests/485
Allowing unsafe rehandshakes used to be required for web compatibility,
but this is no longer a concern in 2018. So there should no longer be
compatibility benefits to calling this function. All it does is make
your TLS connection insecure.
Also, rehandshaking no longer exists at all in TLS 1.3.
At some point (maybe soon!) glib-networking will begin ignoring the
rehandshake mode, so let's deprecate it now.
Let's entirely deprecate calling this function for rehandshaking. The
current documentation is OK, but guarantees defined behavior (to attempt
a rehandshake) when TLS 1.2 is in use. But there's no way to force TLS
1.2, and also no way to check which version of TLS is in use. I really
should have deprecated use of this function for rehandshaking entirely
last time I updated it.
Fortunately, there should be no compatibility risk for existing code,
because rehandshaking has no visible effects at the API level.
With the changes to limit GVariant type nesting (commit 7c4e6e9fbe),
it’s now possible to have a valid type signature which is not a valid
GVariant type when enclosed in parentheses (to make it a tuple).
Check for that when parsing the signature field in a D-Bus message.
Includes a unit test.
oss-fuzz#11120
Signed-off-by: Philip Withnall <withnall@endlessm.com>
This test is intended to verify the fix for
https://bugzilla.gnome.org/show_bug.cgi?id=787731, which was that
g_file_query_filesystem_info() would return stale information for the
mount. After replacing a read-only mount with a read-write mount, this
test used to only fail if G_FILE_ATTRIBUTE_FILESYSTEM_READONLY was TRUE
and yet the file could be opened for writing. In particular, if (due to
a test bug) the file really was still on a read-only filesystem, the
test would pass.
Now that we have fixed that bug in the test, we can make a stronger
assertion.
fusermount -z behaves like umount --lazy, which is documented thus:
> Detach the filesystem from the file hierarchy now, and clean up all
> references to this filesystem as soon as it is not busy anymore.
Without this, the call to `fusermount -u` often fails with:
/usr/bin/fusermount: failed to unmount /home/wjt/src/gnome/glib/_build/dir_bindfs_mountpoint: Device or resource busy
which causes the subsequent call to bindfs to fail:
fuse: mountpoint is not empty
fuse: if you are sure this is safe, use the 'nonempty' mount option
It's not clear what is causing the mount to be busy. Inserting a
g_usleep (100 * 1000) before the calls to `fusermount -u` also works to
make the problem go away, but for the purposes of this test the
important point is that the mount is detached from the directory, for
which a lazy unmount is fine.
Fixes#1590.
In practice, fusermount -u often fails:
/usr/bin/fusermount: failed to unmount /home/wjt/src/gnome/glib/_build/dir_bindfs_mountpoint: Device or resource busy
which causes the subsequent calls to bindfs to fail:
fuse: mountpoint is not empty
fuse: if you are sure this is safe, use the 'nonempty' mount option
This may or may not cause the current test run to fail, but it reliably
causes a repeat run of the test to fail. This change causes the current
run to fail instead.
I made a mistake when last updating the documentation in 94a99ae9. I
wrote that, with TLS 1.3, this would perform a rekey instead of a
rehandshake. In fact, that's only true for client connections. For
server connections, it's a no-op.
I was a bit nervous about how to document the behavior anyway, because
we really don't know what behavior will be reasonable with non-GnuTLS
crypto backends. This behavior is reasonable for the GnuTLS backend, but
might not necessarily make sense for OpenSSL. Ideally, we would
discourage API users from doing things which could have unexpected
effects, so instead of documenting what the GnuTLS backend does, I think
it'd be better to document that this is "undefined but not dangerous,"
since of course we want to make sure that existing code that doesn't
know about TLS 1.3 is not broken.
The docs sound like settings list is a thing, and
a ::children-changed signal exists. That is not the
case, and will never be the case at this point, so
stop pretending.
Closes: #1362
Currently, GDBusProxy:g-name-owner only notifies changes to the unique
name owner of the remote object in case the proxy was constructed for a
well-known name.
That sounds like an artificial restriction, and it's convenient to
connect to notify::g-name-owner if a proxy instance has already been
created for an unique name, instead of additionally using
g_bus_watch_name() to track the owner.
To fix this, always connect to NameOwnerChanged after the proxy is
initialized, instead of only doing so when the proxy was constructed for
a well-known name.
https://bugzilla.gnome.org/show_bug.cgi?id=791316https://gitlab.gnome.org/GNOME/glib/issues/1310
test_c_args is defined in the root meson.build with unfiltered list of
compiler flags, then redefined in gio/tests/meson.build after the
subdir() call. Move it before.
The length of the stolen data from a memory output stream is given by
get_data_size() — get_size() can be larger, and hence cause unnecessary
overallocation.
Similarly to g_source_set_name(), this sets a name on a GTask for
debugging and profiling. Importantly, this name is propagated to the
GSource for idle callbacks for the GTask, ending the glorious reign of
`[gio] complete_in_idle_cb`.
The name can be queried using g_task_get_name(). Locking is avoided by
only allowing the name to be set before the GTask is used from another
thread.
Includes tests.
Signed-off-by: Philip Withnall <withnall@endlessm.com>
This is the most degenerate possible test but it does exercise this code
path.
(Tweaked by Philip Withnall <withnall@endlessm.com> to also add the flag
to the autotools build.)
The executable depends only on the generated header file at compile
time, and on the library at link time. So meson can decide to compile
gdbus-peer.c before compiling the library and thus won't have generated
the header yet, causing the build error.
So declare_dependency() should only have the header file in its sources,
to force generating files before compiling gdbus-peer.c without
including objectmanager-gen.c into gdbus-peer's sources.
