The WSAEnumNetworkEvents API is called every time the socket
needs to be checked for status changes. Doing this in an application
with several sockets could generate a high cpu usage since
this call is done for each socket at each iteration of the main loop.
Since there is also a WSAEvent that gets signaled when there is
a change in the status of the socket, checking its status and
calling the WSAEnumNetworkEvents API only if the event is signaled,
can reduce the overall cpu usage.
This was one of the code paths not currently covered by unit tests, so
let’s add a test for it.
This tests what happens when a structurally valid GResource file, but
with a corrupt entry for a compressed file, is loaded.
Signed-off-by: Philip Withnall <pwithnall@gnome.org>
Helps: #3465
This is slightly more involved than the previous couple of commits, as
`g_resource_lookup_data()` can return two errors: one if the resource is
not found, and another if decompression fails.
We want to avoid allocating the `G_RESOURCE_ERROR_NOT_FOUND` error, as
`g_resources_lookup_data()` will be looping through multiple
`GResource`s trying to find the given path, and all but one of them will
return `G_RESOURCE_ERROR_NOT_FOUND`. For a large application, this can
amount to a lot of `GError`s allocated and then immediately freed on
startup.
Use the split from the previous commit to replace the call to
`g_resource_lookup_data()` with its two constituent parts. We can then
handle errors from them separately, ignoring the `NOT_FOUND` error from
`do_lookup()`, while paying attention to any errors from
`resource_to_bytes()`.
This should result in no functional difference to
`g_resources_lookup_data()`, but fewer allocations overall.
Spotted by Christian Hergert.
Signed-off-by: Philip Withnall <pwithnall@gnome.org>
Helps: #3465
It’s now a call to `do_lookup()` followed by a call to
`resource_to_bytes()`. This makes no functional changes, but will be
useful in the following commit.
Signed-off-by: Philip Withnall <pwithnall@gnome.org>
Helps: #3465
As with the previous commit:
The error here can only ever be `G_RESOURCE_ERROR_NOT_FOUND`, which
`g_resources_get_info()` immediately frees. So let’s avoid allocating
the error in the first place.
Spotted by Christian Hergert.
Signed-off-by: Philip Withnall <pwithnall@gnome.org>
Helps: #3465
The error here can only ever be `G_RESOURCE_ERROR_NOT_FOUND`, which
`g_resources_open_stream()` immediately frees. So let’s avoid allocating
the error in the first place.
Spotted by Christian Hergert.
Signed-off-by: Philip Withnall <pwithnall@gnome.org>
Helps: #3465
This makes it a bit easier to make sure all the translatable strings are
kept in sync. It introduces no functional changes.
Signed-off-by: Philip Withnall <pwithnall@gnome.org>
Helps: #3465
The test in `unix-mounts` to see whether `g_unix_mounts_get_from_file()`
can parse an example file was working fine when GLib is built with
libmount, but not when built without it (and hence typically using
`getmntent()`).
This is because libmount supports mountinfo files (like
`/proc/self/mountinfo`), but `getmntent()` only supports mount files
(like `/proc/mounts`). The test was written only with the former.
So, change the test to use mount files when GLib is built without
libmount support.
Signed-off-by: Philip Withnall <pwithnall@gnome.org>
Fixes: #3456
This kind of deeply nested menu is definitely no longer good UI practice
for most apps (deeply nested menus make things hard to find, and require
good mouse control to navigate). However, it does serve as a good
demonstration of the concepts in `GMenuModel`, so keep it, with a
sentence to acknowledge that it’s not a good UI.
Signed-off-by: Philip Withnall <pwithnall@gnome.org>
Fixes: #3451
These tests are expected to cause a thread to deadlock. That seems to be
fine with glibc on Linux, but the glibc version on FreeBSD can detect
the deadlock, and aborts the whole test process with:
```
GLib (gthread-posix.c): Unexpected error from C library during 'pthread_mutex_lock': Resource deadlock avoided. Aborting.
```
This is fair enough.
To avoid this causing the test suite to fail, run those two tests in
subprocesses. This also means we’re not carrying a deadlocked thread
around for the rest of the test suite.
Improves on commit 62192925b6.
Signed-off-by: Philip Withnall <pwithnall@gnome.org>
Provide examples of what they all represent, and expand on the
descriptions of them in a few places.
Move references to their equivalents from `GnomeVFS` to lower down in
the documentation, since `GnomeVFS` has been deprecated for many years
now, and is unlikely to be pertinent to most readers.
Signed-off-by: Philip Withnall <pwithnall@gnome.org>
When listing schemas from a specified directory, explicitly
create the GSettings object from the schema, don't allow g_settings_new
to do the usual lookup. That lookup fails if no other schemas are
installed in the default directories.
Fixes#3429.
This can never have been tested, it was returning `GUnixMountEntry`
structs from functions which are typed to return `GUnixMountPoint`s.
Signed-off-by: Philip Withnall <pwithnall@gnome.org>
While GLib doesn’t parse these files, it does provide API to access the
fields from them, and does implement some logic based on options fields
in them. It would be nice to be able to test that, and get coverage of
the methods for `GUnixMountPoint` and `GUnixMountEntry`.
We don’t expect users to start querying the fstab or mtab by explicitly
loading data from those file paths. These functions are mainly intended
to prove a controllable entry point into the `gunixmounts.c` code for
unit testing.
It means we can provide a file with controllable contents in order to
test the mount entry/point code on.
See: https://gitlab.gnome.org/GNOME/glib/-/merge_requests/4155
Signed-off-by: Philip Withnall <pwithnall@gnome.org>
You may not always know which schemes are available.
The library should not bail out, but only show
an informal message. It's the responsibility of
the application to deal with invalid URI schemes.
The test brings a Finder window to the front. It's not ideal,
but I have no better idea at the moment. It would be cool if we
can make the test case register itself as handler for a particular
uri scheme, but I have no idea how to do that.
I answered a question on irc about withdrawing notifications, and
when I handed out a link to the GApplication docs, I noticed we
don't have this function name linkified. Fix that.
On Wayland the activation token returned by
`g_app_launch_context_get_startup_notify_id()` doesn't depend on the
`GAppInfo`. The token is only used to hand over focus to the
application that is launched. In some cases it's not even possible to know
what application will actually be used to open the files. For example
when using portals within a sandbox. Therefore, allow providing no
`GAppInfo`.
This also makes clear in the docs that the `files` argument can be `NULL`.
We want to add the support for the activation token, to get it we use
`g_app_launch_context_get_startup_notify_id` which takes a list of
files, so that we don't have to create a GFile twice simply change the
signature of the functions. Fortunately this isn't a public API.
This file doesn’t contain any real implementation, it just call the
`impl` functions from the platform-specific files
`gcontenttype-{fdo,osx,win32}.[cm]`.
It serves as a location for the doc comments, introspection annotations
and API preconditions, and will be built on every platform. In
particular, this means that we get consistent GIR output for the
`g_content_type_*()` APIs regardless of whether GLib was built on Linux or
Windows or macOS.
Signed-off-by: Philip Withnall <pwithnall@gnome.org>
Helps: #3399
This reflects its status as actually platform-dependent: it’s only built
on systems using the freedesktop.org content type system.
It makes the file naming match up with other platform-specific
implementations, such as `gcontenttype-win32.c` and
`gcontenttype-osx.m`.
A subsequent commit will introduce a platform-independent high level API
wrapper so that the introspection annotations from this file can be
reused between platforms.
Signed-off-by: Philip Withnall <pwithnall@gnome.org>
Helps: #3399
Previously, some of the doc comments for platform-independent APIs were
in `gdesktopappinfo.c`, which is only built on Unix systems. This meant
the introspection annotations for those APIs were not used on non-Unix
systems, which caused platform differences in `Gio-2.0.gir`.
So, move those doc comments to `gappinfo.c` and put them next to some
new platform-independent wrapper functions which provide a consistent
entry point and location for the API preconditions.
Signed-off-by: Philip Withnall <pwithnall@gnome.org>
Helps: #3399
On g_cancellable_cancel() we were increasing the GCancellable ref count
before emitting the ::cancelled signal, this is a safe thing to do but
it was happening while the cancellable was locked, and this may have
potentially waken up some toggle notifications.
To prevent this, reference the GCancellable just before locking.
GCancellable is meant to be used in multi-thread operations but all the
cancellable instances were sharing a single mutex to synchronize them
which can be less optimal when many instances are in place.
Especially when we're doing a lock/unlock dances that may leave another
thread to take the control of a critical section in an unexpected way.
This in fact was leading to some races in GCancellableSources causing
leaks because we were assuming that the "cancelled" callback was always
called before our dispose implementation.
As per this, use per-instance mutexes.
The lock is also now used only to protect the calls that may interact
with cancelled state or that depends on that, as per this we can just
reduce it to the cancel and reset case, other than to the connect one to
prevent the race that we could have when connecting to a cancellable
that is reset from another thread.
We don't really need to release the locks during callbacks now as they
are per instance, and there's really no function that we allowed to call
during a ::cancelled signal callback that may require an unlocked state.
This could been done in case with a recursive lock, that is easy enough
to implement but not really needed for this case.
Fixes: #2309, #2313
Currently, the trash functionality is disabled for system internal mounts.
That might be a problem in some cases. The `x-gvfs-notrash` mount option
allows disabling the trash functionality for certain mounts. Let's add
support for the `x-gvfs-trash` mount option to allow the opposite.
See: https://issues.redhat.com/browse/RHEL-46828
We can only use the [class@Foo.Bar] syntax for identifiers under
namespaces included by the current namespace. Naturally, we cannot
include the GDK namespace.
Use a direct link for this instead.
Adjust all docs to use the gi-docgen referencing syntax, reindent
some of the comments, and add missing annotations to some async
methods.
The error arguments are not necessary with gi-docgen so they're
removed.
Confusingly enough, the docks for GAppInfo is spread between two
files.
This fixes commit cdcb179808.
`dn_comp()` is needed to build fake DNS records for most of the tests in
this file. The new ownership test is no exception.
See https://gitlab.gnome.org/GNOME/glib/-/jobs/4058481
Signed-off-by: Philip Withnall <pwithnall@gnome.org>
On Linux the error will be `G_IO_ERROR_CONNECTION_REFUSED`, but on macOS
it will be `G_IO_ERROR_TIMED_OUT`. Both errors seem reasonable to me, so
let’s not specifically require one of them.
See: https://gitlab.gnome.org/GNOME/glib/-/merge_requests/4104#note_2161451
Signed-off-by: Philip Withnall <pwithnall@gnome.org>
This should have been dropped in commit
38faeca62e but somehow that didn’t happen
and somehow it wasn’t caught by the CI until afterwards.
Fixes: https://gitlab.gnome.org/GNOME/glib/-/jobs/4049254
Signed-off-by: Philip Withnall <pwithnall@gnome.org>
For each test expected to return valid DNS records, test that the
record variants are not floating references.
Also add an test which checks this explicitly for a simple TXT record.
The return value to `lookup_records()` methods is set as `transfer full`
but the code path in `g_resolver_records_from_res_query()` doesn't
sink the GVariant.
Add the `g_variant_ref_sink()` call when prepending the record, so
the list hold a full reference on each records.
closes#3393
- Add licensing tags
- Tweak spacing, colors, line thicknesses
- Create light-mode version
- Use `<picture>` tag to include appropriate version for each media
color scheme.
Recreate the `menu-model.png` diagram in SVG, with box outlines and
connectors recolored from black to white. This will allow the diagram
to show up better in the dark documentation theme.
By keeping `expected` as a `double` for longer, we avoid having to cast
when populating the elements of `ordering`, to avoid
`-Wfloat-conversion` warnings.
Signed-off-by: Philip Withnall <pwithnall@gnome.org>
Helps: #3405
If we enable `-Wfloat-conversion`, these warn about a possible loss of
precision due to an implicit conversion from `double` to some other
numeric type.
The warning is correct: there is a possible loss of precision here. In
these instances, we don’t care, as the floating point arithmetic is
being done to do some imprecise scaling or imprecise timing. A loss of
precision is not a problem.
So, add an explicit cast to squash the warning.
Signed-off-by: Philip Withnall <pwithnall@gnome.org>
Helps: #3405
When the file name is too long (for example, more than 238 bytes on
ext4), this will cause the creation of the .trashinfo file to fail.
Let's shorten the .trashinfo filename in this case, after all the
trash specification only requires unique filenames (see
`Contents of a trash directory` section in
https://specifications.freedesktop.org/trash-spec/trashspec-latest.html).
This should test the limits of loading 4GB files on i386 platforms, such
as the Hurd CI runner. On such platforms, `sizeof(size_t) == 4`.
This should fix the compiler warning from
https://gitlab.gnome.org/GNOME/glib/-/jobs/3989442:
```
../gio/tests/file.c:2931:51: error: left shift count >= width of type [-Werror=shift-count-overflow]
2931 | static const gsize testfile_4gb_size = ((gsize) 1 << 32) + (1 << 16); /* 4GB + a bit */
| ^~
cc1: all warnings being treated as errors
```
Signed-off-by: Philip Withnall <pwithnall@gnome.org>
They take too long to include in a normal test run. They’ll still be run
in CI once a week as part of our scheduled slow test job.
Signed-off-by: Philip Withnall <pwithnall@gnome.org>
The tests - one for sync, one for async - create a sparse file for
this purpose, so this should be cheap on the fileystem.
Of course, the test still allocates >4GB of memory for the data that it
returns from g_file_load_contents(), I hope the CI test runners can deal
with that.
GByteArray is limited to 4GB in size and the current code silently
overflows when that happens.
Replace both load_contents() and load_contents_async() implementations
with a version that uses realloc() and gsize to maintain the array.
Disable tests that require update-desktop-database when it is missing.
It requires glib to build so it will be missing when bootstrapping glib.
Refactor the ifdef for Windows and MacOS while at it and reduce number
of ifdefs.
Ref: https://gitlab.gnome.org/GNOME/glib/-/merge_requests/3658
Signed-off-by: Natanael Copa <ncopa@alpinelinux.org>
shared-mime-info required glib to build and will not be there during
bootstrap. Skip the test if it is missing.
ref: https://gitlab.gnome.org/GNOME/glib/-/issues/3317
Signed-off-by: Natanael Copa <ncopa@alpinelinux.org>
Previously it was mapped (as a default) to `G_IO_ERROR_FAILED`.
It’s the error that macOS returns when trying to connect to a socket which
is bound but not listened to. Linux returns `ECONNREFUSED` in this case.
It’s helpful if they both map to the same `GIOError` value.
This should fix the `/socket-client/connection-fail` test on macOS,
which is currently
[failing](https://gitlab.gnome.org/GNOME/glib/-/jobs/3970547) with:
```
# GLib-GIO-DEBUG: GSocketClient: Starting TCP connection attempt
# GLib-GIO-DEBUG: GSocketClient: Connection attempt failed: Can't assign requested address
# GLib-GIO-DEBUG: GSocketClient: Starting new address enumeration
# GLib-GIO-DEBUG: GSocketClient: Address enumeration completed (out of addresses)
# GLib-GIO-DEBUG: GSocketClient: Address enumeration failed: (null)
# GLib-GIO-DEBUG: GSocketClient: Connection failed: Could not connect to localhost: Can't assign requested address
not ok /socket-client/connection-fail - GLib-GIO:ERROR:../gio/tests/gsocketclient-slow.c:231:test_connection_failed: assertion failed (local_error == (g-io-error-quark, 39)): Could not connect to localhost: Can't assign requested address (g-io-error-quark, 0)
Bail out!
```
Signed-off-by: Philip Withnall <pwithnall@gnome.org>
See: #3184Fixes: #3394
Once the task is completed (and `g_task_return_*()` has been called),
the task is no longer needed. It would make more sense to unref it in
`complete_connection_with_error()`, where `g_task_return_*()` is called,
but that complicates other call sites significantly, so I didn’t do it.
Signed-off-by: Philip Withnall <pwithnall@gnome.org>
Fixes: #3184
While backporting CVE-2024-34397 fixes I noticed that this comment
claimed that the reference count is immutable after construction, which
is clearly not true. In fact the reference count is the only
mutable field.
Signed-off-by: Simon McVittie <smcv@collabora.com>
To avoid adding a large block of macros to gdbusprivate.h, I've only
added a subset of the well-known error names. I chose to draw the
line by adding constants for the errors emitted via their string names
in GDBusConnection, but not for error names that are only mentioned
in `gdbuserror.c` or in tests.
Signed-off-by: Simon McVittie <smcv@collabora.com>
Most D-Bus interfaces are domain-specific, but these interfaces from the
D-Bus Specification are intended to be commonly used in any context for
which they are found to be appropriate.
Most of these use `gdbusprivate.h`. One exception is that
`gio/tests/gdbus-example-*` redefine the constants locally: due to these
files' dual role as part of the unit tests and as sample code, it seems
desirable to ensure that they can still be compiled outside GLib.
Signed-off-by: Simon McVittie <smcv@collabora.com>
These well-known flags and replies are part of the D-Bus Specification,
and also exist with the same names in libdbus header files.
Moving them into a private header means that unit tests like
gdbus-proxy-threads and gdbus-subscribe don't have to reinvent them.
Signed-off-by: Simon McVittie <smcv@collabora.com>
Unlike the various functions to call D-Bus methods, these sort their
arguments in a non-obvious order (bus name, interface, signal, path),
presumably aiming to sort the most-likely-to-be-used arguments first.
Signed-off-by: Simon McVittie <smcv@collabora.com>
These function arguments are arranged in the obvious order from
conceptually largest to smallest: (bus name, path, interface, method).
Signed-off-by: Simon McVittie <smcv@collabora.com>
This test was subscribing to the NameOwnerChanged signal with an
incorrect object path, so the callback would never be called. In this
particular case it doesn't actually matter, because the callback does
nothing anyway (the purpose of this particular test was to test that
the user-data is freed on unsubscription).
Signed-off-by: Simon McVittie <smcv@collabora.com>
Almost identically to the previous commit, fix a similar latent bug in
`g_dbus_connection_export_action_group()`, which was not ready to handle
the fledgling `GActionGroupExporter` being freed early on an error
handling path.
See the previous commit message for details of the approach.
This includes a unit test.
Signed-off-by: Philip Withnall <pwithnall@gnome.org>
Fixes: #3366
This latent bug wasn’t triggered until commit 3f30ec86c (or its
cherry-pick onto `glib-2-80`, 747e3af99, which was first released in
2.80.1).
That change means that `g_menu_exporter_free()` is now called on the
registration failure path by `g_dbus_connection_register_object()`
before it returns. The caller then tries to call `g_slice_free()` on the
exporter again. The call to `g_menu_exporter_free()` tries to
dereference/free members of the exporter which it expects to be
initialised — but because this is happening in an error handling path,
they are not initialised.
If it were to get any further, the `g_slice_free()` would then be a
double-free on the exporter allocation.
Fix that by making `g_menu_exporter_free()` robust to some of the
exporter members being `NULL`, and moving some of the initialisation
code higher in `g_dbus_connection_export_menu_model()`, and removing the
duplicate free code on the error handling path.
This includes a unit test.
Signed-off-by: Philip Withnall <pwithnall@gnome.org>
Fixes: #3366
gio/glocalfileinfo.c has a struct 'ThumbMD5Context'
that's been unused since
commit d013d46b98 ("Replace the copy-and-paste MD5 digest generation
with GChecksum.")
Remove it.
Signed-off-by: Dr. David Alan Gilbert <dave@treblig.org>
It's an array containing the list of sanitizers in use, normally it
contains a value, but in some cases may have more than one (e.g.
'address' and 'undefined').
And so use it to avoid repeated checks
In glocalfile we're allocating some temporary strings but we don't free
them on early returns, so free them once done and unset the variables
to prevent them being used incorrectly.
It looks like that finally also valgrind notices the same leaks as
address sanitizer does. It does it more randomly but it still happens,
so better to inform about until #2309 is resolved.
We're now caching arg0 but such value is not cleared when a new body is
set as it's in the connection filter test cases where we've a leak as
highlighted by both valgrind and leak sanitizer
In a D-Bus-Specification-compliant message bus, the owner of a well-known
name is a unique name. However, ibus has its own small implementation
of a message bus (src/ibusbus.c) in which org.freedesktop.IBus is
special-cased to also have itself as its owner (like org.freedesktop.DBus
on a standard message bus), and connects to that bus with the
G_DBUS_CONNECTION_FLAGS_MESSAGE_BUS_CONNECTION flag. The ability to do
this regressed when CVE-2024-34397 was fixed.
Relax the checks to allow the owner of a well-known name to be any valid
D-Bus name, even if it is not syntactically a unique name.
Fixes: 683b14b9 "gdbus: Track name owners for signal subscriptions"
Resolves: https://gitlab.gnome.org/GNOME/glib/-/issues/3353
Bug-Debian: https://bugs.debian.org/1070730
Bug-Debian: https://bugs.debian.org/1070736
Bug-Debian: https://bugs.debian.org/1070743
Bug-Debian: https://bugs.debian.org/1070745
Signed-off-by: Simon McVittie <smcv@debian.org>
The test case assumes signals will dispatched in a different order than
they're subscribed. In fact, signals can be dispatched in any order,
and are often dispatched in order.
This commit reorders the subscriptions so they're in order, which is
more logical, and also changes the code to only exit the event loops
when there are no pending handlers ready to dispatch.
This was highlighted (but not introduced) by
0144feb41f. Previously the test coverage
didn’t cover this branch, I think.
`iter` was leaked, and at this point `parameter` had never been set, so
clearing it was unnecessary.
Signed-off-by: Philip Withnall <pwithnall@gnome.org>
Helps: #3349
GDBusConnection sends each signal to recipients in a separate idle
callback, and there's no particular guarantee about the order in which
they're scheduled or dispatched. For the NameOwnerChanged signal that
reports the name becoming unowned, it's possible that g_bus_watch_name()
gets its idle callback called before the GDBusProxy:g-name-owner
machinery has updated the name owner, in which case the assertion
will fail.
Fixing GNOME/glib#3268 introduced a new subscription to NameOwnerChanged
which can alter the order of delivery, particularly in the case where
G_DBUS_PROXY_FLAGS_NO_MATCH_RULE was used (as tested in
/gdbus/proxy/no-match-rule). The resulting test failure is intermittent,
but reliably appears within 100 repetitions of that test.
Fixes: 511c5f5b "tests: Wait for gdbus-testserver to die when killing it"
Signed-off-by: Simon McVittie <smcv@debian.org>
If the file to be added is on a read-only filesystem, opening read/write
will fail with EROFS. In this case we should fall back to opening it
read-only, the same way we already do if write access is forbidden by
DAC or MAC.
An easy way to reproduce this test failure is to build and test GLib
in a podman container, with its source code read-only and its build
directory read/write:
podman run --rm -it \
-v $(pwd):$(pwd):ro \
-v $(pwd)/_build:$(pwd)/_build:rw \
-w $(pwd) ...
Before this commit, the dbus-appinfo test would fail, because opening
${srcdir}/gio/tests/org.gtk.test.dbusappinfo.flatpak.desktop read/write
would fail with EROFS.
For completeness, give similar handling to the other error codes
documented in Linux open(2) that might succeed if re-attempted using
read-only access: according to that documentation, we could get EPERM
if opening read/write is prevented by fcntl F_ADD_SEALS, or ETXTBSY
if the file is an executable that is currently being run.
Signed-off-by: Simon McVittie <smcv@collabora.com>
This was a bug that existed during development of this branch; make sure
it doesn't come back.
This test fails with a use-after-free and crash if we comment out the
part of name_watcher_unref_watched_name() that removes the name watcher
from `map_method_serial_to_name_watcher`.
It would also fail with an assertion failure if we asserted in
name_watcher_unref_watched_name() that get_name_owner_serial == 0
(i.e. that GetNameOwner is not in-flight at destruction).
Signed-off-by: Simon McVittie <smcv@collabora.com>
The vulnerability reported as GNOME/glib#3268 can be characterized
as: these signals from an attacker should not be delivered to either
the GDBusConnection or the GDBusProxy, but in fact they are (in at
least some scenarios).
Reproduces: https://gitlab.gnome.org/GNOME/glib/-/issues/3268
Signed-off-by: Simon McVittie <smcv@collabora.com>
