This will probably make no functional difference, but will squash two
warnings from scan-build:
```
../../../../source/glib/gio/gsocket.c:503:14: warning: Assigned value is garbage or undefined [core.uninitialized.Assign]
family = address.storage.ss_family;
^ ~~~~~~~~~~~~~~~~~~~~~~~~~
../../../../source/glib/gio/gsocket.c:527:29: warning: Assigned value is garbage or undefined [core.uninitialized.Assign]
socket->priv->family = address.storage.ss_family;
^ ~~~~~~~~~~~~~~~~~~~~~~~~~
```
It seems like a reasonable thing to warn about. Initialising the full
union to zero should avoid any possibility of undefined behaviour like
that.
Signed-off-by: Philip Withnall <pwithnall@endlessos.org>
Helps: #1767
This fixes a scan-build warning:
```
../../../../source/glib/gio/tests/gdbus-tests.c:146:3: warning: Value stored to 'watch_id' is never read [deadcode.DeadStores]
watch_id = 0;
^
```
Signed-off-by: Philip Withnall <pwithnall@endlessos.org>
Helps: #1767
Tested using:
```sh
touch ~/foo
gio set ~/foo -t bytestring user::test "\x00\x00"
```
(it doesn’t matter that this fails; the bytestring is still decoded)
Signed-off-by: Philip Withnall <pwithnall@endlessos.org>
Coverity CID: #1474407
These `memcpy()` calls only happen if `g_inet_address_get_family(group)
== G_SOCKET_FAMILY_IPV4`, so the assertions should never fail.
It’s helpful for understanding the code, and for static analysis, to add
the assertions though.
Signed-off-by: Philip Withnall <pwithnall@endlessos.org>
Coverity CID: #1486858
When I enabled unix socketpair test on win32, I left the existing
g_close(fds[1]), but _g_win32_socketpair() returns native sockets
descriptors that must be closed with closesocket() on win32.
Let GSocket handle the socket pair cleanup.
Signed-off-by: Marc-André Lureau <marcandre.lureau@redhat.com>
When checking that the connection has the expected number of refs, the
test would block on a `GMainContext` iteration for up to 3s before
waking up and failing (if the refcount was still not as expected).
This check was written in the expectation that changing the refcount of
the connection would only happen due to dispatching a source on
`GMainContext` — hence the `GMainContext` would wake up as the refcount
changed.
That’s probably not actually true though. It might be the case that the
connection’s refcount is changed on from the GDBus worker thread, which
would not cause any wakeups on the main thread’s `GMainContext`.
In this case, the `GMainContext` iteration in
`assert_connection_has_one_ref()` would block for the full 3s, and then
wake up and notice the refcount is correct (then the test would
proceed).
That’s fine, apart from the fact that `test_threaded_singleton()` does
this 1000 times. If the slow case is hit on a significant number of
those test runs, the test will take around 3000s to complete, which is
significantly more than meson’s test timeout of 360s. So the test fails
with something like:
```
220/266 glib:gio+slow / gdbus-threading TIMEOUT 360.07 s
--- command ---
G_TEST_SRCDIR='/builds/GNOME/glib/gio/tests' GIO_MODULE_DIR='' G_TEST_BUILDDIR='/builds/GNOME/glib/_build/gio/tests' /builds/GNOME/glib/_build/gio/tests/gdbus-threading
--- stdout ---
\# random seed: R02S83fe8de22db4d4f376e6d179e2bdd601
1..3
\# Start of gdbus tests
ok 1 /gdbus/delivery-in-thread
ok 2 /gdbus/method-calls-in-thread
\# GLib-GIO-DEBUG: refcount of 0x5602de913660 is not right (3 rather than 1) in test_threaded_singleton(), sleeping
\# GLib-GIO-DEBUG: refcount of 0x5602de913660 is not right (3 rather than 1) in test_threaded_singleton(), sleeping
\# GLib-GIO-DEBUG: refcount of 0x5602de913c60 is not right (3 rather than 1) in test_threaded_singleton(), sleeping
\# GLib-GIO-DEBUG: refcount of 0x5602de913c60 is not right (3 rather than 1) in test_threaded_singleton(), sleeping
\# GLib-GIO-DEBUG: refcount of 0x5602de913260 is not right (3 rather than 1) in test_threaded_singleton(), sleeping
\# GLib-GIO-DEBUG: refcount of 0x5602de913260 is not right (3 rather than 1) in test_threaded_singleton(), sleeping
```
From this log, it can be seen that the sleep is happening on a different
`GMainContext` every other time, so the test *is* making progress.
Assuming this is a correct diagnosis (it’s a lot of guessing), this
commit tries to fix the test by adding a wakeup timeout to the
`GMainContext` in `assert_connection_has_one_ref()`, which will wake it
up every 50ms to re-check the exit condition.
This polling approach has been taken because it doesn’t seem feasible to
make sure that every `g_object_ref()`/`g_object_unref()` call on a
`GDBusConnection` causes the main context to wake up.
Signed-off-by: Philip Withnall <pwithnall@endlessos.org>
This might fix a recent test failure:
https://gitlab.gnome.org/GNOME/glib/-/jobs/1929015. Unfortunately
there’s not much debug information in the logs to go on, and I can’t
reproduce it locally. All I have is:
```
192/272 glib:gio / gdbus-peer-object-manager FAIL 0.43 s (killed by signal 11 SIGSEGV)
--- command ---
GIO_MODULE_DIR='' G_TEST_BUILDDIR='/builds/GNOME/glib/_build/gio/tests' G_TEST_SRCDIR='/builds/GNOME/glib/gio/tests' /builds/GNOME/glib/_build/gio/tests/gdbus-peer-object-manager
--- stdout ---
\# random seed: R02Seee9b7325ecd7c19249a3412397aed9b
1..2
\# Start of gdbus tests
\# Start of peer-object-manager tests
```
Signed-off-by: Philip Withnall <pwithnall@endlessos.org>
While the assertion always turned out to be true on Linux, it frequently
caused spurious test failures on FreeBSD.
After some remote debugging, I *think* the cause is as written up in the
comment in the code in this commit. However, I cannot be certain, as the
more debugging messages I added, the harder the failure was to
reproduce; and I don’t have access to a FreeBSD machine.
This fixes failures like:
```
Bail out! GLib-GIO:ERROR:../gio/tests/converter-stream.c:1043:test_converter_pollable: assertion failed (error == NULL): Resource temporarily unavailable (g-io-error-quark, 27)
```
It’s succeeded 1000 times in a row on the FreeBSD CI now; previously
it was failing one time in three:
https://gitlab.gnome.org/GNOME/glib/-/jobs/1936395.
Signed-off-by: Philip Withnall <pwithnall@endlessos.org>
There’s (deliberately) a bit of race in implementing/handling
`CloseBeforeReturning()` in `gdbus-method-invocation.c`. If the server
closes the D-Bus connection early, the client may exit with `SIGTERM` if
`GDBusConnection:exit-on-close` is set. We don’t want that, as the test
is trying to check that the default handling of a D-Bus method return
after a connection has closed works.
See https://gnome.pages.gitlab.gnome.org/-/glib/-/jobs/1935191/artifacts/_build/meson-logs/testlog.txt
Signed-off-by: Philip Withnall <pwithnall@endlessos.org>
G_GNUC_UNUSED does perfectly its job with gcc compiler but the warning
still remains with msvc compiler.
Once the unused variable removed, the finalize vfunc can be removed as
it's doing the same job as the parent function.
We must not open the fd with O_PATH|O_NOFOLLOW,
since the portal rejects that combination. Leaving
out O_NOFOLLOW is fine in this case - we know it
is a directory, we just received EISDIR.
Fixes: #2629
libgamin was last released in 2007 and is dead
[upstream](https://gitlab.gnome.org/Archive/gamin). Distributions may
still ship it (although Fedora no longer does), but we want people to
use inotify on Linux since it’s actively supported.
BSDs use kqueue. Windows uses win32filemonitor.
FAM might still be used on some commercial Unix distributions, but there
are no contributors from those distributions, and certainly no CI for
them to prevent regressions.
Signed-off-by: Philip Withnall <pwithnall@endlessos.org>
Fixes: #2614
It used to exist on Solaris, but GLib’s support for it was mostly
removed in 2015 in commit 21ab660cf8.
Remove the final few references.
Signed-off-by: Philip Withnall <pwithnall@endlessos.org>
They’re only defined on Unix anyway. `GThreadedResolver` has an entirely
different code path for handling DNS replies on Windows.
Signed-off-by: Philip Withnall <pwithnall@endlessos.org>
Success and failure tests. This massively increases test coverage for
parsing DNS records, although it doesn’t get it to 100%.
It should now be useful enough to do more fuzzing on, without
immediately getting trivial failures from the fuzzer.
Signed-off-by: Philip Withnall <pwithnall@endlessos.org>
Rather than limiting them to the full length of the answer, which may
include subsequent records.
Signed-off-by: Philip Withnall <pwithnall@endlessos.org>
This should catch all kinds of invalid records, and correctly report
them as errors.
Heavily based on work by Patrick Griffis in !2134.
Signed-off-by: Philip Withnall <pwithnall@endlessos.org>
Otherwise the code isn’t forwards-compatible, and may be DOSed by
servers returning unknown records, if `G_DEBUG=fatal-warnings` is
enabled for some reason.
Signed-off-by: Philip Withnall <pwithnall@endlessos.org>
It is possible for `dn_expand()` to fail; if so, it’ll return `-1`,
which will mess up subsequent parsing.
Signed-off-by: Philip Withnall <pwithnall@endlessos.org>
Split out from https://gitlab.gnome.org/GNOME/glib/-/merge_requests/2134
by Philip Withnall so it can be used in advance of HTTPS DNS record
support landing.
Reworked to no longer use test fixtures, as it’s simple enough to build
the response header in each test.
The tests are built on Unix only, as they test the parsing code in
`g_resolver_records_from_res_query()`, which is Unix-specific. The
Windows DNS APIs provide much more structured results which don’t need
parsing.
The SONAME of libutil varies between architectures, so the logic to find
the SONAME of libutil was only correct for native builds (Linux on
Linux), not for cross-builds. The regular expression was also not
sufficiently broad to match the SONAME used on the alpha architecture,
which is apparently libutil.so.1.1.
Instead of screen-scraping the output of ldconfig and using that to
dlopen the library that contains openpty, it seems more reliable to
emit a link-time reference to openpty and let the linker do its job.
It's also less code.
Bug-Debian: https://bugs.debian.org/1007946
Signed-off-by: Simon McVittie <smcv@collabora.com>
These should cover everything to do with returning a value or error from
a `GDBusMethodInvocation` object.
Signed-off-by: Philip Withnall <pwithnall@endlessos.org>
`property_info` is only ever set for `Get` and `Set` calls, not for
`GetAll`, as it only represents a single property. So this code was
never reachable.
Move it out so that it is reachable.
Signed-off-by: Philip Withnall <pwithnall@endlessos.org>
When doing an early return from `g_dbus_method_invocation_return_*()`
due to passing in the wrong type (or no return value when one was
expected), the parameters were not correctly sunk and were leaked.
Fix that. A unit test will be added in a following commit.
Signed-off-by: Philip Withnall <pwithnall@endlessos.org>
Coverity CID: #1474536
The public `g_strv_contains()` API didn’t exist at the time this code
was originally written. Now, happily, it does.
Signed-off-by: Philip Withnall <pwithnall@endlessos.org>
The public `g_strv_contains()` API didn’t exist at the time this code
was originally written. Now, happily, it does.
Signed-off-by: Philip Withnall <pwithnall@endlessos.org>
When the test has finished writing all the expanded content into the
socket, explicitly close the output stream, which should make the input
stream readable and non-blocking.
The code intended to do this before, but only as a side-effect of
dropping its last reference to `right`. If another reference was being
held to `right` somewhere else, it wouldn’t end up being closed, which
would lead to failures like
https://gitlab.gnome.org/GNOME/glib/-/jobs/1890000:
```
(/var/tmp/gitlab_runner/builds/Ff4WDDRj/0/GNOME/glib/_build/gio/tests/converter-stream:56570): GLib-GIO-DEBUG: 12:56:23.280: GSocketClient: Connection successful!
Bail out! GLib-GIO:ERROR:../gio/tests/converter-stream.c:1042:test_converter_pollable: assertion failed (error == NULL): Resource temporarily unavailable (g-io-error-quark, 27)
stderr:
```
This is a bit of a guess (I’m not sure it’ll fix the intermittent test
error, as I haven’t been able to reproduce that locally), but it’s worth
a try.
Signed-off-by: Philip Withnall <pwithnall@endlessos.org>
When multiple tests were run in parallel, this would race on its access
to `~/.dbus-keyrings` to authenticate with the D-Bus server, since the
keyring directory was not appropriately sandboxed to the unit test.
Use `G_TEST_OPTION_ISOLATE_DIRS` to automatically isolate each unit
test’s directory usage.
This should hopefully fix the failure seen in
https://gitlab.gnome.org/GNOME/glib/-/jobs/1849524, where the following
was in the log for a test executed in parallel:
```
GDBus-DBUS_COOKIE_SHA1: Deleted stale lock file '/home/user/.dbus-keyrings/org_gtk_gdbus_general.lock'
```
Signed-off-by: Philip Withnall <pwithnall@endlessos.org>
When multiple tests were run in parallel, this would race on its access
to `~/.dbus-keyrings` to authenticate with the D-Bus server, since the
keyring directory was not appropriately sandboxed to the unit test.
Use `G_TEST_OPTION_ISOLATE_DIRS` to automatically isolate each unit
test’s directory usage.
This should hopefully fix the failure seen in
https://gitlab.gnome.org/pwithnall/glib/-/jobs/1879558.
```
228/266 glib:gio / gdbus-non-socket FAIL 8.64 s (killed by signal 6 SIGABRT)
…
--- stderr ---
GDBus-DBUS_COOKIE_SHA1: Deleted stale lock file '/home/user/.dbus-keyrings/org_gtk_gdbus_general.lock'
**
GLib-GIO:ERROR:../gio/tests/gdbus-non-socket.c:253:test_non_socket: assertion failed (error == NULL): Exhausted all available authentication mechanisms (tried: EXTERNAL, DBUS_COOKIE_SHA1) (available: EXTERNAL, DBUS_COOKIE_SHA1) (g-io-error-quark, 0)
```
Signed-off-by: Philip Withnall <pwithnall@endlessos.org>
If the whole set of tests takes more than 5 seconds, the failure timeout
from the first test could still trigger, causing an incorrect failure.
Ensure the timeout is removed at the end of each test.i
This will hopefully fix the CI failure seen here:
https://gitlab.gnome.org/pwithnall/glib/-/jobs/1879558.
```
204/266 glib:gio / gdbus-auth FAIL 9.21 s (killed by signal 5 SIGTRAP)
…
ok 1 /gdbus/auth/client/EXTERNAL
Bail out! GLib-GIO-FATAL-ERROR: Timeout waiting for client
```
Signed-off-by: Philip Withnall <pwithnall@endlessos.org>
Now that the leaks are fixed, this test can be run under the sanitizer
again.
This is a partial revert of commit
f378352051.
Signed-off-by: Philip Withnall <pwithnall@endlessos.org>
Helps: #2312
When destroying `GDBusProxy`s in a custom `GMainContext`, the context
must be iterated enough after finalisation of the proxies that any
pending D-Bus traffic, and the signal subscription data, can be freed.
See the documentation for `g_dbus_connection_signal_unsubscribe()`.
Signed-off-by: Philip Withnall <pwithnall@endlessos.org>
Fixes: #2312
This is quite gross, but it looks like the whole content-type code on
Windows is similar. Pass test_subtype.
Signed-off-by: Marc-André Lureau <marcandre.lureau@redhat.com>
The `ay` property has type `string` (see the generated code) since it’s
not been annotated to force accepting a `GVariant`.
This means the GObject property machinery expects a string, and calls
`g_strdup()` on the passed-in pointer, rather than sinking the
`GVariant`.
Signed-off-by: Philip Withnall <pwithnall@endlessos.org>
Helps: #2312
It periodically hangs due to the `GDBusConnection` having more than 1
ref (and never losing them), so there’s potentially a leaking ref
somewhere:
```
(/builds/alexander.klauer/glib/_build/gio/tests/gdbus-threading:17767): GLib-GIO-DEBUG: 13:18:12.268: refcount of 0x55fe85b1a260 is not right, sleeping
\# GLib-GIO-DEBUG: refcount of 0x55fe85b1a260 is not right, sleeping
```
Add some more debug output to try and track the problem down.
See: https://gitlab.gnome.org/alexander.klauer/glib/-/jobs/1865968
Signed-off-by: Philip Withnall <pwithnall@endlessos.org>
It’s periodically failing on FreeBSD and I can’t reproduce the failure
locally nor work out what it is from the logs:
```
Bail out! GLib-GIO:ERROR:../gio/tests/converter-stream.c:1041:test_converter_pollable: assertion failed (res != -1): (-1 != -1)
stderr:
**
GLib-GIO:ERROR:../gio/tests/converter-stream.c:1041:test_converter_pollable: assertion failed (res != -1): (-1 != -1)
```
Add some more debug output to get the value of `error`, in the hope that
will provide some insight.
See: https://gitlab.gnome.org/GNOME/glib/-/jobs/1866486
Signed-off-by: Philip Withnall <pwithnall@endlessos.org>
Commit 13c4b9579b seems to have fixed
`network-address` so that it’s reliable everywhere, including on macOS.
Signed-off-by: Philip Withnall <pwithnall@endlessos.org>
Helps: #1392
This reverts commit 1ed67a9c44.
It turns out that including options, with their default values, in the
`handle-local-options` signal, which weren’t set on the command line,
breaks some applications.
In particular, it breaks Inkscape, which is the application this commit
was originally meant to fix (a different problem).
Signed-off-by: Philip Withnall <pwithnall@endlessos.org>
Fixes: #2611
Breaks: #2329
See: !1953
This allows applications to get their value regardless whether glib is a
subproject or pkgconfig:
gio_dep = dependency('gio-2.0')
giomoduledir = gio_dep.get_variable('giomoduledir')
schemasdir = gio_dep.get_variable('schemasdir')
This reverts commit 5aa03882ca.
It fails to compile on newer Meson versions with
`--fatal-meson-warnings` due to:
```
WARNING: Project targeting '>= 0.52.0' but tried to use feature introduced in '0.54.0': variables arg in declare_dependency.
gio/meson.build:833:0: ERROR: Fatal warnings enabled, aborting
```
That happens regardless of the fact that we’ve correctly limited the use
of the `variables` argument to only when building with Meson ≥ 0.56.
Unfortunately Meson can’t statically detect that the argument is
conditional.
Bumping GLib’s Meson dependency is too much work right now, so this MR
unfortunately has to be reverted.
This allows applications to get their value regardless whether glib is a
subproject or pkgconfig:
gio_dep = dependency('gio-2.0')
giomoduledir = gio_dep.get_variable('giomoduledir')
schemasdir = gio_dep.get_variable('schemasdir')
`mock-resolver.c` is a mock implementation of `GResolver` used in the
`network-address` tests. It returns resolver results, and implements
timeouts, as directed by the test calling it.
In particular, it allows the IPv4 and IPv6 resolver results to be
returned using independent delays. This allows code paths which deal
with IPv4 and IPv6 results being returned at different times to be
tested, as the ‘Happy Eyeballs’ spec mandates various hard-coded
timeouts for returning the best results it can in a reasonable
timeframe.
Previously, `mock-resolver.c` implemented the timeouts by handling
`lookup_by_name()` in a `GTask` worker thread, and calling `g_usleep()`
for the timeout. This seemed to cause occasional CI failures, such as
https://gitlab.gnome.org/GNOME/glib/-/jobs/1843454, where a resolver
error would be returned rather than the expected results:
```
ok 52 /network-address/happy-eyeballs/ipv4-error-ipv6-first
\# GLib-GIO-DEBUG: IPv4 DNS error: IPv4 Broken
(/var/tmp/gitlab_runner/builds/Ff4WDDRj/0/GNOME/glib/_build/gio/tests/network-address:18428): GLib-GIO-DEBUG: 09:03:08.587: IPv4 DNS error: IPv4 Broken
Bail out! GLib-GIO:ERROR:../gio/tests/network-address.c:586:got_addr: assertion failed (error == NULL): IPv4 Broken (g-io-error-quark, 24)
stderr:
**
GLib-GIO:ERROR:../gio/tests/network-address.c:586:got_addr: assertion failed (error == NULL): IPv4 Broken (g-io-error-quark, 24)
```
While I’ve been unable to reproduce these failures locally, I suspect
they might be down to thread spawning occasionally taking long enough on
a CI runner to change the ordering of the timeouts, such that the ‘Happy
Eyeballs’ algorithm returns a different set of results from what the
test expects.
So, this commit rewrites part of `mock-resolver.c` to implement timeouts
in the main thread, rather than in a worker thread. That should
eliminate the delays in spawning threads, and should mean that the
timeout sources in `mock-resolver.c` are attached to the same
`GMainContext` as those from the ‘Happy Eyeballs’ algorithm which are
monitoring them, so a total order over the timeouts can be guaranteed.
Of course, I might be completely wrong since this is just a guess and I
can’t properly test it since I can’t reproduce the failure. Worth a try.
Signed-off-by: Philip Withnall <pwithnall@endlessos.org>
The test results weren’t being freed.
This makes the `network-address` test clean under memcheck for me.
Signed-off-by: Philip Withnall <pwithnall@endlessos.org>
If these struct members aren't available, we can be more like an
abstraction layer by falling back to yielding 0.
Signed-off-by: Simon McVittie <smcv@collabora.com>
Test failures were previously ignored on macOS because there are 12
tests which consistently fail (and have not yet been fixed, because
there are no regularly active macOS maintainers for GLib; you could help
here!).
However, this means that new test failures can’t be spotted.
So, explicitly mark those 12 tests as `should_fail` on macOS, and then
make other test failures cause failure of the CI run.
We can track the process of fixing those 12 tests on #1392 and #1251.
Signed-off-by: Philip Withnall <pwithnall@endlessos.org>
Helps: #1392
As they use `g_test_dbus_*()`, they depend on dbus-daemon, so move them
to the part of the Meson file which lists those tests.
This disables them running on platforms which don’t have `dbus-daemon`
available. Arguably, this should be done by returning an error from
`g_test_dbus_up()` and then calling `g_test_skip()`, so the test is
correctly recorded as having been skipped. But that’s a fix for another
time.
Signed-off-by: Philip Withnall <pwithnall@endlessos.org>
Having compared the debug output, it doesn’t show anything unusual
happening that can’t already be seen from other output, for this test.
This is a partial revert of 8fd71dccc5. The debugging output it added to
other tests may still be useful.
Signed-off-by: Philip Withnall <pwithnall@endlessos.org>
Helps: #1929
The retry loop for acquiring the lock for the authentication cookie file
currently tries to acquire the lock for 0.5s, then gives up, assumes the
lock file is stale, and deletes it.
That’s great if the lock file *is* stale because it’s been left there by
a crashed process.
It’s not so great if the lock file just happens to have been there every
time this process checked, because the cookie file is highly contested
while (for example) running lots of parallel unit tests.
Check for that situation by comparing the mtime of the lock file and
continuing to retry if it’s changed.
Signed-off-by: Philip Withnall <pwithnall@endlessos.org>
Fixes: #1929
Rather than tracking them with a counter. This should close the race in
tracking the finalisation of the tasks by the task worker thread.
There’s no way to synchronise with that thread as it’s internal to
`g_task_run_in_thread()`.
This should hopefully stop the `debugcontroller` test being flaky.
See https://gitlab.gnome.org/GNOME/glib/-/merge_requests/2486#note_1384102
Signed-off-by: Philip Withnall <pwithnall@endlessos.org>
We are matching `<parameter>` as well as `<para>`, and we
end up with broken XML in case the (expanded) description
starts with `<parameter>`.
Fixes: #2601
This allows the controller to explicitly be removed from the bus, in a
way that allows the caller to synchronise with it and know that all
other references to the controller should have been dropped (i.e. after
this method returns, there should be no in-flight D-Bus calls still
holding a reference to the object).
This is needed to be able to guarantee finalisation of the controller in
unit tests (and comparable real-world situations).
Signed-off-by: Philip Withnall <pwithnall@endlessos.org>
Helps: #1190
The resources data is generated for both GCC and MSVC toolchains, even
though we know beforehand which toolchain we're going to compile it for.
By dropping the data duplication we make the generated resources file
faster to compile, especially when dealing with large embedded data,
instead of relying on the C pre-processor to walk the whole file and
discard the branch we're not using.
There shouldn’t be any issues here with empty argv arrays since an empty
`Exec=` line is already checked for. Encode that explicitly with an
assertion.
Signed-off-by: Philip Withnall <pwithnall@endlessos.org>
This won’t really affect anything, but we might as well fix them to not
crash if called with an empty `argv` by someone (ab)using `execve()`.
Signed-off-by: Philip Withnall <pwithnall@endlessos.org>
While it’s not usual, it is possible for applications to be called with
an empty `argv` by a process (ab)using `execve()`. Modify the
`GApplication` code example to handle that possibility, so that anyone
copying the example isn’t introducing a bug into their program
immediately.
Signed-off-by: Philip Withnall <pwithnall@endlessos.org>
If `GDebugControllerDBus` remains as the only, or default,
implementation of `GDebugController`, `dup_default()` cannot work.
`GDebugControllerDBus` requires a `GDBusConnection` at construction
time, which the `GIOModule` construction code can’t provide it.
Either we use a default D-Bus connection (but which one? and how would
it be changed by the user later if it was the wrong one?), or delegate
singleton handling of the `GDebugController` to the user.
The latter approach seems more flexible.
Signed-off-by: Philip Withnall <pwithnall@endlessos.org>
Helps: #1190
On Windows, dbus is launched by spawning the gdbus.exe executable on
demand from the gio module. When linked dynamically, the executable
path is guessed relatively to the gio DLL path. But when linked
statically, the only reference path available is the current
executable path. In this case, gdbus.exe is not necessarily in the same
folder as the current executable.
This patch solves the issue using the same algorithm as the one used
with process spawning in glib core source code two commits above.
