As per the previous few commits, explicitly document the established
reference counting semantics of the method call closure for
`g_dbus_connection_register_object_with_closures()`.
This isn’t ideal, but
`g_dbus_connection_register_object_with_closures()` has had these
semantics for 10 years now, and it’s a bit late to change them to
something neater.
Signed-off-by: Philip Withnall <pwithnall@gnome.org>
Helps: #3559
It’s not leaked, it’s transferred forwards to the eventual
`g_dbus_method_invocation_return_*()` call.
Signed-off-by: Philip Withnall <pwithnall@gnome.org>
Helps: #3559
This reverts commit 092fedd5f085a2f1966b5c34befe8b603c1a0f07.
This was not the right change to make, and I shouldn’t have accepted the
MR. The situation is laid out in this comment:
https://gitlab.gnome.org/GNOME/glib/-/issues/2600#note_1385050
tl;dr: The reference on the `GDBusMethodInvocation` which is transferred
in to the `GDBusInterfaceMethodCallFunc` is balanced by a reference
transferred to `g_dbus_method_invocation_return_*()`. This is how the
refcounting has always worked for these functions, and even if we’d
probably arrange things differently if the code was written now, we
can’t change those semantics without breaking API.
In particular, bindings have various bits of custom code to account for
these reference tranfers (since they can’t be represented using
gobject-introspection annotations), so changing the semantics will break
bindings.
Fixes: #3559
The method was correctly returning an error from
`g_data_input_stream_read_line_utf8()` if the line contained invalid
UTF-8, but it wasn’t correctly setting the returned line length to 0.
This could have caused problems if callers were basing subsequent logic
on the length and not the return value nullness or `GError`.
Signed-off-by: Philip Withnall <pwithnall@gnome.org>
oss-fuzz#372819437
ip_mreqn.imr_ifindex is not used correctly by the XNU kernel, and
causes us to bind to the default interface; so fallback to ip_mreq
and set the iface source address (not SSM).
Fixes https://gitlab.gnome.org/GNOME/glib/-/issues/3489
As with the previous commit, this is _always_ defined in `gmacros.h`
and therefore the `#ifndef` will always be 0 even if disabled.
Just use `#if` instead.
Signed-off-by: Philip Withnall <pwithnall@gnome.org>
`SOCKS4_CONN_MSG_LEN` failed to account for the length of the final nul
byte in the connect message, which is an addition in SOCKSv4a vs
SOCKSv4.
This means that the buffer for building and transmitting the connect
message could be overflowed if the username and hostname are both
`SOCKS4_MAX_LEN` (255) bytes long.
Proxy configurations are normally statically configured, so the username
is very unlikely to be near its maximum length, and hence this overflow
is unlikely to be triggered in practice.
(Commit message by Philip Withnall, diagnosis and fix by Michael
Catanzaro.)
Fixes: #3461
Remove cmake as we no longer need to build ninja. We can use the
official wheel now since the runner's Python is 3.9 (before: 3.8).
Use the same comment regarding '--wrap-mode' as in the other jobs.
Download and use official ccache binary.
Add myself to the 'only' section in .gitlab-ci.yml so I can have
CI in my fork.
Disable a few deprecation warnings due to the much newer SDK of
the Apple Silicon machine.
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
This reverts commit 0a8cb10f224ff2dfed14f6500e77cee68ae7d4c4.
Merge request !2765 has caused a thread safety regression in
`GCancellableSource` disposal. It landed too late in the cycle to fix
with any confidence before the 2.82 release, so the changes are being
reverted for the `glib-2-82` branch and 2.82.0 release.
Fixes: #3448
Re-opens: #774, #2309, #2313
This reverts commit 3a07b2abd4006da33cdfb0916b266a21070a47d6.
Merge request !2765 has caused a thread safety regression in
`GCancellableSource` disposal. It landed too late in the cycle to fix
with any confidence before the 2.82 release, so the changes are being
reverted for the `glib-2-82` branch and 2.82.0 release.
Fixes: #3448
Re-opens: #774, #2309, #2313
This reverts commit 54d9c26b34d70be9a1e5519bf03d727334c52e0a.
Merge request !2765 has caused a thread safety regression in
`GCancellableSource` disposal. It landed too late in the cycle to fix
with any confidence before the 2.82 release, so the changes are being
reverted for the `glib-2-82` branch and 2.82.0 release.
Fixes: #3448
Re-opens: #774, #2309, #2313
This reverts commit 6c679fb37a0bfeed7beb42d1b1e3590713eac10c.
Merge request !2765 has caused a thread safety regression in
`GCancellableSource` disposal. It landed too late in the cycle to fix
with any confidence before the 2.82 release, so the changes are being
reverted for the `glib-2-82` branch and 2.82.0 release.
This commit is not problematic, but is built entirely on top of the
problematic MR, so has to be reverted.
Fixes: #3448
Re-opens: #774, #2309, #2313
This reverts commit 365411ea327a5f126896b106fe81a113bc0cc7df.
Since commit 3a07b2abd4006da33cdfb0916b266a21070a47d6, issue 2309 has
been fixed, so we should no longer have failures from valgrind here.
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.
