We used to use a pipe for the dbus daemon stdout to read the defined
address, but that was already requiring a workaround to ensure that dbus
daemon children were then able to write to stdout.
However the current implementation is still causing troubles in some
cases in which the daemon is very verbose, leading to hangs when writing
to stdout.
As per this, just don't handle stdout ourself, but use instead a
specific pipe to get the address address. That can now be safely closed
once we've received the data we need.
This reverts commit d80adeaa96.
Fixes: #2537
The code in `g_dbus_message_new_from_blob()` has now been fixed to
correctly error out on all truncated messages, so there’s no need for an
arbitrary programmer error if the input is too short to contain a valid
D-Bus message header.
Signed-off-by: Philip Withnall <pwithnall@endlessos.org>
Helps: #2528
Perform strict bounds checking when reading data from the D-Bus message,
and propagate errors to the callers.
Previously, truncated D-Bus messages could cause out-of-bounds reads.
This is a security issue, but one which is only exploitable when
communicating with an untrusted peer (who might send malicious
messages). Almost all D-Bus traffic is with a session or system bus,
where the dbus-daemon or dbus-broker is trusted, and is known to have
already rejected malformed (malicious) messages.
Accordingly, this is only exploitable with peer-to-peer D-Bus
conversations with an untrusted peer.
(Includes some minor cleanups from Philip Withnall.)
oss-fuzz#17408
Fixes: #2528
Since
https://gitlab.gnome.org/GNOME/glib-networking/-/merge_requests/173,
there is now a really surprising implication to using a non-default
GTlsDatabase: your database could do nothing at all other than wrap the
default database, which you would expect to result in no behavior
changes, but in fact it causes fewer security checks to be performed
during certificate verification. This is because certificate
verification moved from GTlsDatabase to GTlsConnection, allowing for
more security checks to be performed. But if using a non-default
GTlsDatabase, we have to fall back to letting GTlsDatabase to the
verification, as before.
This is the best we can do. It's not a regression for applications,
because it means applications get the previous pre-2.72 behavior. But it
does mean that new security checks added in 2.72 are not applied, which
is unfortunate, so we should warn developers about this.
This feature has been reverted for now because I messed up the
implementation and it was doing sync I/O during async API calls. Oops!
Since it's not present in 2.70 nor in 2.72, let's remove the reference
to the exact GLib version that this behavior was introduced in. I'd like
to get it working properly for 2.74, but it's not ready yet and just
changing the version to 2.74 feels optimistic.
Rather than waiting for a fixed period of time, poll in a loop until the
condition the test is expecting is true.
A better solution would be to use a `GSource` and wait until that’s
dispatched. But doing so might affect the behaviour of the
`GInputStream` under test, so busy-wait instead.
Fixes this CI failure: https://gitlab.gnome.org/GNOME/glib/-/jobs/1630758
```
(some socket debug output)
Bail out! GLib-GIO:ERROR:../gio/tests/converter-stream.c:1037:test_converter_pollable: assertion failed (res == -1): (1 == -1)
```
I could not reproduce the failure remotely with a few hundred
invocations of the test, so it might only present itself on BSD, which
presumably has different socket timing behaviour from Linux.
Signed-off-by: Philip Withnall <pwithnall@endlessos.org>
gio/tests/gio-du.c: In function 'main':
gio/tests/gio-du.c:74:11: error: parameter 'argc' set but not used
74 | main (int argc, char **argv)
| ~~~~^~~~
gio/ginputstream.c: In function 'g_input_stream_real_skip':
gio/ginputstream.c:433:31: error: comparison of integer expressions of different signedness: 'goffset' {aka 'long long int'} and 'long long unsigned int'
433 | (start + count) > (guint64) end)
| ^
gio/gwin32appinfo.c: In function 'uwp_package_cb':
gio/gwin32appinfo.c:3383:17: warning: comparison of integer expressions of different signedness: 'gint' {aka 'int'} and 'guint' {aka 'unsigned int'}
for (i = 0; i < supported_extgroups->len; i++)
^
gio/gwin32appinfo.c:3389:29: warning: comparison of integer expressions of different signedness: 'gint' {aka 'int'} and 'guint' {aka 'unsigned int'}
for (i_ext = 0; i_ext < grp->extensions->len; i_ext++)
^
gio/gwin32appinfo.c:3430:35: warning: comparison of integer expressions of different signedness: 'gint' {aka 'int'} and 'guint' {aka 'unsigned int'}
for (i_verb = 0; i_verb < grp->verbs->len; i_verb++)
^
gio/gwin32appinfo.c:3463:33: warning: comparison of integer expressions of different signedness: 'gint' {aka 'int'} and 'guint' {aka 'unsigned int'}
for (i_hverb = 0; i_hverb < ext->verbs->len; i_hverb++)
^
gio/gwin32appinfo.c:3478:17: warning: comparison of integer expressions of different signedness: 'gint' {aka 'int'} and 'guint' {aka 'unsigned int'}
for (i = 0; i < supported_protocols->len; i++)
^
gio/gwin32appinfo.c:3541:33: warning: comparison of integer expressions of different signedness: 'gint' {aka 'int'} and 'guint' {aka 'unsigned int'}
for (i_hverb = 0; i_hverb < url->verbs->len; i_hverb++)
^
gio/gwin32appinfo.c: In function 'g_win32_app_info_launch_internal':
gio/gwin32appinfo.c:4799:37: warning: comparison of integer expressions of different signedness: 'gint' {aka 'int'} and 'guint' {aka 'unsigned int'}
for (p_index = 0; p_index <= g_strv_length (envp); p_index++)
^~
gio/gwin32packageparser.c: In function 'WIN32_FROM_HRESULT':
gio/gwin32packageparser.c:99:30: warning: comparison of integer expressions of different signedness: 'long unsigned int' and 'long int'
if ((hresult & 0xFFFF0000) == MAKE_HRESULT (SEVERITY_ERROR, FACILITY_WIN32, 0) ||
^~
This was previously done (by commit 63038d1e4c) in one of the cases
where `kill_test_service()` was called — but not the other.
This meant that one instance of `gdbus-testserver` could still be
around when (as it happens, due to the order of the tests) the
`/gdbus/proxy/no-match-rule` test was run. It would start a second
instance of `gdbus-testserver`, which would exit early due to the test
name still being owned on the bus. The first (killed) instance of
`gdbus-testserver` would then exit, leaving no test servers running, and
hence the new test would fail.
This was being seen as frequent CI failures, particularly on FreeBSD
(must have slightly different timing for process signalling and
termination from Linux).
Signed-off-by: Philip Withnall <pwithnall@endlessos.org>
Once upon a time, we tried to return all possible certificate errors,
but it never actually worked reliably and nowadays we have given up.
This needs to be documented because a reasonable developer would not
expect it.
Because mistakes could be security-critical, I decided to copy the same
warning in several different places rather than relying only on
cross-referencese.
These are known leaks, as they were being done in tests which were
checking precondition failures.
However, since we know what happens when the failures occur, we can
still free the input data reliably, so do that.
This improves the valgrind output for `actions` to show zero definite
leaks.
Signed-off-by: Philip Withnall <pwithnall@endlessos.org>
The `actions` test previously waited an arbitrary 100ms for various
D-Bus messages to be sent/received, before checking the results of those
messages.
Normally, this would work, but on heavily loaded CI systems, it would
sometimes fail. For example,
https://gitlab.gnome.org/GNOME/glib/-/jobs/1611701.
Fix that by waiting for the condition being checked to evaluate to true,
rather than waiting an arbitrary period of time. On faster machines,
this will speed the tests up too.
Assume that the global default `GMainContext` is in use, so a
`GMainContext*` pointer doesn’t have to be passed around.
Signed-off-by: Philip Withnall <pwithnall@endlessos.org>
gio/gcontenttype-win32.c: In function 'get_registry_classes_key':
gio/gcontenttype-win32.c:66:78: warning: comparison of integer expressions of different signedness: 'DWORD' {aka 'long unsigned int'} and 'int'
if (ExpandEnvironmentStringsW (wc_temp, wc_temp_expanded, len) == len)
^~
This allows the flag to allow interactive auth to be set. Previously, it
was unconditionally unset.
Signed-off-by: Philip Withnall <pwithnall@endlessos.org>
D-Bus has an upper limit on number of Match rules and it's rather easy to hit
with a big number of proxies with signal subscriptions. This happens with
NetworkManager with hundreds of devices or connection settings. By passing
G_DBUS_SIGNAL_FLAGS_NO_MATCH_RULE to g_dbus_connection_signal_subscribe(), the
user can call AddMatch with a less granular match instead of a match per every
proxy.
Tests subsequently added by Philip Withnall.
Fixes: #1109
- Isolate the first meaningful paragraph, for gi-docgen's summary
- Describe get_object() as a binding API
- Fix reference to get_item() inside get_item_type()
g_check_setuid does more than setuid checks when using AT_SECURE.
Make sure that it is referenced in the error message to help
users debug in case or errors
Closes#2518
Fix another variant of the previous commit, this time specific to the
idle callback of a method call on a subtree object, racing with
unregistration of that subtree.
In this case, the `process_subtree_vtable_message_in_idle_cb()` idle
callback already has a pointer to the right `ExportedSubtree` struct,
but again doesn’t have a strong reference to it.
Signed-off-by: Philip Withnall <pwithnall@endlessos.org>
Helps: #2400
If `g_dbus_connection_unregister_object()` (or `unregister_subtree()`)
was called from one thread, while an idle callback for a method call (or
a property get or set) was being invoked in another, it was possible for
the two to race after the idle callback had checked that the
object/subtree was registered, but before it had finished dereferencing
all the data related to that object/subtree.
Unregistering the object/subtree would immediately free the data,
leading the idle callback to cause a use-after-free error.
Fix that by giving the idle callback a strong reference to the data from
inside the locked section where it checks whether the object/subtree is
still registered.
Signed-off-by: Philip Withnall <pwithnall@endlessos.org>
Fixes: #2400
This is needed for an upcoming change which decouples their lifecycle
from their presence in the `map_id_to_ei` and `map_id_to_es` hash
tables.
Signed-off-by: Philip Withnall <pwithnall@endlessos.org>
Helps: #2400
Move it further up the file, but make no changes to it. This will help
with a subsequent commit.
Signed-off-by: Philip Withnall <pwithnall@endlessos.org>
Helps: #2400
This introduces no functional changes; it only simplifies the code.
Instead of maintaining a separate pointer to the backend iff it’s a
`GDelayedSettingsBackend`, just test the `backend` pointer’s type.
Signed-off-by: Philip Withnall <pwithnall@endlessos.org>
Helps: #2426
Previously, the delay-apply status of the parent `GSettings` object
would be partially inherited: `settings->priv->backend` in the child
`GSettings` object would point to a `GDelayedSettingsBackend`, but
`settings->priv->delayed` would be `NULL`.
The expectation from https://bugzilla.gnome.org/show_bug.cgi?id=720891
was that `get_child()` would fully inherit delay-apply status.
So, ensure that `settings->priv->delayed` is correctly set to point to
the delayed backend when constructing any `GSettings`. Update the tests
to work again (presumably the inverted test was an oversight in the
original changes).
Signed-off-by: Philip Withnall <pwithnall@endlessos.org>
Fixes: #2426
`g_settings_reset()` changes the value of the setting to `NULL`;
`add_to_tree()` was not handling that correctly.
Add a unit test.
Signed-off-by: Philip Withnall <pwithnall@endlessos.org>
Fixes: #2426
Add missing (nullable), and use 2-space indentation to avoid markdown
pre-formatted blocks when unwanted.
Signed-off-by: Marc-André Lureau <marcandre.lureau@redhat.com>
As this would have undesirable consequence.
Quoting Philip Withnall:
https://gitlab.gnome.org/GNOME/glib/-/merge_requests/2305#note_1294729:
The documentation never said anything about accepting absolute paths,
so any code which is relying on that is relying on undocumented
behaviour. We’re allowed to change that.
Signed-off-by: Marc-André Lureau <marcandre.lureau@redhat.com>
`standard::name` must be available for `g_file_enumerator_get_child()`
to work. Emit a critical warning and return if it’s not. This is similar
to the existing behaviour in `g_file_enumerator_iterate()`.
Improve the documentation to mention this.
Signed-off-by: Philip Withnall <pwithnall@endlessos.org>
Fixes: #2507
The code cannot function correctly if the `standard::name` attribute is
not present, so upgrade the existing warning to a critical warning and
return if it fails in `g_file_enumerator_iterate()`.
Signed-off-by: Philip Withnall <pwithnall@endlessos.org>
Helps: #2507
It was Red Hat specific when it was introduced in 2004, was never
supported by mount(8) upstream, and was removed entirely in 2008.
It’s confusing for GLib to keep references to it around.
Thanks to Karel Zak for digging up the history of it:
https://gitlab.gnome.org/GNOME/glib/-/merge_requests/2298#note_1294519
And thanks to Xidorn Quan for looking into it in the first place (see
!2298).
Signed-off-by: Philip Withnall <pwithnall@endlessos.org>
gio/gsocket.c: In function 'g_socket_get_available_bytes':
gio/gsocket.c:3141:17: warning: comparison of integer expressions of different signedness: 'u_long' {aka 'long unsigned int'} and 'int'
if (avail == -1)
^~
gio/gsocket.c: In function 'g_socket_send_messages_with_timeout':
gio/gsocket.c:5283:19: warning: comparison of integer expressions of different signedness: 'gint' {aka 'int'} and 'guint' {aka 'unsigned int'}
for (i = 0; i < num_messages; ++i)
^
gio/gsocket.c:5308:76: warning: operand of ?: changes signedness from 'int' to 'gsize' {aka 'long long unsigned int'} due to unsignedness of other operand
result = pollable_result == G_POLLABLE_RETURN_OK ? bytes_written : -1;
^~
gio/win32/gwinhttpfile.c: In function 'g_winhttp_file_query_info':
gio/win32/gwinhttpfile.c:554:13: warning: comparison of integer expressions of different signedness: 'int' and 'size_t' {aka 'long long unsigned int'}
n == wcslen (content_length))
^~
gio/win32/gwin32fsmonitorutils.c: In function 'g_win32_fs_monitor_handle_event':
gio/win32/gwin32fsmonitorutils.c:107:11: warning: comparison of integer expressions of different signedness: 'GFileMonitorEvent' {aka 'enum <anonymous>'} and 'int'
if (fme != -1)
^~
gio/win32/gwinhttpvfs.c: In function 'g_winhttp_vfs_get_file_for_uri':
gio/win32/gwinhttpvfs.c:172:17: warning: comparison of integer expressions of different signedness: 'int' and 'long long unsigned int'
for (i = 0; i < G_N_ELEMENTS (winhttp_uri_schemes); i++)
^
gio/win32/gwinhttpvfs.c: In function 'g_winhttp_vfs_get_supported_uri_schemes':
gio/win32/gwinhttpvfs.c:210:17: warning: comparison of integer expressions of different signedness: 'int' and 'long long unsigned int'
for (i = 0; i < G_N_ELEMENTS (winhttp_uri_schemes); i++)
^
The "recursive:" kwarg is available in the targeted minimum version of
meson, and is basically required if you want to not emit warnings and
maybe error with --fatal-meson-warnings.
There are two basic solutions to this problem:
- The current default behavior is false, so explicitly opt in to that
value. None of these internal libraries use recursive objects anyway.
- Use link_with to link to the static library directly, rather than the
extracted objects.
Option 2 is what used to be done before commit
62af03bda8, but it only works with meson
>=0.52 and previously had buggy behavior.
Since the minimum version of meson is now 0.52, it is safe to revert
that commit and go back to using link_with, and therefore option 2 is
chosen.
Previously, the code validated that child objects have a path with the
object manager strictly as a prefix. That doesn’t work in the case where
the object manager’s path is `/`. This case is not recommended, but is
supported.
If the object manager’s path is `/`, validate that child objects’ paths
are not equal to it. If they are equal to it, warn the user rather than
emitting a critical warning, since we can’t expect any users who’ve not
been compliant with the spec to instantly rework their D-Bus APIs.
Signed-off-by: Philip Withnall <pwithnall@endlessos.org>
Fixes: #2500
Emit this when we're about to spawn or DBus activate a GAppInfo. This
allows lauchers to keep the appinfo associated with a startup id.
We use a GVariant to allow for future exansion of the supplied data.
When using g_desktop_app_info_launch_uris_as_manager the "launched"
signal allows to map a desktop-startup-id to a GAppInfo. Make this
possible for DBus activation too.
Since we don't have a PID there we pass a 0. Update the signal
description accordingly.
These should be implemented by loadable IO module libraries, but are not
callable in GLib itself.
Signed-off-by: Philip Withnall <pwithnall@endlessos.org>
Fixes: #2498
This is a partial revert of commit
f378352051, as the previous commits have
silenced the AddressSanitizer warnings for `GContentType`.
Signed-off-by: Philip Withnall <pwithnall@endlessos.org>
Fixes: #2310
The function pointer casts silence the compiler and allow the code to
build (and even run in the typical case). However, when building with
control flow integrity checks, the runtime (rightfully) complains about
calling a function via a mismatched function pointer type.
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>
Allocate an empty cache object, check cache objects for being empty
before using them.
Otherwise the code will re-read cache every 5 seconds, as NULL cache
does not trigger the code that stores mtime, which makes the cache
file appear modified/unloaded permanently.
https://bugzilla.gnome.org/show_bug.cgi?id=735696
Since returning exactly one match has special significance, don't
give up matching before we've found at least 2 types. Also, make
sure that we don't return the same mime type more than once.
Bug 541236.
If an `InterfacesRemoved` signal is received for an object which doesn’t
exist in the local map of interfaces, don’t emit a warning.
This seems to happen in the real world (see #2401). Without a trace of
the D-Bus traffic it’s not possible to know exactly what situation is
causing this, but it seems possible that the peer could disappear and
its `notify::name-owner` signal could be processed before its
`InterfacesRemoved` signal, or something similar.
Signed-off-by: Philip Withnall <pwithnall@endlessos.org>
Fixes: #2401
Relax assertion about opened registry key as it may have been removed
in the meantime between enumeration and when opening, or (more likely)
we may not have the required permissions to open the some enumerated
keys (i.e. RegOpenKeyExW fails and returns ERROR_ACCESS_DENIED).
Fixes https://gitlab.com/inkscape/inbox/-/issues/5669
Instead of calling xterm when it clearly does not exist and causes a silent error,
inform the user that the launch failed so they can take the right action.
Also added (transfer full) or (transfer none) annotations while I was at it.
This is the result of checking each `Returns:` line in these files. I’ve
only considered nullability and transferability, and not other (potentially
missing or incorrect) annotations.
Helps: #2227
If the first power-profile installed test fails (for example, because
xdg-desktop-portal isn’t available), correctly tear down the dbusmock
object, or it will cause setUp() to fail when the next test in the suite
is run.
Signed-off-by: Philip Withnall <pwithnall@endlessos.org>
Helps: #2481
When first creating the monitor, correctly set its property value to the
value from the portal, rather than waiting for the portal value to
change to set it.
Signed-off-by: Philip Withnall <pwithnall@endlessos.org>
Fixes: #2481
We were lucky that this worked in some cases (the test is racy), but we
should actually run the condition check each loop, rather than when the
function is called.
Spotted by Martin Pitt:
96a8c02d24 (r54773831)
Let's explain the advantages of relying on GTlsConnection to perform
certificate verification.
Also, document that the issuer property is a little tricky, because the
issuer certificate might not be the certificate that actually gets used
in final certification path building. This is very unexpected to anybody
who is not an expert.
Because TLS certificate verification is extremely complex, the lookup
issuer function may be tempting to misuse even by experienced
developers. There is a notion that the issuer certificate will always be
used in the final certification path, but it's just not always true.
Trying to make security decisions based on the results of this function is
a trap, so let's document that.
It turns out that old versions of glib-networking actually reordered the
certificate chain to match the final verification path. This no longer
happens since a long time ago, because it was a buggy mess. Instead, we
rely on the TLS library to build the final verification path. Their path
building is not very good, but at least it's consistent. The point of
these doc updates is to clarify that only the TLS library can make
security decisions.
Document that HTTP requests may be performed to look up missing
certificates.
Finally, let's document that certificate verification using GTlsDatabase
cannot be as smart as certificate verification performed directly by
GTlsConnection.
g_win32_package_parser_enum_packages() reads beyond the end of a buffer
when doing a memcpy. With app verifier enabled on Windows, it causes
the application to crash on startup.
This change limits the memcpy to the size of the source string.
Fixes: #2454
This reverts commit 7aa0580cc5.
As stated in #2316, that commit was a workaround to allow gnome-keyring
and msmtp to continue to get their session bus address from
`DBUS_SESSION_BUS_ADDRESS`, even though they’re `AT_SECURE`. The timeout
on that workaround has expired so that commit is now being reverted.
Fixes: #2316
You need to separate the first entry in the list from the preceding
paragraph, and you should add a space before the enumerating symbol.
GTK-Doc accepts a very lax Markdown syntax, but any other tool parsing
our documentation will likely fail.
The value should be initialized to NULL before calling
g_win32_registry_key_get_value_w(), to ensure that cleanup
can be done unconditionally afterward.
To ensure that the watch is properly re-set every time, call
watch_keys() from the watch callback. Previously the watch was only
renewed after a data update was done in a worker thread, which made
no sense, since the update function was implemented in such a way
that it can (and should) be re-triggered on each key change, until
the changes stop coming, and that can only happen if we renew
the registry watcher right away.
If a key watch is renewed from the key watch callback, it results
in the callback being NULL, since we clear it after we call it.
Rearrange the function to make sure that the changes done by the
callback function are preserved properly.
This function can, in fact, return STATUS_SUCCESS. We shouldn't
assert that it doesn't.
For now interpret it just like STATUS_PENDING (i.e. APC will be called),
see how it goes (it isn't documented how the function behaves in this
case, we have to play it by ear).
Note that while we *can* use a better-documented RegNotifyChangeKeyValue() here,
it communicates back to us via event objects, which means that the registry
watcher would have to interact with the main loop directly and insert its
events (plural; one event per key) there. That would make the API more complicated.
Whereas the internal NT function communicates by calling an APC - we're good
as long as something somewhere puts the thread in alertable state.
When attempting to test Windows support for building libadwaita, since we are
using multiple GResource files, one would hit linker errors where multiple
definitions of the following symbols have been defined, when
glib-compile-resources was invoked without manual register:
resource_constructor_wrapper
resource_destructor_constructor
_arrayresource_constructor
_arrayresource_destructor
In order to avoid that, just prefix the definitions of resource_constructor
and resource_destructor, like what we do when --manual-register is used, with
what we pass in with --c-name so that we ensure that we do not end up in such
name collisions.
Port all existing calls in GLib to the new API so that they can receive
more detailed error information (although none of them actually make use
of it at the moment).
This also serves to test the new API better through use.
Signed-off-by: Philip Withnall <pwithnall@endlessos.org>
Helps: #203
The `g_file_trash` function fails with the `Unable to find or create trash
directory` error when the global `.Trash` directory exists. This is because
the commit 7f2af262 introduced the `gboolean success` variable to signalize
the detection of the trash folder, but didn't set it in all code branches.
Since for a time this variable was not initialized the bug wasn't visible
when the trash folder existed. The bug became effective after the `success`
variable was initialized with `FALSE` by the commit c983ded0. Let's explicitly
set the `success` variable in all branches to fix the global trash dir
detection.
Fixes: https://gitlab.gnome.org/GNOME/glib/-/issues/2439
The function which calls `SetFileTime()` works with seconds and
nanosecond, but the functions which call it are doing so with seconds
and microseconds.
Fix them so they convert to nanoseconds first.
Signed-off-by: Philip Withnall <pwithnall@endlessos.org>
The code appears to be dealing with time in units of 100ns, not 100µs,
so name the variable accordingly.
The rest of the arithmetic in that function appears consistent and
correct.
Signed-off-by: Philip Withnall <pwithnall@endlessos.org>
The modification time test creates a file, gets the modification time in
seconds, then gets the modification time in microseconds and assumes
that the difference between the two has to be above 0.
As rare as this may be, it can happen:
$ stat g-file-info-test-50A450 -c %y
2021-07-06 18:24:56.000000767 +0100
Change the test to simply assert that the difference not negative to
handle this case.
This is necessary when building glib with icecc. Icecc splits the build
process into two parts. The file is locally preprocessed with
-fdirectives-only to resolve any includes. This adds linemarkers to the
intermediate file. Without the new-line at the end of the file this:
#include "gconstructor_as_data.h"
#include "glib/glib-private.h"
Is turned into this:
const char gconstructor_code[] = "...";# 1 "glib/glib-private.h"
...
The result is a compile error:
In file included from ../glib/gio/glib-compile-resources.c:45:
gio/gconstructor_as_data.h:1: error: stray '#' in program
gio/gconstructor_as_data.h:1: error: expected identifier or '(' before numeric constant
In file included from ../glib/glib/glib-private.h:22,
from gio/gconstructor_as_data.h:2,
from ../glib/gio/glib-compile-resources.c:45:
../glib/glib/gwakeup.h:27:1: error: unknown type name 'GWakeup'
../glib/glib/gwakeup.h:28:42: error: unknown type name 'GWakeup'
../glib/glib/gwakeup.h:30:42: error: unknown type name 'GWakeup'
../glib/glib/gwakeup.h:32:42: error: unknown type name 'GWakeup'
../glib/glib/gwakeup.h:33:42: error: unknown type name 'GWakeup'
In file included from gio/gconstructor_as_data.h:2,
from ../glib/gio/glib-compile-resources.c:45:
../glib/glib/glib-private.h:98:3: error: unknown type name 'GWakeup'
../glib/glib/glib-private.h:99:58: error: unknown type name 'GWakeup'
../glib/glib/glib-private.h💯58: error: unknown type name 'GWakeup'
../glib/glib/glib-private.h:102:58: error: unknown type name 'GWakeup'
../glib/glib/glib-private.h:103:58: error: unknown type name 'GWakeup'
In file included from gio/gconstructor_as_data.h:2,
from ../glib/gio/glib-compile-resources.c:45:
../glib/glib/glib-private.h:164:53: warning: file "../glib/gio/glib-compile-resources.c" linemarker ignored due to incorrect nesting
To avoid this, generate gconstructor_as_data.h with a new-line at the end
of the file.
Signed-off-by: Michael Olbrich <m.olbrich@pengutronix.de>
This helps to void deadlocks when two processes call interfaces on each
other one of them being org.freedesktop.DBus.ObjectManager.
Signed-off-by: Guido Günther <agx@sigxcpu.org>
The current code is unsafe to use from multiple threads at once.
GIOStream functions like this are supposed to be semi-threadsafe. It's
allowed for them to be called on both a reader thread and a writer
thread at the same time. Of course, it's still tricky and dangerous,
because it's only *really* threadsafe if the handshake has finished,
and API users have no plausible way to know that because the API
does not require performing an explicit handshake operation. But that's
a glib-networking problem. We can at least avoid the most obvious
threadsafety issue here in the API layer.
Note that we'll need to implement the new vfunc in glib-networking for
this to actually work.
Fixes#2393
The documentation for `g_bus_watch_name()` implies that the
`GDestroyNotify` for the user data will be called in the current thread
default `GMainContext`. Currently, it could be called in any thread, as
`client_unref()` can be called in any thread.
Fix that by deferring it to an idle source if `client_unref()` finalises
the `Client` object in a different thread.
Signed-off-by: Philip Withnall <pwithnall@endlessos.org>
These were missing from the test before the previous commit ported from
`GMainLoop` to `GMainContext`.
Signed-off-by: Philip Withnall <pwithnall@endlessos.org>
It makes combination exit conditions a lot easier than when using
`g_main_loop_quit()` from different callbacks.
Signed-off-by: Philip Withnall <pwithnall@endlessos.org>
The first sentence incorrectly said that it checked the type of the
value, and then the second sentence explicitly said it was a programmer
error to give a value of the wrong type.
According to the code, the second sentence is correct.
Signed-off-by: Philip Withnall <pwithnall@endlessos.org>
Fixes: #2425
WebKit wants these private key properties to be readable in order to
implement a deserialization function. Currently they are read-only
because at the time GTlsCertificate was originally designed, the plan
was to support PKCS#11-backed private keys: private keys that are stored
on a smartcard, where the private key is completely unreadable. The
design goal was to support both memory-backed and smartcard-backed
private keys with the same GTlsCertificate API, abstracting away the
implementation differences such that code using GTlsCertificate doesn't
need to know the difference.
The original PKCS#11 implementation was never fully baked and at some
point in the past I deleted it all. It has since been replaced with a
new implementation, including a GTlsCertificate:private-key-pkcs11-uri
property, which is readable. So our current API already exposes the
differences between normal private keys and PKCS#11-backed private keys.
The point of making the private-key and private-key-pem properties
write-only was to avoid exposing this difference.
Do we have to make this API function readable? No, because WebKit could
be just as well served if we were to expose serialize and deserialize
functions instead. But WebKit needs to support serializing and
deserializing the non-private portion of GTlsCertificate with older
versions of GLib anyway, so we can do whatever is nicest for GLib. And I
think making this property readable is nicest, since the original design
reason for it to not be readable is now obsolete. The disadvantage to
this approach is that it's now possible for an application to read the
private-key or private-key-pem property, receive NULL, and think "this
certificate must not have a private key," which would be incorrect if
the private-key-pkcs11-uri property is set. That seems like a minor
risk, but it should be documented.
On Unix platforms, wait() and friends yield an integer that encodes
how the process exited. Confusingly, this is usually not the same as
the integer passed to exit() or returned from main(): conceptually it's
an integer encoding of this tagged union:
enum { EXITED, SIGNALLED, ... } tag;
union {
int exit_status; /* if EXITED */
struct {
int terminating_signal;
bool core_dumped;
} terminating_signal; /* if SIGNALLED */
...
} detail;
Meanwhile, on Windows, wait statuses and exit statuses are
interchangeable.
I find that it's clearer what is going on if we are consistent about
referring to the result of wait() as a "wait status", and the value
passed to exit() as an "exit status".
GSubprocess already gets this right: g_subprocess_get_status() returns
the wait status, while g_subprocess_get_exit_status() genuinely returns
the exit status. However, the GSpawn family of APIs has tended to
conflate the two.
Confusingly, g_spawn_check_exit_status() has always checked a wait
status, and it would not be correct to pass an exit status to it; so
let's deprecate it in favour of g_spawn_check_wait_status(), which
does the same thing that g_spawn_check_exit_status() always did.
Code that needs backwards-compatibility with older GLib can use:
#if !GLIB_CHECK_VERSION(2, 69, 0)
#define g_spawn_check_wait_status(x) (g_spawn_check_exit_status (x))
#endif
Signed-off-by: Simon McVittie <smcv@collabora.com>
Confusingly, g_spawn_check_exit_status() takes a wait status, not an
exit status, so passing g_subprocess_get_exit_status() to it is
incorrect (although both encodings happen to use 0 to encode success
and a nonzero value to encode failure, so in practice this probably
had the desired effect).
Signed-off-by: Simon McVittie <smcv@collabora.com>
Following on from the previous commit, some explicit
`g_main_context_wakeup()` calls were missing from the test code which
only uses `GMainContext`.
Add them, and also add some assertions to check that these functions are
being called in the expected thread (as the code comments say).
Signed-off-by: Philip Withnall <pwithnall@endlessos.org>
This is a bit of a compromise. Since the option parsing in
`GApplication` is built on `GOptionContext`, there’s no way to
reliably indicate that a given option was passed by the user, other than
by its value changing. If the default value is zero, but the user
explicitly passed zero, nothing changes, so it’s not obvious that the
option was explicitly provided.
When just `GOptionContext` is being used, this is fine, as that’s
obvious what will happen from the way the API is built. With
`GApplication::handle-local-options`, though, the `GVariantDict`
provided by GLib to the callback claims to only contain the values of
the options provided by the user, and no defaults.
It’s not actually possible for GLib to do that reliably.
Previously, GLib was dropping all numeric values which were zero valued
(i.e. the defaults), as they *could* have been the defaults. It seems
like a slightly better behaviour to instead *not* drop those numeric
values, and err on the side of reporting some defaults as user-provided
(even if they weren’t) rather than dropping some user-provided values
which happen to be the defaults.
This adds a test for the case of parsing a double; the cases for
integers are analogous.
Signed-off-by: Philip Withnall <pwithnall@endlessos.org>
Fixes: #2329
The tests in `gdbus-names.c` use a mixture of `GMainLoop` and iterating
a `GMainContext` directly. Some of the helper functions based around the
`OwnNameData` struct use the `loop` `GMainLoop` even when called from
tests like `watch_with_different_context()` which themselves use
`GMainContext` directly.
Thus, it’s possible for the `GMainLoop` to not be running, while the
test is iterating on `g_main_context_iteration()`. In this case,
`g_main_loop_quit()` is a no-op and will not wake up the `GMainContext`.
This causes the test to livelock in around 1 in 1200 test runs.
Fix this by adding an explicit `g_main_context_wakeup()` call after each
`g_main_loop_quit()` call. A more comprehensive fix would be to port all
the tests in this file to iterating `GMainContext` directly, and drop
all the `GMainLoop` usage, but I don’t have time for that right now.
Signed-off-by: Philip Withnall <pwithnall@endlessos.org>
If `g_file_monitor_source_dispatch()` drops the last reference to its
`GLocalFileMonitor`, a deadlock will occur, because disposing the
`GLocalFileMonitor` causes synchronous disposal of the
`GFileMonitorSource`, and hence an attempt to re-lock the already-locked
mutex in the `GFileMonitorSource`.
Fix that by dropping the reference to the `GLocalFileMonitor` after
unlocking.
Diagnosed by Ting-Wei Lan. The bug was originally introduced by me in
commit 592a13b483.
Signed-off-by: Philip Withnall <pwithnall@endlessos.org>
Relax the requirement for the test to only be compiled/run under gcc,
since a version of LLVM was released which supports `--add-symbol`.
`objcopy` should be overrideable to be `llvm-objcopy` by using a machine
file as per https://mesonbuild.com/Machine-files.html#binaries.
Suggested and tested by Grigory Vasilyev.
Signed-off-by: Philip Withnall <pwithnall@endlessos.org>
Fixes: #2423
Clarify that the terms ‘GUID’ and ‘UUID’ are used interchangeably in the
context of D-Bus, and that neither of them are an RFC 4122 UUID.
Signed-off-by: Philip Withnall <pwithnall@endlessos.org>
